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

Unable to load resource META-INF/services/javax.xml.parsers.SAXParserFactory

      On a Jenkins slave, I observed this failure during the Cobertura post-build task:

      FATAL: Unable to load resource META-INF/services/javax.xml.parsers.SAXParserFactory
      java.lang.Error: Unable to load resource META-INF/services/javax.xml.parsers.SAXParserFactory

      The full traceback is here:
      https://gist.github.com/wedaly/7770273

      The slave produced this failure in multiple builds. The slave had been created from an Amazon AMI; other slaves created from the same AMI did not produce this error.

      Attached is the plugin/version info for Jenkins.

          [JENKINS-20855] Unable to load resource META-INF/services/javax.xml.parsers.SAXParserFactory

          Igor Okulist added a comment -

          BUMP,

          any news on this one?

          Igor Okulist added a comment - BUMP, any news on this one?

          Dylan McCall added a comment -

          I've started to observe this issue after migrating Jenkins to Amazon VPC (instead of EC2-Classic). All our builds and tests happen on EC2 instances launched from the same set of AMIs. This particular failure is happening with a node running Ubuntu 12.04. Master has Ubuntu 14.04 and Jenkins 1.571. The problem seems strangely intermittent, but once it occurs I need to destroy the offending machine and launch a new one for the build to work again.

          Dylan McCall added a comment - I've started to observe this issue after migrating Jenkins to Amazon VPC (instead of EC2-Classic). All our builds and tests happen on EC2 instances launched from the same set of AMIs. This particular failure is happening with a node running Ubuntu 12.04. Master has Ubuntu 14.04 and Jenkins 1.571. The problem seems strangely intermittent, but once it occurs I need to destroy the offending machine and launch a new one for the build to work again.

          Gordon McNair added a comment -

          We also just observed this today. Same scenario, slave VM is Amazon VPC. A single VM has had this issue which emerged on first usage after it was launched from the AMI used for dynamic Jenkins slaves. Issue continued after reboot. We are using Amazon Linux in the AMI. Jenkins version is 1.565

          Stack trace looks the same as the orginal poster reported.

          Gordon McNair added a comment - We also just observed this today. Same scenario, slave VM is Amazon VPC. A single VM has had this issue which emerged on first usage after it was launched from the AMI used for dynamic Jenkins slaves. Issue continued after reboot. We are using Amazon Linux in the AMI. Jenkins version is 1.565 Stack trace looks the same as the orginal poster reported.

          Gordon McNair added a comment - - edited

          More information for our case:

          • cobertura-plugin not installed
          • failure occurred early in job execution at the tail end of SCM processing (added plugin to affected components for issue). Tail of the stacktrace is:
            at hudson.remoting.RemoteClassLoader.findResource(RemoteClassLoader.java:376)
            at java.lang.ClassLoader.getResource(ClassLoader.java:1147)
            at java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:227)
            at javax.xml.parsers.SecuritySupport$4.run(SecuritySupport.java:94)
            at java.security.AccessController.doPrivileged(Native Method)
            at javax.xml.parsers.SecuritySupport.getResourceAsStream(SecuritySupport.java:87)
            at javax.xml.parsers.FactoryFinder.findJarServiceProvider(FactoryFinder.java:283)
            at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:255)
            at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:126)
            at org.jenkinsci.plugins.multiplescms.MultiSCMChangeLogParser.parse(MultiSCMChangeLogParser.java:130)
            at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:863)
            at hudson.model.AbstractBuild.access$600(AbstractBuild.java:101)
            at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
            at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)

          Gordon McNair added a comment - - edited More information for our case: cobertura-plugin not installed failure occurred early in job execution at the tail end of SCM processing (added plugin to affected components for issue). Tail of the stacktrace is: at hudson.remoting.RemoteClassLoader.findResource(RemoteClassLoader.java:376) at java.lang.ClassLoader.getResource(ClassLoader.java:1147) at java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:227) at javax.xml.parsers.SecuritySupport$4.run(SecuritySupport.java:94) at java.security.AccessController.doPrivileged(Native Method) at javax.xml.parsers.SecuritySupport.getResourceAsStream(SecuritySupport.java:87) at javax.xml.parsers.FactoryFinder.findJarServiceProvider(FactoryFinder.java:283) at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:255) at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:126) at org.jenkinsci.plugins.multiplescms.MultiSCMChangeLogParser.parse(MultiSCMChangeLogParser.java:130) at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:863) at hudson.model.AbstractBuild.access$600(AbstractBuild.java:101) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)

          Last two releases (separated by over a year) were by olivergondza so looks like the maintainer

          Stephen Connolly added a comment - Last two releases (separated by over a year) were by olivergondza so looks like the maintainer

            Unassigned Unassigned
            wedaly Will Daly
            Votes:
            3 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: