Upgrade to JAXB 2.3

Currently we're depending on JAXB 2.2.11, which works with both Java 8 and 11, and (critically) is the version included in Karaf, so it also works in Karaf.

However, this is not the latest version, and we will need to upgrade the dependency, first in order to remove any recently fixed security vulnerability, but also to make it easier for users to integrate with other libraries that use JAXB (possibly a newer version of it).

The problem is, it is not currently possible to use the latest version, JAXB 2.3.1, within Karaf. There are multiple reasons:

1. Several dependencies of Karaf's declare in their OSGi metadata that they require Java 9+. This includes in particular stax-ex 1.8 and FastInfoset 1.2.15, maybe others. If we upgrade, and install these dependencies in a Karaf instance, Karaf just will fail on startup with Java 8 because of unsatisfied dependencies. Dependencies will be satisfied when running it with Java 11, though...

2. Even if we can solve the above, I am not sure that it's possible to use our own JAXB bundle in Karaf. So far we've always use the JAXB bundle provided by the JRE (when using Java 8) or Karaf (when using Java 11 in particular). And when I try to add our own version of JAXB to Karaf, I'm unable to make it all work.

I started a sandbox project to help experiment with the upgrade, and if necessary allow us to provide reproducers to the Karaf team: https://github.com/yrodiere/karaf-sandbox

So far I only tested a "naive" approach where I wrap the JAXB JARs as OSGi bundles, put them in the Karaf instance, and see how it goes. There are other approaches, though. See this PR for details, in particular this section:

The second issue is that JAXB JARs do not work "out of the box". Just adding the runtime JAR as a bundle to our feature is not enough, the API classes will not detect it. Apparently it's because the JAXB JARs do not declare service implementations as OSGi requires (using blueprints, for example). Here are the solutions I could think of:

• Use com.sun.xml.bind:jaxb-osgi, which is an OSGi bundle by the JAXB maintainers. Looks ideal? No it's not:

  • This bundle includes jaxb-xfc, which requires a lot of dependencies, among which package com.sun.source.tree which is part of the Java compiler APIs and is not available by default in Karaf (I couldn't find the appropriate OSGi bundle).

  • I'm not even sure this OSGi bundle will work correctly if we solve the problem above, because the source code for this Maven artifact doesn't look like it does anything special to declare service implementations (no blueprints in particular). Maybe it will, but given the strange stuff we do in our classloader, I wouldn't bet on it.

• Wrap the JAXB JARs ourselves, adding whatever OSGi configuration that is necessary.

  • Maybe we could create a clean bundle with all the correct configuration, but that would essentially mean re-building the jaxb-osgi artifact ourselves.

  • [This was true before that PR, this may be obsolete]I was able to come up with a very simple wrapping. It's an ugly and probably fragile hack, but it works in Karaf with both JRE 8 and JRE 11. The hack consists in wrapping the JAXB runtime bundle, adding in particular an "Export-Package: META-INF.services" instruction to the manifest. Due to how resource loading works in Karaf, this ends up exposing the relevant META-INF/services/XXX file from the runtime bundle to the API classes, and the API classes end up instantiating the runtime as we would expect.

Here are the stack traces I got:

Java 8:

Java 11: