Jboss6EAP java.lang.NoSuchMethodError: org.springframework.beans.factory.config.ConfigurableListableBeanFactory.registerResolvableDependency - jboss7.x

I am moving a simple web application from Jboss 4.3 to Jboss 6 EAP (Jboss AS 7.2). However, I am unable to deploy the war because of the error
07:43:17,773 ERROR [org.springframework.web.context.ContextLoader] (ServerService Thread Pool -- 63) Context initialization failed: java.lang.NoSuchMethodError: org.springframework.beans.factory.config.ConfigurableListableBeanFactory.registerResolvableDependency(Ljava/lang/Class;Ljava/lang/Object;)V
at org.springframework.context.support.AbstractApplicationContext.prepareBeanFactory(AbstractApplicationContext.java:458) [spring-2.5.5.jar:2.5.5]
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:356) [spring-2.5.5.jar:2.5.5]
at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255) [spring-2.5.5.jar:2.5.5]
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199) [spring-2.5.5.jar:2.5.5]
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45) [spring-2.5.5.jar:2.5.5]
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) [rt.jar:1.7.0_60]
at java.util.concurrent.FutureTask.run(Unknown Source) [rt.jar:1.7.0_60]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_60]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_60]
at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_60]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
I am not sure what needs to be done. The Spring libraries the war file uses is version 2.5.5 and is bundled within the war 0 within the WEB-INF/lib directory.
Any help in resolving my problem, would be much appreciated. Thanks.

I was able to solve this issue. Would like to share with others, in case they run into the same issue. The war file we were using had Spring libraries and was included within the war file.
The problem was with the versions of the spring.jar and spring-context.jar. The former was 2.0.3 but the latter was version 2.5.5. I downgraded the spring-context.jar to 2.0.3 and it did the trick.
Not sure, why there was no problem in Jboss 4.3. Anyway, I don't have the problem now.

I would like to add that this problem could persist - after clearing out the dependencies (using exclusions), there could still be a wrong version in the Eclipse classpath.
You can figure this out running f.ex. a test with two methods:
in Eclipse
using Maven
mvn clean test -Dtest=com.example.HelloTest
Compare error messages / the stack traces, they might be different, or the Maven test runs fine while in Eclipse the test fails.

Related

SerializationComponentRegistrar is not compatible with this version of compiler

I am getting this error inside AS - even though I tripple checked to pick a valid version pairing (kotlin 1.2.40 with serialisation 0.5.0):
Error:Kotlin: [Internal Error] java.lang.IllegalStateException: The provided plugin org.jetbrains.kotlinx.serialization.compiler.extensions.SerializationComponentRegistrar is not compatible with this version of compiler
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt:186)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt:119)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.createForProduction(KotlinCoreEnvironment.kt:418)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.createCoreEnvironment(K2JVMCompiler.kt:265)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:154)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:63)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.java:107)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.java:51)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:96)
at org.jetbrains.kotlin.daemon.CompileServiceImpl$compile$$inlined$ifAlive$lambda$1.invoke(CompileServiceImpl.kt:399)
at org.jetbrains.kotlin.daemon.CompileServiceImpl$compile$$inlined$ifAlive$lambda$1.invoke(CompileServiceImpl.kt:98)
at org.jetbrains.kotlin.daemon.CompileServiceImpl$doCompile$$inlined$ifAlive$lambda$2.invoke(CompileServiceImpl.kt:920)
at org.jetbrains.kotlin.daemon.CompileServiceImpl$doCompile$$inlined$ifAlive$lambda$2.invoke(CompileServiceImpl.kt:98)
at org.jetbrains.kotlin.daemon.common.DummyProfiler.withMeasure(PerfUtils.kt:137)
at org.jetbrains.kotlin.daemon.CompileServiceImpl.checkedCompile(CompileServiceImpl.kt:950)
at org.jetbrains.kotlin.daemon.CompileServiceImpl.doCompile(CompileServiceImpl.kt:919)
at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:397)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:361)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.AbstractMethodError: org.jetbrains.kotlinx.serialization.compiler.extensions.SerializationComponentRegistrar.registerProjectComponents(Lcom/intellij/mock/MockProject;Lorg/jetbrains/kotlin/config/CompilerConfiguration;)V
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt:184)
... 33 more
Check your installed Kotlin plugin in the idea(Tools>Kotlin>Configure Kotlin Plugin Updates). Must be same as in your build.gradle file.
There's an IntelliJ / Android Studio plugin that's made just for the Kotlin Serialization support, separate from the main Kotlin plugin. From the Working in IntelliJ IDEA section of the readme:
Because serialization is still highly experimental, it is shipped as a separate artifact from "big" Kotlin IDEA plugin. You can download additional IDEA plugin for working with projects that uses serialization from its TeamCity build page
It provides links to the latest TeamCity builds for this plugin, including this one for Kotlin 1.2.40.
Since they only currently publish this plugin through TeamCity, you would have to install it manually by going to Preferences > Plugins > Install plugin from disk...
For anyone using IntelliJ instead of Android Studio, if the plugin doesn't solve the problem, the same readme says to:
try to use gradle for running builds: Settings - Build, Execution, Deployment - Build Tools - Gradle - Runner - tick Delegate IDE build/run actions to gradle; or launch builds from console.
There's an open ticket on Github about this error message, and it might also be worth keeping an eye on that.

