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 https://github.com/eclipse-ee4j/jaxb-api/issues/194