[JIRA] (JENKINS-58130) JAX-WS ClassNotFoundException javax.xml.ws.WebServiceException
Title: Message Title Richard Otte edited a comment on JENKINS-58130 Re: JAX-WS ClassNotFoundException javax.xml.ws.WebServiceException Replying on behalf of Synopsys (as the developer of the Synopsys Coverity plugin), Investigating this extensively, it would appear that the root of this exception is a fundamental problem in Jenkins or JAX-WS. Briefly, JAX-WS has a ServiceLoaderUtil class shared among the SAAJ, JAXB, and JAXWS libraries to invoke java's ServiceLoader and get implementation classes, but it only ever invokes ServiceLoader.load(Class spiClass), the method that tries to load the class from the current thread's context ClassLoader.When the exception mentioned by Sverre occurs, the thread that is executing the Synopsys Coverity plugin code does not have the dynamic plugin ClassLoader as it's context ClassLoader-- instead it has the Jenkins WAR ClassLoader, which does not contain any of the JAX-WS classes.It appears that either: * JAX-WS has a bug and should be patched to not rely on the thread context ClassLoader, for example by also checking the spi class's ClassLoader * Jenkins has a bug and should be patched ensuring that threads executing plugin code always have a context ClassLoader that is the dynamic plugin ClassLoaderIn either case, does the Jenkins team have any suggestions for how to work around this problem? I admit I'm fairly new to the Jenkins Jira and I'm not quite sure who to tag.Edit: As context, my investigation was conducted while providing the missing JAX-WS classes as jar dependencies to the Synopsys Coverity plugin. I can provide a link to the branch on GitHub if further investigation is needed on the Jenkins side of things to see what I see. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-58130) JAX-WS ClassNotFoundException javax.xml.ws.WebServiceException
Title: Message Title Richard Otte edited a comment on JENKINS-58130 Re: JAX-WS ClassNotFoundException javax.xml.ws.WebServiceException Replying on behalf of Synopsys (as the developer of the Synopsys Coverity plugin),Investigating this extensively, it would appear that the root of this exception is a fundamental problem in Jenkins or JAX-WS. Briefly, JAX-WS has a ServiceLoaderUtil class shared among the SAAJ, JAXB, and JAXWS libraries to invoke java's ServiceLoader and get implementation classes, but it only ever invokes ServiceLoader.load(Class spiClass), the method that tries to load the class from the current thread's context ClassLoader.When the exception mentioned by Sverre occurs, the thread that is executing the Synopsys Coverity plugin code does not have the dynamic plugin ClassLoader as it's context ClassLoader-- instead it has the Jenkins WAR ClassLoader, which does not contain any of the JAX-WS classes.It appears that either:* JAX-WS has a bug and should be patched to not rely on the thread context ClassLoader, for example by also checking the spi class's ClassLoader* Jenkins has a bug and should be patched ensuring that threads executing plugin code always have a context ClassLoader that is the dynamic plugin ClassLoaderIn either case, does the Jenkins team have any suggestions for how to work around this problem? I admit I'm fairly new to the Jenkins Jira and I'm not quite sure who to tag. Edit: As context, my investigation was conducted while providing the missing classes as dependencies to the Synopsys Coverity plugin. I can provide a link to the branch on GitHub if further investigation is needed on the Jenkins side of things to see what I see. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-58130) JAX-WS ClassNotFoundException javax.xml.ws.WebServiceException
Title: Message Title Richard Otte commented on JENKINS-58130 Re: JAX-WS ClassNotFoundException javax.xml.ws.WebServiceException Replying on behalf of Synopsys (as the developer of the Synopsys Coverity plugin), Investigating this extensively, it would appear that the root of this exception is a fundamental problem in Jenkins or JAX-WS. Briefly, JAX-WS has a ServiceLoaderUtil class shared among the SAAJ, JAXB, and JAXWS libraries to invoke java's ServiceLoader and get implementation classes, but it only ever invokes ServiceLoader.load(Class spiClass), the method that tries to load the class from the current thread's context ClassLoader. When the exception mentioned by Sverre occurs, the thread that is executing the Synopsys Coverity plugin code does not have the dynamic plugin ClassLoader as it's context ClassLoader-- instead it has the Jenkins WAR ClassLoader, which does not contain any of the JAX-WS classes. It appears that either: JAX-WS has a bug and should be patched to not rely on the thread context ClassLoader, for example by also checking the spi class's ClassLoader Jenkins has a bug and should be patched ensuring that threads executing plugin code always have a context ClassLoader that is the dynamic plugin ClassLoader In either case, does the Jenkins team have any suggestions for how to work around this problem? I admit I'm fairly new to the Jenkins Jira and I'm not quite sure who to tag. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
