-
Improvement
-
Resolution: Duplicate
-
Major
-
None
As described in Dependencies and Class Loading:
Java defines a Thread.getContextClassLoader(). Jenkins does not use this much; it will normally be set by the servlet container to the Jenkins core loader.
Unfortunately, JAXB has a design flaw in that JAXBContext#newInstance expects JAXB to be available in the thread's context class loader. With JAXB being detached to a separate plugin as of recent Java 11 changes, JAXB is no longer available in the Jenkins core loader. This causes a failure to load JAXB.
This plugin has been identified as containing such a call to JAXBContext#newInstance The suggested solution is to wrap calls to JAXBContext#newInstance with a try/finally block to set the thread's context class loader to that of the plugin, which (by virtue of a plugin-to-plugin dependency on JAXB API plugin) enables JAXB to be loaded. See the following PR for an example:
- duplicates
-
JENKINS-55572 Remove JAXB usages in codesonar plugin for Java 11 compatibility
-
- Resolved
-
[JENKINS-68504] Prepare CodeSonar for removal of JAXB and Java 11 requirement
Basil Crow
added a comment - Sorry for not looking at the code carefully enough when filing this ticket. Yes, this was already fixed in JENKINS-55572.
Basil Crow
added a comment - Sorry for not looking at the code carefully enough when filing this ticket. Yes, this was already fixed in JENKINS-55572 . 
Adrien Lecharpentier
added a comment - There is no problem basil . Better safe than sorry. 
The code using JAXBContext#newInstance is already following the pattern suggested: https://github.com/jenkinsci/codesonar-plugin/blob/8d04b144e4ff8e0a0e6342cd3cfed965dd5f0246/src/main/java/org/jenkinsci/plugins/codesonar/services/XmlSerializationService.java#L18-L25
And the plugin already has a dependency to the JAXB Jenkins plugin: https://github.com/jenkinsci/codesonar-plugin/blob/8d04b144e4ff8e0a0e6342cd3cfed965dd5f0246/pom.xml#L153-L157
From what I understand, there is nothing to do here.