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

javax.xml.parsers.FactoryConfigurationError exception thrown by slaves.

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Blocker Blocker
    • pmd-plugin, violations-plugin
    • None
    • Both Windows & Linux, Java 6.

      When configured as post-build action, both plugins attempt to parse XML documents using a third party xml parser (xerces) on the slave node. As this library is not part of most JDK's it is usually not installed on the slave nodes. This then fails with the cryptic stacktrace:

      [PMD] Collecting PMD analysis files...
      ERROR: Publisher hudson.plugins.pmd.PmdPublisher aborted due to exception
      hudson.util.IOException2: remote file operation failed: project at hudson.remoting.Channel@37393739:slave
      at hudson.FilePath.act(FilePath.java:835)
      at hudson.FilePath.act(FilePath.java:821)
      at hudson.plugins.pmd.PmdPublisher.perform(PmdPublisher.java:134)
      at hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:358)
      at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
      at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710)
      at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685)
      at hudson.model.Build$RunnerImpl.post2(Build.java:162)
      at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632)
      at hudson.model.Run.run(Run.java:1463)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:239)
      Caused by: java.io.IOException: Remote call on yasser-windows-slave failed
      at hudson.remoting.Channel.call(Channel.java:672)
      at hudson.FilePath.act(FilePath.java:828)
      ... 12 more
      Caused by: javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found
      at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source)
      at org.apache.commons.digester.Digester.getFactory(Digester.java:490)
      at org.apache.commons.digester.Digester.getParser(Digester.java:693)
      at org.apache.commons.digester.Digester.getXMLReader(Digester.java:899)
      at org.apache.commons.digester.Digester.parse(Digester.java:1666)
      at hudson.plugins.pmd.parser.PmdParser.parse(PmdParser.java:70)
      at hudson.plugins.analysis.core.AbstractAnnotationParser.parse(AbstractAnnotationParser.java:54)
      at hudson.plugins.analysis.core.FilesParser.parseFile(FilesParser.java:261)
      at hudson.plugins.analysis.core.FilesParser.parseFiles(FilesParser.java:220)
      at hudson.plugins.analysis.core.FilesParser.invoke(FilesParser.java:169)
      at hudson.plugins.analysis.core.FilesParser.invoke(FilesParser.java:31)
      at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2193)
      at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      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(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)

      Downloading the xerces library manually and adding it to the classpath works on linux, but fails on windows. In that case Jenkins outputs the following message to stdout:
      <===[JENKINS REMOTING CAPACITY]===>rO0ABXNyABpodWRzb24ucmVtb3RpbmcuQ2FwYWJpbGl0eQAAAAAAAAABAgABSgAEbWFza3hwAAAAAAAAAAY=

      I would expect that:

      • complicated operations, such as parsing an xml file, are performed solely on the master node;
      • a slave node does never need any third party libraries;
      • plugins are not allowed to execute part of their code on the slave nodes.

          [JENKINS-14689] javax.xml.parsers.FactoryConfigurationError exception thrown by slaves.

          SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Ulli Hafner
          Path:
          .classpath
          pom.xml
          http://jenkins-ci.org/commit/pmd-plugin/60c5370aee9a0fdfd0ca4514b8abe510f9343c84
          Log:
          JENKINS-14689 Add Xerces dependency so that parser is found on slave.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Ulli Hafner Path: .classpath pom.xml http://jenkins-ci.org/commit/pmd-plugin/60c5370aee9a0fdfd0ca4514b8abe510f9343c84 Log: JENKINS-14689 Add Xerces dependency so that parser is found on slave.

          Jesse Glick added a comment -

          This fix seems suspect. All Java runtimes include a SAXParserFactory implementation already - in the case of a Sun/Oracle JRE, a slightly simplified, and repackaged, version of Xerces in the com.sun namespace.

          The fact that Digester.getFactory is trying and failing to load a parser from the org.apache namespace probably means that (1) the slave JVM includes a copy of Xerces in an inappropriate place such as jre/lib/endorsed (using the "endorsed" mechanism is always a bad idea!), (2) something in the slave's ClassLoader is broken.

          Regarding conclusion #2, there is a known bug in some versions of JAXP (fixed in Java 7) that can cause its factory finder to pick up the presence of a custom implementation (here org.apache Xerces) while not actually being able to load it. The bug can be tickled by user installations that add Xerces to the endorsed classpath. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6723276 has a fuller explanation and http://hg.netbeans.org/main/rev/269e1a79df2b gives an example of how to work around this.

          Reporter: your expectation #2 is true to the extent that an administrator of a slave node should not need to install any additional Java libraries; #1 and #3 are false.

          Jesse Glick added a comment - This fix seems suspect. All Java runtimes include a SAXParserFactory implementation already - in the case of a Sun/Oracle JRE, a slightly simplified, and repackaged, version of Xerces in the com.sun namespace. The fact that Digester.getFactory is trying and failing to load a parser from the org.apache namespace probably means that (1) the slave JVM includes a copy of Xerces in an inappropriate place such as jre/lib/endorsed (using the "endorsed" mechanism is always a bad idea!), (2) something in the slave's ClassLoader is broken. Regarding conclusion #2, there is a known bug in some versions of JAXP (fixed in Java 7) that can cause its factory finder to pick up the presence of a custom implementation (here org.apache Xerces) while not actually being able to load it. The bug can be tickled by user installations that add Xerces to the endorsed classpath. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6723276 has a fuller explanation and http://hg.netbeans.org/main/rev/269e1a79df2b gives an example of how to work around this. Reporter: your expectation #2 is true to the extent that an administrator of a slave node should not need to install any additional Java libraries; #1 and #3 are false.

          Ulli Hafner added a comment -

          Ok, that means that this is not a bug in my code and it is ok to leave this issue closed? Or is there something I can do?

          Ulli Hafner added a comment - Ok, that means that this is not a bug in my code and it is ok to leave this issue closed? Or is there something I can do?

            drulli Ulli Hafner
            bcmpinc a a
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: