Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-16920

Running native Maven projects on JDK 5 using Jenkins hosted on Tomcat 7 fails

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Critical Critical
    • maven-plugin
    • None
    • Jenkins 1.500
      Tomcat 7.0.35
      Java 1.7.0_13

      building a project with Java 1.5.0_22

      We hit this issue with Jenkins 1.500 running in Tomcat 7.0.35 with Java 1.7.0_13 and building a project with Java 1.5.0_22:

      ERROR: Failed to parse POMs
      java.io.IOException: Remote call on Channel to Maven [/home/wlsiadm/.jenkins/tools/hudson.model.JDK/jdk1.5.0_22/bin/java, -Xmx512m, -cp, /home/wlsiadm/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.2.jar:/home/wlsiadm/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar, org.jvnet.hudson.maven3.agent.Maven3Main, /home/wlsiadm/apache-maven-3.0.4, /home/wlsiadm/apache-tomcat-jenkins/webapps/jenkins/WEB-INF/lib/remoting-2.21.jar, /home/wlsiadm/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.2.jar, 50473] failed
      	at hudson.remoting.Channel.call(Channel.java:681)
      	at hudson.maven.ProcessCache$MavenProcess.call(ProcessCache.java:156)
      	at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:755)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:592)
      	at hudson.model.Run.execute(Run.java:1557)
      	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477)
      	at hudson.model.ResourceController.execute(ResourceController.java:88)
      	at hudson.model.Executor.run(Executor.java:236)
      Caused by: java.lang.ClassFormatError: Failed to load org.kohsuke.stapler.Stapler
      	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:193)
      	at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:144)
      	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
      	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
      	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
      	at hudson.model.Result.<clinit>(Result.java:191)
      	at java.lang.Class.forName0(Native Method)
      	at java.lang.Class.forName(Class.java:164)
      	at $Proxy2.<clinit>(Unknown Source)
      	at sun.reflect.GeneratedSerializationConstructorAccessor39.newInstance(Unknown Source)
      	at java.lang.reflect.Constructor.newInstance(Constructor.java:501)
      	at java.io.ObjectStreamClass.newInstance(ObjectStreamClass.java:896)
      	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1704)
      	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
      	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1910)
      	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1834)
      	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
      	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
      	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
      	at java.util.HashMap.readObject(HashMap.java:1067)
      	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:592)
      	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
      	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1812)
      	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
      	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
      	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1910)
      	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1834)
      	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
      	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
      	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
      	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:269)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
      	at java.lang.Thread.run(Thread.java:595)
      Caused by: java.lang.ClassFormatError: Failed to load javax.servlet.http.HttpServlet
      	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:193)
      	at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:144)
      	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
      	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
      	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
      	at java.lang.ClassLoader.defineClass1(Native Method)
      	at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
      	at java.lang.ClassLoader.defineClass(ClassLoader.java:466)
      	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:191)
      	... 42 more
      Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file
      	at java.lang.ClassLoader.defineClass1(Native Method)
      	at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
      	at java.lang.ClassLoader.defineClass(ClassLoader.java:466)
      	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:191)
      	... 50 more
      Finished: FAILURE
      

          [JENKINS-16920] Running native Maven projects on JDK 5 using Jenkins hosted on Tomcat 7 fails

          Jesse Glick added a comment -

          Originally noted under JENKINS-13659, though that is a rather different issue.

          My diagnosis: Result used by the Jenkins Maven runner amends Stapler.CONVERT_UTILS in a static block, Stapler makes reference to HttpServlet, and Tomcat 7 apparently ships a copy of the Servlet API built for Java 6+. So we get a linkage error, even though the Maven runner has no business loading Servlet-related classes to begin with.

          Simplest fix would be to do the registration not in a static block but using @Initializer. This is assuming the registration is used only in the master JVM, not on slaves.

          Better fix would be to make the CONVERT_UTILS registration declarative so that Stapler discovers such conversions if and when it needs them. Useful to do anyway for performance reasons.

          Best fix would be to refactor the Maven embedder to use only the most limited dependencies on the Maven JVM side, certainly not anything from Jenkins core; at most Remoting and a few custom classes built in their own module. This would allow us to upgrade Jenkins main sources to Java 6 (or greater) dependencies without affecting Maven builds.

          Jesse Glick added a comment - Originally noted under JENKINS-13659 , though that is a rather different issue. My diagnosis: Result used by the Jenkins Maven runner amends Stapler.CONVERT_UTILS in a static block, Stapler makes reference to HttpServlet , and Tomcat 7 apparently ships a copy of the Servlet API built for Java 6+. So we get a linkage error, even though the Maven runner has no business loading Servlet-related classes to begin with. Simplest fix would be to do the registration not in a static block but using @Initializer . This is assuming the registration is used only in the master JVM, not on slaves. Better fix would be to make the CONVERT_UTILS registration declarative so that Stapler discovers such conversions if and when it needs them. Useful to do anyway for performance reasons. Best fix would be to refactor the Maven embedder to use only the most limited dependencies on the Maven JVM side, certainly not anything from Jenkins core; at most Remoting and a few custom classes built in their own module. This would allow us to upgrade Jenkins main sources to Java 6 (or greater) dependencies without affecting Maven builds.

          Jesse Glick added a comment -

          As of 1.520, core has moved on to Java6, so currently this is expected. To quote the changelog:

          Core started relying on Java 1.6 as per the agreement in the dev list. If you have a serious objection against it, please let us know before we really start relying on 1.6 features.

          Jesse Glick added a comment - As of 1.520, core has moved on to Java6, so currently this is expected. To quote the changelog: Core started relying on Java 1.6 as per the agreement in the dev list. If you have a serious objection against it, please let us know before we really start relying on 1.6 features.

            Unassigned Unassigned
            cmueller Christian Müller
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: