-
Improvement
-
Resolution: Fixed
-
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:
- links to
[JENKINS-68510] Prepare Maven Metadata for CI server for removal of JAXB and Java 11 requirement
Basil Crow
added a comment - CC marcrohlfs 
Adrien Lecharpentier
added a comment - The PR was merged by marcrohlfs Basil Crow
added a comment - Fixed in jenkinsci/maven-metadata-plugin#22. Released in 2.1. Thank you for the help, alecharp!
Basil Crow
added a comment - Fixed in jenkinsci/maven-metadata-plugin#22 . Released in 2.1 . Thank you for the help, alecharp ! 
Sebastian Sturm
added a comment - Hi,
it looks like there is the same problem in the method resolveSnapshotRevision(...)
Can you please fix this.
A Possible solution could be like this:
private String resolveSnapshotRevision(String version) { InputStream input = null; try { LOGGER.finest("Resolving SNAPSHOT version if any..."); URL url = new URL(getArtifactUrlForPath(version+"/maven-metadata.xml")); LOGGER.finest("Requesting metadata from URL: "+url.toExternalForm()); URLConnection conn = prepareConnection(url); input = conn.getInputStream(); Thread currentThread = Thread.currentThread(); ClassLoader originalContext = currentThread.getContextClassLoader(); try { currentThread.setContextClassLoader(MavenMetadataParameterDefinition.class.getClassLoader()); JAXBContext context = JAXBContext.newInstance(MavenMetadataVersions.class); Unmarshaller unmarshaller = context.createUnmarshaller(); MavenMetadataVersions metadata = (MavenMetadataVersions) unmarshaller.unmarshal(input); if (metadata.versioning.snapshot != null && !StringUtils.isEmpty(metadata.versioning.snapshot.timestamp)) { return version.replaceAll("SNAPSHOT", "") + metadata.versioning.snapshot.timestamp + "-" + metadata.versioning.snapshot.buildNumber; } } finally { currentThread.setContextClassLoader(originalContext); } } catch (Exception e) { LOGGER.log(Level.WARNING, "Could not parse maven-metadata.xml", e); } finally { try { if (input != null) input.close(); } catch (IOException e) { // ignore } } // we did not find anything, return the original value LOGGER.finest("No match found, using default"); return version; }
Sebastian Sturm
added a comment - Hi,
it looks like there is the same problem in the method resolveSnapshotRevision(...)
Can you please fix this.
A Possible solution could be like this:
private String resolveSnapshotRevision( String version) {
InputStream input = null ;
try {
LOGGER.finest( "Resolving SNAPSHOT version if any..." );
URL url = new URL(getArtifactUrlForPath(version+ "/maven-metadata.xml" ));
LOGGER.finest( "Requesting metadata from URL: " +url.toExternalForm());
URLConnection conn = prepareConnection(url);
input = conn.getInputStream();
Thread currentThread = Thread .currentThread();
ClassLoader originalContext = currentThread.getContextClassLoader();
try {
currentThread.setContextClassLoader(MavenMetadataParameterDefinition. class. getClassLoader());
JAXBContext context = JAXBContext.newInstance(MavenMetadataVersions.class);
Unmarshaller unmarshaller = context.createUnmarshaller();
MavenMetadataVersions metadata = (MavenMetadataVersions) unmarshaller.unmarshal(input);
if (metadata.versioning.snapshot != null && !StringUtils.isEmpty(metadata.versioning.snapshot.timestamp)) {
return version.replaceAll( "SNAPSHOT" , "") + metadata.versioning.snapshot.timestamp + " -" + metadata.versioning.snapshot.buildNumber;
}
} finally {
currentThread.setContextClassLoader(originalContext);
}
} catch (Exception e) {
LOGGER.log(Level.WARNING, "Could not parse maven-metadata.xml" , e);
} finally {
try {
if (input != null )
input.close();
} catch (IOException e) {
// ignore
}
}
// we did not find anything, return the original value
LOGGER.finest( "No match found, using default " );
return version;
}
Basil Crow
added a comment - Can you please fix this.
ssturm No, I cannot. As of jenkins-infra/repository-permissions-updater#2643 I am no longer maintaining this plugin and no longer have permissions to merge PRs or perform releases. If the changes you have suggested work, you can consider adopting the plugin to merge and release them. The "Contributing to Open Source" workshop from DevOps World 2021 is a useful starting point for new maintainers. That document includes links to a five part video series that illustrates many of the steps. If the plugin is crucial to your work, you may want to ask your employer to support your work efforts by allowing you to adopt the plugin.
Basil Crow
added a comment - Can you please fix this.
ssturm No, I cannot. As of jenkins-infra/repository-permissions-updater#2643 I am no longer maintaining this plugin and no longer have permissions to merge PRs or perform releases. If the changes you have suggested work, you can consider adopting the plugin to merge and release them. The " Contributing to Open Source " workshop from DevOps World 2021 is a useful starting point for new maintainers. That document includes links to a five part video series that illustrates many of the steps. If the plugin is crucial to your work, you may want to ask your employer to support your work efforts by allowing you to adopt the plugin. 
I created https://github.com/jenkinsci/maven-metadata-plugin/pull/22 to track this improvement.