Jenkins build failed on OSX

I am trying to build my project using Jenkins to deploy the artifacts to the nexus. I have a Jenkins setup on my macOSX.
below is the error, I am getting:
Parsing POMs
[maventest] $
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java
-Xmx512m -XX:MaxPermSize=128m -Dfile.encoding=UTF-8 -cp /Users/Shared/Jenkins/Home/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.3.jar:/usr/share/maven/boot/plexus-classworlds-2.4.jar
org.jvnet.hudson.maven3.agent.Maven3Main /usr/share/maven
/Users/Shared/Jenkins/Home/war/WEB-INF/lib/remoting-2.26.jar
/Users/Shared/Jenkins/Home/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.3.jar
59985
<===[JENKINS REMOTING CAPACITY]===>channel started
channel stopped
ERROR: Failed to parse POMs java.io.IOException: Remote call on
Channel to Maven
[/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java,
-Xmx512m, -XX:MaxPermSize=128m, -Dfile.encoding=UTF-8, -cp, /Users/Shared/Jenkins/Home/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.3.jar:/usr/share/maven/boot/plexus-classworlds-2.4.jar,
org.jvnet.hudson.maven3.agent.Maven3Main, /usr/share/maven,
/Users/Shared/Jenkins/Home/war/WEB-INF/lib/remoting-2.26.jar,
/Users/Shared/Jenkins/Home/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.3.jar,
59985] failed at hudson.remoting.Channel.call(Channel.java:727) at
hudson.maven.ProcessCache$MavenProcess.call(ProcessCache.java:156) at
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:770)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586)
at hudson.model.Run.execute(Run.java:1593) at
hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:491) at
hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:247) Caused by:
java.lang.InternalError: Can't connect to window server - not enough
permissions. at java.lang.ClassLoader$NativeLibrary.load(Native
Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1827)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1724) at
java.lang.Runtime.loadLibrary0(Runtime.java:823) at
java.lang.System.loadLibrary(System.java:1045) at
sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
at java.security.AccessController.doPrivileged(Native Method) at
java.awt.Toolkit.loadLibraries(Toolkit.java:1605) at
java.awt.Toolkit.(Toolkit.java:1627) at
java.awt.Color.(Color.java:263) at
hudson.util.ColorPalette.(ColorPalette.java:39) at
hudson.model.BallColor.(BallColor.java:56) at
hudson.model.Result.(Result.java:51) at
java.lang.Class.forName0(Native Method) at
java.lang.Class.forName(Class.java:171) at
com.sun.proxy.$Proxy8.(Unknown Source) at
sun.reflect.GeneratedSerializationConstructorAccessor41.newInstance(Unknown
Source) at
java.lang.reflect.Constructor.newInstance(Constructor.java:513) at
java.io.ObjectStreamClass.newInstance(ObjectStreamClass.java:929) at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1759)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1327)
at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1969)
at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1775)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1327)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
at java.util.HashMap.readObject(HashMap.java:1030) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597) at
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:979)
at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1775)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1327)
at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1969)
at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1775)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1327)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
at hudson.remoting.UserRequest.deserialize(UserRequest.java:182) at
hudson.remoting.UserRequest.perform(UserRequest.java:98) at
hudson.remoting.UserRequest.perform(UserRequest.java:48) at
hudson.remoting.Request$2.run(Request.java:326) at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138) at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680) Finished: FAILURE
I already tried the below solution but it didn't work:
http://jenkins-ci.361315.n4.nabble.com/JIRA-Created-HUDSON-5584-java-io-IOException-Remote-call-on-Channel-to-Maven-td1475049.html
Configurations I have:
MAVEN_OPTS:-Xmx1024m
-XX:MaxPermSize=128m
-Dfile.encoding=UTF-8
-Djava.awt.headless=true
output of ps -ef | grep java: /usr/bin/java -Djava.awt.headless=true -jar /Applications/Jenkins/jenkins.war
build command:clean deploy -DaltDeploymentRepository=central::default::http://<user>:<pwd>#<host>:<port>/nexus/content/groups/public/
The solution I used was to apply Java 7. What you want to do is add 1.7 to Jenkins. Following these steps I was able to successfully build my project:
Go to the Oracle Java page and downloaded the 1.7_51 jdk for Mac.
Opened the dmg and ran the executable.
On the Mac, this installs the JDK to /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/
In Jenkins, go to 'Manage Jenkins' > 'Configure System'
Under the JDK heading, click the button that says JDK Installations
Under Name type 'JDK 1.7.0_51'
For JAVA_HOME type '/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/'
Select Save
Go to your project and select Configure
You should now have a JDK drop down near the top of the page.
Select the JDK you just configured under 'Manage Jenkins'
Run the build
After doing this, my build successfully ran without the 'Can't connect to window server - not enough permissions error.'
This line looks curious:
hudson.model.Executor.run(Executor.java:247) Caused by: java.lang.InternalError:
Can't connect to window server - not enough permissions. at java.lang.ClassLoader
$NativeLibrary.load(Native Method)
I would start with a simpler project, and then add complexity from that point, for the reason of just testing to make sure your basic assumptions are correct.
You might need to set the JVM property : -Djava.awt.headless=true . By doing that you will disable the (most likely unnecessary) gui libraries that are trying to load.

Apache CXF issue on Glassfish

I created a web-service app based on Apache CXF (2.7.5), deployed it on a Glassfish 3.0.1 and it works fine till I turn on WS-Sec support. Then I get the following exception when I try to do a web-service request:
Caused by: javax.xml.crypto.NoSuchMechanismException: class configured for XMLSignatureFactory(provider: ApacheXMLDSig)cannot be found.
at javax.xml.crypto.dsig.XMLDSigSecurity.doGetImpl(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLDSigSecurity.getImpl(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLDSigSecurity.getImpl(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLSignatureFactory.findInstance(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLSignatureFactory.getInstance(Unknown Source) ~[webservices-osgi.jar:1.0]
at org.apache.ws.security.message.WSSecSignature.init(WSSecSignature.java:127) ~[wss4j-1.6.10.jar:1.6.10]
at org.apache.ws.security.message.WSSecSignature.<init>(WSSecSignature.java:120) ~[wss4j-1.6.10.jar:1.6.10]
at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.getSignatureBuilder(AbstractBindingBuilder.java:1730) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5]
at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignature(AsymmetricBindingHandler.java:546) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5]
at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:147) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5]
... 273 common frames omitted
Caused by: java.lang.ClassNotFoundException: org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:744) ~[felix.jar:na]
at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) ~[felix.jar:na]
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1656) ~[felix.jar:na]
at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ~[na:1.6.0_43]
It seems that CXF invokes the XMLSignatureFactory class contained by Glassfish's default webservice provider implementation instead of invoking it's own one (it's in the xmlsec.jar file). All CXF files are packed into my war file and also have the <class-loader delegate="false" /> set in sun-web.xml.
Can someone help me why the Glassfish classloader works this way and how could I fix this?
I managed to find out that Glassfish (at least the 3.0.1 version) modifies the default class loading behavior to "protect" some packages (mostly javax. packages) in it's classpath. That's the reason why it finds and uses classes in it's modules directory instead of the one in my war's lib.
To solve this a JVM option should be added to the domain.xml:
<jvm-options>-Dcom.sun.enterprise.overrideablejavaxpackages=javax.xml.crypto,javax.xml.crypto.dsig</jvm-options>
With this Glassfish will allow to use your libs in your war file. But even with this setting it's problematic to use CXF with WS-Securityy along with Metro. The better solution is to use a Glassfish with only Web Profile not Full Profile as Web Profile doesn't have Metro included.

Error configuring dynamic methods for plugin [resources:1.1.6]: Cannot get property 'pluginPath'

Using grails 1.3.7 i have no problem compiling and running my project from my STS.
The error listed below occurs after packaging the WAR and trying to deply it from apache tomcat. This problem has not occured before and i have had success deploying it to apache tomcat in the same fashion before. (Using apache-tomcat-7.0.26).
In regards to the error:
at BootstrapResources.run(BootstrapResources.groovy:23) row 23 points to:
def twitterbootstrapPlugin = applicationContext.pluginManager.getGrailsPlugin('twitter-bootstrap')
row 23 --> twitterbootstrapPluginDir = applicationContext.getResource(twitterbootstrapPlugin.pluginPath).file
ERROR [pool-2-thread-1] (DefaultGrailsPluginManager.java:818) - Error configuring dynamic methods for plugin [resources:1.1.6]: Cannot get property 'pluginPath' on null object java.lang.NullPointerException: Cannot get property 'pluginPath' on null object
at BootstrapResources.run(BootstrapResources.groovy:23)
at org.grails.plugin.resource.module.ModuleDeclarationsFactory$_getModuleDeclarations_closure2.doCall(ModuleDeclarationsFactory.groovy:43)
at org.grails.plugin.resource.module.ModuleDeclarationsFactory.getModuleDeclarations(ModuleDeclarationsFactory.groovy:38)
at org.grails.plugin.resource.module.ModuleDeclarationsFactory.getModuleDeclarations(ModuleDeclarationsFactory.groovy)
at org.grails.plugin.resource.module.ModuleDeclarationsFactory$getModuleDeclarations.call(Unknown Source)
at org.grails.plugin.resource.ResourceProcessor.loadModules(ResourceProcessor.groovy:720)
at org.grails.plugin.resource.ResourceProcessor.this$2$loadModules(ResourceProcessor.groovy)
at org.grails.plugin.resource.ResourceProcessor$this$2$loadModules.callCurrent(Unknown Source)
at org.grails.plugin.resource.ResourceProcessor.reloadAll(ResourceProcessor.groovy:1056)
at org.grails.plugin.resource.ResourceProcessor$reloadAll.call(Unknown Source)
at ResourcesGrailsPlugin$_closure3.doCall(ResourcesGrailsPlugin.groovy:172)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The latest additions to the project has been spring-security-core, but i cant see how this could be an issue.
Anyone has any ideas?
This is probably not a generic solution for this problem, but for my project this was an issue of my maven packaging not including all the needed plugins for successful deployment.
For some reason having defined my plugins within my BuildConfig.groovy file as follows:
plugins{
build ':whateverplugin:0.1'
compile ':whateverplugin:0.1'
runtime ':whateverplugin:0.1'
test ':whateverplugin:0.1'
}
The plugins were not including in the war packaging when packaging my project issuing the command:
mvn package -Dmaven.skip.test=true

Jenkins slave throws "Classloading from system classloader disabled" exception

When running a Maven2 job on a slave instance (Master on AIX 5.3; slave on Windows 2008(R2)), I get the following message (complete stack trace pasted in below): "java.lang.ClassNotFoundException: Classloading from system classloader disabled". This happens with the first job after the slave instance is started (it's running as a Windows service). After that, I get a "java.lang.NoClassDefFoundError: Could not initialize class hudson.maven.MavenModuleSetBuild" error.
If I create a freestyle job, and include the maven command as a batch command to run on the slave, it works fine. The Maven2 job appears to locate Maven on the slave machine, but it apparently can't find the maven-plugin (probably due to the classloading error).
I've searched and posted a ticket to the jenkins-ci site, but no luck as of yet. Has anyone run into this problem?
Stacktrace:
Found mavenVersion 2.2.1 from file jar:file:/C:/apache-maven-2.2.1/lib/maven-2.2.1-uber.jar!/META-INF/maven/org.apache.maven/maven-core/pom.properties
Parsing POMs
ERROR: Failed to parse POMs
hudson.util.IOException2: remote file operation failed: c:\jenkins-slave\workspace\AO_SISO_AT-smoketest-CIT1 at hudson.remoting.Channel#7b827b82:10.40.163.105
at hudson.FilePath.act(FilePath.java:752)
at hudson.FilePath.act(FilePath.java:738)
at hudson.maven.MavenModuleSetBuild$RunnerImpl.parsePoms(MavenModuleSetBuild.java:817)
at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:617)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:429)
at hudson.model.Run.run(Run.java:1374)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:467)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:145)
Caused by: java.io.IOException: Remote call on 10.40.163.105 failed
at hudson.remoting.Channel.call(Channel.java:652)
at hudson.FilePath.act(FilePath.java:745)
... 8 more
Caused by: java.lang.ExceptionInInitializerError
at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1236)
at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1110)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1956)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:270)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at hudson.remoting.Engine$1$1.run(Engine.java:60)
at java.lang.Thread.run(Unknown Source)
Caused by: com.thoughtworks.xstream.XStream$InitializationException: Could not instantiate converter : com.thoughtworks.xstream.converters.extended.DurationConverter : null
at com.thoughtworks.xstream.XStream.dynamicallyRegisterConverter(XStream.java:735)
at com.thoughtworks.xstream.XStream.setupConverters(XStream.java:699)
at com.thoughtworks.xstream.XStream.<init>(XStream.java:445)
at com.thoughtworks.xstream.XStream.<init>(XStream.java:385)
at com.thoughtworks.xstream.XStream.<init>(XStream.java:323)
at hudson.util.XStream2.<init>(XStream2.java:62)
at hudson.model.Run.<clinit>(Run.java:1867)
... 13 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.thoughtworks.xstream.XStream.dynamicallyRegisterConverter(XStream.java:728)
... 19 more
Caused by: javax.xml.datatype.DatatypeConfigurationException: Provider org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl not found
at javax.xml.datatype.DatatypeFactory.newInstance(Unknown Source)
at com.thoughtworks.xstream.converters.extended.DurationConverter.<init>(DurationConverter.java:33)
... 24 more
Caused by: java.lang.ClassNotFoundException: Classloading from system classloader disabled
at java.lang.Throwable.<init>(Throwable.java:56)
at java.lang.Throwable.<init>(Throwable.java:80)
at java.lang.ClassNotFoundException.<init>(ClassNotFoundException.java:80)
at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch2(RemoteClassLoader.java:399)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274)
at hudson.remoting.Request$2.run(Request.java:270)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:432)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:284)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:799)
I had similar issue. Researched internet but did not get any solution. Finally debugged the jenkins/hudson and resolved this issue.
The root cause of this error is that recent versions of jenkin is shipped with xml parser within jenkins.war file. Looks like if your server already has this jar file, it won't let jenkin application to reload its own version of xml parsers. So to resolve this issue I have removed file xercesImpl-2.9.1.jar from WEB-INF/lib directory of jenkins.war file. After that replaced existing war file and restarted server. And it worked as without any problem.