XMLBindingContextFactory in EclipseLink 4 causes GlassFish to find 2 JAXBContextFactory providers

[arjantijms]

XMLBindingContextFactory, which I think is new in EclipseLink 4, causes jakarta.xml.bind.ServiceLoaderUtil.lookupUsingOSGiServiceLoader(String, Logger) to find 2 providers for jakarta.xml.bind.JAXBContextFactory; this new one and the existing V2 ONE.

As Jersey instantiates its WADL Feature which needs JAXB, the parent class loader at that point is the Jersey bundle class loader:
(org.apache.felix.framework.BundleWiringImpl$BundleClassLoader) org.glassfish.jersey.core.jersey-server [256].

This ultimately leads to class loading errors when org.eclipse.persistence.internal.jaxb.WrappedValue is being loaded by org.eclipse.persistence.internal.jaxb.JaxbClassLoader.loadClass(String).

I'm still researching the exact issue, but any hints would be appreciated.

[arjantijms]

@lukasj the cause seems to be because of this change.

In jakarta.xml.bind.ContextFinder.find(String, String, ClassLoader, Map<String, ?>):

In 4.0.0

Class<?> ctxFactory = (Class<?>) ServiceLoaderUtil.lookupUsingOSGiServiceLoader(
                JAXBContext.JAXB_CONTEXT_FACTORY, logger);

Where JAXB_CONTEXT_FACTORY = "jakarta.xml.bind.JAXBContextFactory"

In 3.0.1

 Class ctxFactory = (Class) ServiceLoaderUtil.lookupUsingOSGiServiceLoader(
                "jakarta.xml.bind.JAXBContext", logger);

For the JAXBContext lookup only one instance is found, which is the right one org.glassfish.jaxb.runtime.v2.ContextFactory.

Any ideas how to resolve this in GF?

[arjantijms]

Other parts of GF seem to dislike the EclipseLink JAXB provider as well, e.g.

  Unknown JAXBContext implementation: class org.eclipse.persistence.jaxb.JAXBContext
com.sun.xml.ws.spi.db.DatabindingException: Unknown JAXBContext implementation: class org.eclipse.persistence.jaxb.JAXBContext
        at com.sun.xml.ws.spi.db.BindingContextFactory.getJAXBFactory(BindingContextFactory.java:226)
        at com.sun.xml.ws.spi.db.BindingContextFactory.create(BindingContextFactory.java:120)
        at com.sun.xml.ws.message.jaxb.JAXBMessage.create(JAXBMessage.java:137)
        at com.sun.xml.ws.fault.SOAPFaultBuilder.createSOAP11Fault(SOAPFaultBuilder.java:405)
        at com.sun.xml.ws.fault.SOAPFaultBuilder.createSOAPFaultMessage(SOAPFaultBuilder.java:180)
        at com.sun.xml.ws.fault.SOAPFaultBuilder.createSOAPFaultMessage(SOAPFaultBuilder.java:168)
        at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:407)
        at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:838)
        at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:392)
        at com.sun.xml.ws.transport.http.servlet.ServletAdapter.invokeAsync(ServletAdapter.java:196)
        at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:131)
        at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:169)
        at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:52)
        at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:547)

Maybe it's better after all to disable org.eclipse.persistence.jaxb.JAXBContext? Why does it exist in the first place?

[lukasj]

See jakartaee/jaxb-api#194

[lukasj]

this has nothing to do with MOXy in the first place - there is no evidence of MOXy code being involved in provided stacktraces, all they say is that {jersey, metro} do rely on a specific implementation of XML binding. This could have come through an overly eager adoption of the API which has announced breaking changes through the change in its major version number by GF without giving those project time to adopt this particular change or it could have been just a development time issue for which some temporary fix has never been reverted.

In any case, once jakartaee/jaxb-api#275 gets to public binary, things should start working as I would expect them to:

-by default, arbitrary version of the xml binding implementation is used by the XML Binding API
-jakarta.xml.bind.JAXBContextFactory property passed to JAXBContext allows the caller to explicitly say which particular implementation is to be used
-System property jakarta.xml.bind.JAXBContextFactory set to a classname of some provider bypasses any caller-level configuration as well as default lookup in the particular JVM