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

ClassNotFoundException when using service as part of SCM poll

    XMLWordPrintable

Details

    • 2.329 released Jan 11, 2022

    Description

      GeneXus Plugin implements SCM support by calling web services to GeneXus Server installations. Some time ago we switched to Jakarta XML Binding 3.0 so as to support both Java 8 and Java 11 Jenkins installations, and it used to work fine in both cases. However, we’ve started seeing problems on Java 11 installations for more recent versions of the core and plugins.

      I'm currently testing with Jenkins version 2.319.1 and this is the stack trace of the error during SCM poll.

      I'm not actually sure where's the root of the problem: the jenkins core, the jackson-databind-plugin or even some change needed on the genexus plugin, but it does seem to be related to a change outside of the genexus plugin.

      Any advice will be greatly appreciated:

      2021-12-28 21:17:16.489+0000 [id=83] SEVERE h.triggers.SCMTrigger$Runner#runPolling: Failed to record SCM polling for org.jenkinsci.plugins.workflow.job.WorkflowJob@3a978328[LocalPipeline]
      2021-12-28 21:17:16.489+0000 [id=83] SEVERE h.triggers.SCMTrigger$Runner#runPolling: Failed to record SCM polling for org.jenkinsci.plugins.workflow.job.WorkflowJob@3a978328[LocalPipeline]
      java.lang.ClassNotFoundException: io.jenkins.cli.shaded.org.w3c.dom.Node
      	at org.jenkinsci.maven.plugins.hpi.JettyAndServletApiOnlyClassLoader.findClass(JettyAndServletApiOnlyClassLoader.java:38)
      	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:588)
      	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
      	at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:543)
      	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
      Caused: java.lang.NoClassDefFoundError: io/jenkins/cli/shaded/org/w3c/dom/Node
      	at org.glassfish.jaxb.runtime.v2.runtime.AnyTypeBeanInfo.<clinit>(AnyTypeBeanInfo.java:152)
      	at org.glassfish.jaxb.runtime.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:493)
      	at org.glassfish.jaxb.runtime.v2.runtime.property.SingleElementNodeProperty.<init>(SingleElementNodeProperty.java:73)
      	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
      	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
      	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
      	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
      	at org.glassfish.jaxb.runtime.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:94)
      	at org.glassfish.jaxb.runtime.v2.runtime.ElementBeanInfoImpl.<init>(ElementBeanInfoImpl.java:58)
      	at org.glassfish.jaxb.runtime.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:448)
      	at org.glassfish.jaxb.runtime.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:299)
      	at org.glassfish.jaxb.runtime.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:77)
      	at org.glassfish.jaxb.runtime.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1111)
      	at org.glassfish.jaxb.runtime.v2.ContextFactory.createContext(ContextFactory.java:140)
      	at org.glassfish.jaxb.runtime.api.JAXBRIContext.newInstance(JAXBRIContext.java:132)
      	at org.glassfish.jaxb.runtime.api.JAXBRIContext.newInstance(JAXBRIContext.java:76)
      	at com.sun.xml.ws.developer.JAXBContextFactory$1.createJAXBContext(JAXBContextFactory.java:83)
      	at com.sun.xml.ws.db.glassfish.JAXBRIContextFactory.newContext(JAXBRIContextFactory.java:64)
      	at com.sun.xml.ws.spi.db.BindingContextFactory.getBindingContextFromSpi(BindingContextFactory.java:177)
      	at com.sun.xml.ws.spi.db.BindingContextFactory.create(BindingContextFactory.java:146)
      	at com.sun.xml.ws.model.AbstractSEIModelImpl$1.run(AbstractSEIModelImpl.java:195)
      	at com.sun.xml.ws.model.AbstractSEIModelImpl$1.run(AbstractSEIModelImpl.java:167)
      	at java.base/java.security.AccessController.doPrivileged(Native Method)
      	at com.sun.xml.ws.model.AbstractSEIModelImpl.createJAXBContext(AbstractSEIModelImpl.java:167)
      	at com.sun.xml.ws.model.AbstractSEIModelImpl.postProcess(AbstractSEIModelImpl.java:81)
      	at com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:294)
      	at com.sun.xml.ws.db.DatabindingImpl.<init>(DatabindingImpl.java:70)
      	at com.sun.xml.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:44)
      	at com.sun.xml.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:28)
      	at com.sun.xml.ws.db.DatabindingFactoryImpl.createRuntime(DatabindingFactoryImpl.java:90)
      	at com.sun.xml.ws.client.WSServiceDelegate.buildRuntimeModel(WSServiceDelegate.java:852)
      	at com.sun.xml.ws.client.WSServiceDelegate.createSEIPortInfo(WSServiceDelegate.java:869)
      	at com.sun.xml.ws.client.WSServiceDelegate.addSEI(WSServiceDelegate.java:832)
      	at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:421)
      	at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:390)
      	at jakarta.xml.ws.Service.getPort(Service.java:181)
      	at org.jenkinsci.plugins.genexus.server.services.teamwork.TeamWorkService2.getCustomBindingITeamWorkService2(TeamWorkService2.java:82)
      	at org.jenkinsci.plugins.genexus.server.clients.TeamWorkService2Client.lambda$getTeamWorkService2$0(TeamWorkService2Client.java:89)
      	at org.jenkinsci.plugins.genexus.server.clients.common.WithLocalContextClassLoader.call(WithLocalContextClassLoader.java:54)
      	at org.jenkinsci.plugins.genexus.server.clients.TeamWorkService2Client.getTeamWorkService2(TeamWorkService2Client.java:87)
      	at org.jenkinsci.plugins.genexus.server.clients.TeamWorkService2Client.getVersions(TeamWorkService2Client.java:126)
      	at org.jenkinsci.plugins.genexus.server.clients.RevisionsQuery$RevisionsIterator.getVersionId(RevisionsQuery.java:201)
      	at org.jenkinsci.plugins.genexus.server.clients.RevisionsQuery$RevisionsIterator.getNextPage(RevisionsQuery.java:187)
      	at org.jenkinsci.plugins.genexus.server.clients.RevisionsQuery$RevisionsIterator.hasNext(RevisionsQuery.java:166)
      	at org.jenkinsci.plugins.genexus.server.clients.RevisionsQuery.getFirstItem(RevisionsQuery.java:132)
      	at org.jenkinsci.plugins.genexus.server.GetLastRevisionTask.getLatestRevisionInfo(GetLastRevisionTask.java:89)
      	at org.jenkinsci.plugins.genexus.server.GetLastRevisionTask.invoke(GetLastRevisionTask.java:74)
      	at org.jenkinsci.plugins.genexus.server.GetLastRevisionTask.invoke(GetLastRevisionTask.java:50)
      	at hudson.FilePath.act(FilePath.java:1171)
      	at hudson.FilePath.act(FilePath.java:1154)
      	at org.jenkinsci.plugins.genexus.server.GeneXusServerSCM.compareRemoteRevisionWith(GeneXusServerSCM.java:239)
      	at org.jenkinsci.plugins.workflow.job.WorkflowJob.poll(WorkflowJob.java:618)
      	at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:614)
      	at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:661)
      	at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:121)
      	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
      	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
      	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
      	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
      	at java.base/java.lang.Thread.run(Thread.java:834)
      

      Attachments

        Issue Links

          Activity

            jlr José Lamas added a comment -

            Update:

            The problem seems to be at the jenkins core level, and related to the shading relocation done at the Jenkins cli pom from "org" to "io.jenkins.cli.shaded.org".

             

            This shading relocation was being done since long time ago, but maybe the recent switch to version 3.2.4 of maven-shade-plugin is related to the problem.

             

            The problem then occurs while creating the service client and invoking the jakarta.xml.ws.Service.getPort() method.

             

            As part of this initialization, the JAXBContextImpl tries to loadClass and inspect all the types (recursively) it needs for deserialization. In particular, when processing org.glassfish.jaxb.runtime.v2.runtime.AnyTypeBeanInfo, this also triggers a loadClass() for the jakarta.xml.bind.annotation.W3CDomHandler class, which in turn would normally trigger a loadClass() for "org.w3c.dom.Node" but since Jenkins version 2.303.1 actually triggers a loadClass() for  "io.jenkins.cli.shaded.org.w3c.dom.Node", which causes the ClassNotFoundException.

             

            As of Jenkins version 2.235 this problem did not occur.

             

            The problem is also easily reproduced by just trying to create a jakarta.xml.bind.annotation.W3CDomHandler instance from the plugin code. 

             

            import jakarta.xml.bind.annotation.W3CDomHandler;

            W3CDomHandler h = new W3CDomHandler();

             

            It fails with the same ClassNotFoundException about "io.jenkins.cli.shaded.org.w3c.dom.Node"

             

             

             

             

             

             

            jlr José Lamas added a comment - Update : The problem seems to be at the jenkins core level, and related to the shading relocation done at the Jenkins cli pom from "org" to "io.jenkins.cli.shaded.org".   This shading relocation was being done since long time ago, but maybe the recent switch to version 3.2.4 of maven-shade-plugin is related to the problem.   The problem then occurs while creating the service client and invoking the jakarta.xml.ws.Service.getPort() method.   As part of this initialization, the JAXBContextImpl tries to loadClass and inspect all the types (recursively) it needs for deserialization. In particular, when processing org.glassfish.jaxb.runtime.v2.runtime.AnyTypeBeanInfo, this also triggers a loadClass() for the jakarta.xml.bind.annotation.W3CDomHandler class, which in turn would normally trigger a loadClass() for "org.w3c.dom.Node" but since Jenkins version 2.303.1 actually triggers a loadClass() for  "io.jenkins.cli.shaded.org.w3c.dom.Node", which causes the ClassNotFoundException.   As of Jenkins version 2.235 this problem did not occur.   The problem is also easily reproduced by just trying to create a jakarta.xml.bind.annotation.W3CDomHandler instance from the plugin code.    import jakarta.xml.bind.annotation.W3CDomHandler; W3CDomHandler h = new W3CDomHandler();   It fails with the same ClassNotFoundException about "io.jenkins.cli.shaded.org.w3c.dom.Node"            
            jlr José Lamas added a comment - - edited

            Update II:

            The problem actually started since this change:

            Bump tyrus-standalone-client-jdk from 1.12 to 2.0.0 (#5128)] …
            dependabot and res0nance committed on Dec 20, 2020

            That changed the tyrus-standalone-client-jdk dependency from version 1.12 to 2.0.0, which in turn caused the inclusion of shaded jakarta/activation, jakarta/websocket and jakarta/xml libraries.

            These libraries are affected by the maven shade relocation specified in the cli/pom.xml

            Then, at JAXB service creation time, it's taking these classes that reference "io.jenkins.cli.shaded.org.w3c.dom.Node" which cause a ClassNotFoundException, and the same problem occurs with a reference to "io.jenkins.cli.shaded.org.xml.sax.SAXException.

            I supposse these jakarta libraries bundled in the cli.jar should be also relocated so as to not interfere with other classes trying to use them? Or maybe the current relocation from "org" to "io.jenkins.cli.shaded.org" should exclude "org.w3c.dom.*" and "org.xml.sax.*"?

             

            jlr José Lamas added a comment - - edited Update II: The problem actually started since this change: Bump tyrus-standalone-client-jdk from 1.12 to 2.0.0 (#5128) ] … dependabot and res0nance committed on Dec 20, 2020 That changed the tyrus-standalone-client-jdk dependency from version 1.12 to 2.0.0, which in turn caused the inclusion of shaded jakarta/activation, jakarta/websocket and jakarta/xml libraries. These libraries are affected by the maven shade relocation specified in the cli/pom.xml .  Then, at JAXB service creation time, it's taking these classes that reference "io.jenkins.cli.shaded.org.w3c.dom.Node" which cause a ClassNotFoundException, and the same problem occurs with a reference to "io.jenkins.cli.shaded.org.xml.sax.SAXException. I supposse these jakarta libraries bundled in the cli.jar should be also relocated so as to not interfere with other classes trying to use them? Or maybe the current relocation from "org" to "io.jenkins.cli.shaded.org" should exclude "org.w3c.dom.*" and "org.xml.sax.*"?  

            People

              jglick Jesse Glick
              jlr José Lamas
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: