Jesse Glick added a comment - 2016-08-24 17:42 Does not look like a Pipeline issue. Any known steps to reproduce from scratch?

Jesse Glick added a comment - 2016-08-24 17:44 Possibly a consequence of this Pipeline change (though if so, still a bug in the Subversion plugin). Investigating.

Jesse Glick added a comment - 2016-08-24 18:54 Failed to reproduce in an acceptance test.

Jesse Glick added a comment - 2016-08-24 19:01 One thing I note is that ReadTrustedStep.Execution should extend AbstractSynchronousNonBlockingStepExecution , in case the SCM checkout takes a long time, which might fix this problem as a side effect.

Jesse Glick added a comment - 2016-08-24 19:12 To that end I also tried running 1.642.x with up-to-date Subversion and Pipeline plugins, creating a local Subversion repository with trunk/Jenkinsfile set to def c = readTrusted 'Jenkinsfile' node { echo c } running svnserve -r … -d , creating a multibranch Pipeline with SCM source set to Subversion using svn://localhost/ , and running a build, then also editing Jenkinsfile trivially and triggering a new build via branch indexing. No errors.

Jesse Glick added a comment - 2016-08-24 19:43 might fix this problem as a side effect Filed a PR for that just in case it does (desirable anyway).

Jesse Glick added a comment - 2016-08-24 20:13 I suspect the root cause is a mismatch of defining vs. initiating class loader as described in JDK-6865375 .

Jesse Glick added a comment - 2016-08-24 21:06 Patch to workflow-cps might resolve this.

Jesse Glick added a comment - 2016-08-24 21:09 In principle SubversionChangeLogParser etc. could also resolve this by setting the desired context loader explicitly, but it is hard to know how many more such cases there might be. Anyway in this case it is not clear the Subversion plugin would even know what to use, since the design of JAXP is such that it is just asking for an XML parser from the system and hoping for the best.

Jesse Glick added a comment - 2016-08-25 12:37 A user claims PR 50 solves the problem with Artifactory, so I will go with that.

SCM/JIRA link daemon added a comment - 2016-08-25 12:52 Code changed in jenkins User: Jesse Glick Path: src/main/java/org/jenkinsci/plugins/workflow/cps/CpsVmExecutorService.java src/main/java/org/jenkinsci/plugins/workflow/cps/DSL.java src/test/java/org/jenkinsci/plugins/workflow/DSLTest.java http://jenkins-ci.org/commit/workflow-cps-plugin/399c76cb59d5bfb2d12502d9b9d2f8b376168d5b Log: JENKINS-37538 Set the context class loader to the usual CCL for plugin code while running steps.

SCM/JIRA link daemon added a comment - 2016-08-25 12:52 Code changed in jenkins User: Jesse Glick Path: src/main/java/org/jenkinsci/plugins/workflow/cps/CpsVmExecutorService.java src/main/java/org/jenkinsci/plugins/workflow/cps/DSL.java src/test/java/org/jenkinsci/plugins/workflow/DSLTest.java http://jenkins-ci.org/commit/workflow-cps-plugin/6f65f3ccd859ca25d0984c40f1723cd05b27cd9b Log: Merge pull request #50 from jglick/CCL- JENKINS-37538 [FIXED JENKINS-37538] Set the context class loader to a neutral value inside step executions Compare: https://github.com/jenkinsci/workflow-cps-plugin/compare/6719c9fa8cf1...6f65f3ccd859

Jesse Glick added a comment - 2016-08-25 12:53 Hope the fix works for the Subversion case as well.

Dietmar Scheidl added a comment - 2016-08-26 09:42 Also works in subversion case. Thanks.

SCM/JIRA link daemon added a comment - 2016-08-26 20:15 Code changed in jenkins User: Jesse Glick Path: src/main/java/org/jenkinsci/plugins/workflow/multibranch/ReadTrustedStep.java http://jenkins-ci.org/commit/workflow-multibranch-plugin/a17edf56abeacd150f1556cac581bb6d1d7a0a46 Log: JENKINS-37538 Should use AbstractSynchronousNonBlockingStepExecution since we are running blocking SCM operations.

SCM/JIRA link daemon added a comment - 2016-08-26 20:15 Code changed in jenkins User: Jesse Glick Path: src/main/java/org/jenkinsci/plugins/workflow/multibranch/ReadTrustedStep.java http://jenkins-ci.org/commit/workflow-multibranch-plugin/b6d7978bf4890010eaf3bc77dd4ca1628cba76c9 Log: Merge pull request #29 from jglick/AbstractSynchronousNonBlockingStepExecution- JENKINS-37538 JENKINS-37538 Should use AbstractSynchronousNonBlockingStepExecution Compare: https://github.com/jenkinsci/workflow-multibranch-plugin/compare/281e8b2d6c4a...b6d7978bf489

SCM/JIRA link daemon added a comment - 2016-08-26 20:16 Code changed in jenkins User: Jesse Glick Path: src/test/java/plugins/WorkflowPluginTest.java http://jenkins-ci.org/commit/acceptance-test-harness/de6fd1153707ea01d3d04b5e59b10277ed7795c7 Log: Failed to reproduce JENKINS-37538 .

SCM/JIRA link daemon added a comment - 2016-08-26 20:16 Code changed in jenkins User: Jesse Glick Path: src/test/java/plugins/WorkflowPluginTest.java http://jenkins-ci.org/commit/acceptance-test-harness/4365c113009e946701949d64eec72753e972165f Log: Merge pull request #178 from jglick/ JENKINS-37538 -reproduction Testing Pipeline + Subversion Compare: https://github.com/jenkinsci/acceptance-test-harness/compare/67e9d1d5bf16...4365c113009e

Nikolay Nachev added a comment - 2017-01-26 18:12 - edited Hello everyone, I have still the same issue with the newest LTS Jenkins 2.32.1. Here my code: String versionPrefix = this .adaptVersionPrefix(releasePrefix) String nexusUrl = "${env.NEXUS_BASE_URL}/service/local/repositories/${repository}/content/${group.replaceAll( '\\.' , '/' ) + '/' + artifact}/maven-metadata.xml" URL metadataUrl = new URL(nexusUrl) URLConnection connection = metadataUrl.openConnection() if (connection.responseCode == 404) { // returned all the first time return versionPrefix + '1' } else if (connection.responseCode == 200) { String xmlContent = connection.content.text def metadata = new XmlSlurper().parseText(xmlContent) List< Integer > maxVersion = [] for (GPathResult pathResult : metadata. 'versioning' . 'versions' . 'version' ) { if (pathResult.toString().startsWith(versionPrefix)) { maxVersion << Integer .valueOf(pathResult.text() - versionPrefix) } } if (maxVersion.isEmpty()) { // only one by new release return versionPrefix + '1' } else { return versionPrefix + (maxVersion.sort().last() + 1); } } else { throw new Exception( "Unknown response code (${connection.responseCode}) from nexus url ${nexusUrl}. Exit job..." ) } The error is: javax.xml.parsers.FactoryConfigurationError: Provider for class javax.xml.parsers.SAXParserFactory cannot be created at javax.xml.parsers.FactoryFinder.findServiceProvider(FactoryFinder.java:311) at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:267) at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:127) at groovy.xml.FactorySupport$2.run(FactorySupport.java:58) at java.security.AccessController.doPrivileged(Native Method) at groovy.xml.FactorySupport.createFactory(FactorySupport.java:35) at groovy.xml.FactorySupport.createSaxParserFactory(FactorySupport.java:56) at groovy.util.XmlSlurper.<init>(XmlSlurper.java:128) at groovy.util.XmlSlurper.<init>(XmlSlurper.java:114) at groovy.util.XmlSlurper.<init>(XmlSlurper.java:101) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83) at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:60) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:235) at org.kohsuke.groovy.sandbox.impl.Checker$3.call(Checker.java:194) at org.kohsuke.groovy.sandbox.GroovyInterceptor.onNewInstance(GroovyInterceptor.java:40) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onNewInstance(SandboxInterceptor.java:128) at org.kohsuke.groovy.sandbox.impl.Checker$3.call(Checker.java:191) at org.kohsuke.groovy.sandbox.impl.Checker.checkedConstructor(Checker.java:188) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.constructorCall(SandboxInvoker.java:20) at Script1.getArtifactBuildVersion(Script1.groovy:129) at WorkflowScript.run(WorkflowScript:34) at ___cps.transform___(Native Method) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:96) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixName(FunctionCallBlock.java:77) at sun.reflect.GeneratedMethodAccessor373.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21) at com.cloudbees.groovy.cps.Next.step(Next.java:58) at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30) at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:163) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:328) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:80) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:240) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:228) at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:63) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang. Thread .run( Thread .java:745) Caused by: java.lang.RuntimeException: Provider for class javax.xml.parsers.SAXParserFactory cannot be created at javax.xml.parsers.FactoryFinder.findServiceProvider(FactoryFinder.java:308) at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:267) at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:127) at groovy.xml.FactorySupport$2.run(FactorySupport.java:58) at java.security.AccessController.doPrivileged(Native Method) at groovy.xml.FactorySupport.createFactory(FactorySupport.java:35) at groovy.xml.FactorySupport.createSaxParserFactory(FactorySupport.java:56) at groovy.util.XmlSlurper.<init>(XmlSlurper.java:128) at groovy.util.XmlSlurper.<init>(XmlSlurper.java:114) at groovy.util.XmlSlurper.<init>(XmlSlurper.java:101) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83) at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:60) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:235) at org.kohsuke.groovy.sandbox.impl.Checker$3.call(Checker.java:194) at org.kohsuke.groovy.sandbox.GroovyInterceptor.onNewInstance(GroovyInterceptor.java:40) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onNewInstance(SandboxInterceptor.java:128) at org.kohsuke.groovy.sandbox.impl.Checker$3.call(Checker.java:191) at org.kohsuke.groovy.sandbox.impl.Checker.checkedConstructor(Checker.java:188) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.constructorCall(SandboxInvoker.java:20) ... 28 more Caused by: java.util.ServiceConfigurationError: javax.xml.parsers.SAXParserFactory: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not a subtype at java.util.ServiceLoader.fail(ServiceLoader.java:239) at java.util.ServiceLoader.access$300(ServiceLoader.java:185) at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:376) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) at java.util.ServiceLoader$1.next(ServiceLoader.java:480) at javax.xml.parsers.FactoryFinder$1.run(FactoryFinder.java:294) at java.security.AccessController.doPrivileged(Native Method) at javax.xml.parsers.FactoryFinder.findServiceProvider(FactoryFinder.java:289) ... 51 more The error line 131 looks like: def metadata = new XmlSlurper().parseText(xmlContent) Am I doing something wrong?

Martin Vehovsky added a comment - 2017-01-30 10:39 Hi Nikolay, I'm also having this issue with the official docker LTS 2.32.1 image. Did you find any solution/workaround? Thanks

Nikolay Nachev added a comment - 2017-01-30 10:48 - edited Hi Martin Vehovsky , I was able to find the cause of my issue and created a new bug, see https://issues.jenkins-ci.org/browse/JENKINS-41515 . My workaround is to read the XML with bash till the bug is fixed. Please let me know if you have the same issue. Best Nikolay

Martin Vehovsky added a comment - 2017-01-30 11:01 - edited Thank you very much Nikolay! You saved me a lot of time investigating the cause. I can confirm disabling the jacoco plugin helped. I'll be watching the linked issue for the fix. Best regards Martin

Jesse Glick added a comment - 2017-01-30 15:09 My workaround is to read the XML with bash till the bug is fixed. This is the proper approach to begin with. Do not use XmlSlurper , URLConnection , etc. from Pipeline script. Write a download/parsing script in the language of your choice and call it from some node using sh / bat .

Martin Vehovsky added a comment - 2017-01-30 15:32 Hi Jesse Glick , can you please elaborate why such common utilities from Groovy shouldn't be used? Besides possible serialization issues that can be avoided if used right. For me, having these utilities is one of the main reasons why I use pipelines.

Jesse Glick added a comment - 2017-02-15 20:04 (a) Class loading hell; (b) dynamic method invocation hell.