search

jakartaee / jaxb-api

BSD 3-Clause "New" or "Revised" License
61 stars 42 forks source link

Invalid JAXB default factory class on JavaSE 11 #78

Closed bravehorsie closed 5 years ago

bravehorsie commented 6 years ago 
    private static final String PLATFORM_DEFAULT_FACTORY_CLASS = "com.sun.xml.internal.bind.v2.ContextFactory";

Jaxb api uses invalid default factory class which referes to JDK versions, which has included JAXB implementation. Since JDK 11 it is no longer valid. Default factory class should be "com.sun.xml.bind.v2.ContextFactory" without "internal" so it takes jaxb-ri as default or should be excluded completely printing describing error message when no implementation is found.

See javax.xml.bind.ContextFinder

col-panic commented 5 years ago

Facing the same problem here, porting my application (to java version "11.0.1" 2018-10-16 LTS). Starting the application leaves me with

javax.xml.bind.JAXBException: Implementation of JAXB-API has not been found on module path or classpath.
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:278) ~[na:na]
    at javax.xml.bind.ContextFinder.find(ContextFinder.java:421) ~[na:na]
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:721) ~[na:na]
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:662) ~[na:na]
    at ch.elexis.core.common.DBConnection.unmarshall(DBConnection.java:133) ~[na:na]
    at info.elexis.server.core.connector.elexis.common.ElexisDBConnectionUtil.<clinit>(ElexisDBConnectionUtil.java:40) ~[na:na]
    at info.elexis.server.core.connector.elexis.internal.Activator.start(Activator.java:33) ~[na:na]
    at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:782) ~[na:na]
    at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1) ~[na:na]
    at java.base/java.security.AccessController.doPrivileged(Native Method) ~[na:na]
    at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:775) ~[na:na]
    at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:732) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1005) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:357) ~[na:na]
    at org.eclipse.osgi.container.Module.doStart(Module.java:584) ~[na:na]
    at org.eclipse.osgi.container.Module.start(Module.java:452) ~[na:na]
    at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:471) ~[na:na]
    at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:117) ~[na:na]
    at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:557) ~[na:na]
    at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:331) ~[na:na]
    at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395) ~[na:na]
    at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:473) ~[na:na]
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) ~[na:na]
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:414) ~[na:na]
    at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:153) ~[na:na]
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.loadClass(EquinoxBundle.java:612) ~[na:na]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.initDependencyManagers(AbstractComponentManager.java:992) ~[na:na]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1019) ~[na:na]
    at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:860) ~[na:na]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:755) ~[na:na]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.enableInternal(AbstractComponentManager.java:675) ~[na:na]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:430) ~[na:na]
    at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:657) ~[na:na]
    at org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:341) ~[na:na]
    at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:387) ~[na:na]
    at org.apache.felix.scr.impl.Activator.access$200(Activator.java:52) ~[na:na]
    at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:262) ~[na:na]
    at org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196) ~[na:na]
    at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:169) ~[na:na]
    at org.apache.felix.scr.impl.AbstractExtender.addingBundle(AbstractExtender.java:139) ~[na:na]
    at org.apache.felix.scr.impl.AbstractExtender.addingBundle(AbstractExtender.java:49) ~[na:na]
    at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:475) ~[na:na]
    at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:1) ~[na:na]
    at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) ~[na:na]
    at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) ~[na:na]
    at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:450) ~[na:na]
    at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:911) ~[na:na]
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:233) ~[na:na]
    at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:233) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:140) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:132) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:194) ~[na:na]
    at org.eclipse.osgi.container.Module.publishEvent(Module.java:479) ~[na:na]
    at org.eclipse.osgi.container.Module.start(Module.java:470) ~[na:na]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1685) ~[na:na]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1664) ~[na:na]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1627) ~[na:na]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1558) ~[na:na]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[na:na]
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:233) ~[na:na]
    at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:343) ~[na:na]
Caused by: java.lang.ClassNotFoundException: com.sun.xml.internal.bind.v2.ContextFactory
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) ~[na:na]
    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) ~[na:na]
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[na:na]
    at org.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:135) ~[na:na]
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[na:na]
    at javax.xml.bind.ServiceLoaderUtil.nullSafeLoadClass(ServiceLoaderUtil.java:122) ~[na:na]
    at javax.xml.bind.ServiceLoaderUtil.safeLoadClass(ServiceLoaderUtil.java:155) ~[na:na]
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:276) ~[na:na]
    ... 62 common frames omitted
lukasj commented 5 years ago

this should be fixed in 2.3.2, right @bravehorsie ?

col-panic commented 5 years ago

Is 2.3.2 already available? I saw that there is a name change to jakarta.xml.bind - but although there is a release available on this site, I can't find the respective artifacts on mavencentral.

lukasj commented 5 years ago

Not yet, it's available only for testing in the sonatype's staging repo (so still subject to change)

col-panic commented 5 years ago

As soon, as @bravehorsie might confirm that a patch is already provided in 2.3.2 i could test it for my scenario!

col-panic commented 5 years ago

Please also confirm, that this package works under osgi - I just checked out the source and manually altered the above mentioned string. Yet a startup within an osgi setting is not possible.

bravehorsie commented 5 years ago

No it is not fixed. There was an issue reported that this change will break CTS Glassfish tests for the first Jakarta release and should be left in place as was for JavaSE 8, so there is less work on fixing CTS tests.
@lukasj If that is not the issue anymore I will create a PR.

bravehorsie commented 5 years ago

@col-panic It was fixed once in jaxb-api 2.4.0-b180830.0359 but was reverted back in 2.3.1 due to above error report.

col-panic commented 5 years ago

@bravehorsie I see that you already have a multi-release bundle, wouldn't it be possible to extract this constant into a separate class, and overriding this class in a >= Java 11 bundle only? The tests should stay ok then, no?

So whats the overall state for this on Java 11?

col-panic commented 5 years ago

I just tried the version mentioned (2.4.0-b180830.0359) - yet I can't seem to get it work in an osgi environment (Java 11.0.1 / org.eclipse.osgi_3.13_100.v20180827-1536), the stack trace is the same, but with different name

javax.xml.bind.JAXBException: Implementation of JAXB-API has not been found on module path or classpath.
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:269) ~[na:na]
    at javax.xml.bind.ContextFinder.find(ContextFinder.java:412) ~[na:na]
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:721) ~[na:na]
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:662) ~[na:na]
    at ch.elexis.core.common.DBConnection.unmarshall(DBConnection.java:133) ~[na:na]
    at info.elexis.server.core.connector.elexis.common.ElexisDBConnectionUtil.<clinit>(ElexisDBConnectionUtil.java:40) ~[na:na]
    at info.elexis.server.core.connector.elexis.internal.Activator.start(Activator.java:33) ~[na:na]
    at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:782) ~[na:na]
    at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1) ~[na:na]
    at java.base/java.security.AccessController.doPrivileged(Native Method) ~[na:na]
    at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:775) ~[na:na]
    at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:732) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1005) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:357) ~[na:na]
    at org.eclipse.osgi.container.Module.doStart(Module.java:584) ~[na:na]
    at org.eclipse.osgi.container.Module.start(Module.java:452) ~[na:na]
    at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:471) ~[na:na]
    at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:117) ~[na:na]
    at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:557) ~[na:na]
    at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:331) ~[na:na]
    at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395) ~[na:na]
    at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:473) ~[na:na]
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) ~[na:na]
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:414) ~[na:na]
    at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:153) ~[na:na]
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.loadClass(EquinoxBundle.java:612) ~[na:na]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.initDependencyManagers(AbstractComponentManager.java:992) ~[na:na]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1019) ~[na:na]
    at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:860) ~[na:na]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:755) ~[na:na]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.enableInternal(AbstractComponentManager.java:675) ~[na:na]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:430) ~[na:na]
    at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:657) ~[na:na]
    at org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:341) ~[na:na]
    at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:387) ~[na:na]
    at org.apache.felix.scr.impl.Activator.access$200(Activator.java:52) ~[na:na]
    at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:262) ~[na:na]
    at org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196) ~[na:na]
    at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:169) ~[na:na]
    at org.apache.felix.scr.impl.AbstractExtender.addingBundle(AbstractExtender.java:139) ~[na:na]
    at org.apache.felix.scr.impl.AbstractExtender.addingBundle(AbstractExtender.java:49) ~[na:na]
    at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:475) ~[na:na]
    at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:1) ~[na:na]
    at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) ~[na:na]
    at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) ~[na:na]
    at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:450) ~[na:na]
    at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:911) ~[na:na]
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:233) ~[na:na]
    at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:233) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:140) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:132) ~[na:na]
    at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:194) ~[na:na]
    at org.eclipse.osgi.container.Module.publishEvent(Module.java:479) ~[na:na]
    at org.eclipse.osgi.container.Module.start(Module.java:470) ~[na:na]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1685) ~[na:na]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1664) ~[na:na]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1627) ~[na:na]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1558) ~[na:na]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[na:na]
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:233) ~[na:na]
    at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:343) ~[na:na]
Caused by: java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) ~[na:na]
    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) ~[na:na]
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[na:na]
    at org.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:135) ~[na:na]
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[na:na]
    at javax.xml.bind.ServiceLoaderUtil.nullSafeLoadClass(ServiceLoaderUtil.java:122) ~[na:na]
    at javax.xml.bind.ServiceLoaderUtil.safeLoadClass(ServiceLoaderUtil.java:155) ~[na:na]
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:267) ~[na:na]
    ... 62 common frames omitted

I'm not sure whether this problem belongs here, so I cross-posted this in https://www.eclipse.org/forums/index.php/t/1096601/

col-panic commented 5 years ago

Related https://sjhannah.com/blog/2018/11/21/jaxb-hell-on-jdk-9/

bravehorsie commented 5 years ago

@col-panic com.sun.xml.bind.v2.ContextFactory is in org.glassfish.jaxb:jaxb-runtime artifact. The ClassNotFound error probably means that you either:

I see that you already have a multi-release bundle, wouldn't it be possible to extract this constant into a separate class, and overriding this class in a >= Java 11 bundle only?

Yes, that would work, but after configuring jaxb properly you should not need it.

lukasj commented 5 years ago

what about targeting 2.4.0 for JDK 11+ and 2.3.x for JDK 8+? 2.3.x should be doable ie as @col-panic suggests (multi-release jar) or by adding additional 'try' option to lookup non-internal version of the ContextFactory.

There are two additional things we probably should keep in mind:

  1. with JAXB-RI removal from JDK, by default, there is no implementation for the API to work with, so the existing lookup for com.sun.xml.{internal.}bind.v2.ContextFactory should probably be removed unless the spec says the opposite; there is also an option to follow what JAF or mail is doing - providing somegroupId:jakarta.xml.bind artifact being API+impl bundle
  2. there is MOXy (other JAXB implementation)
col-panic commented 5 years ago

@bravehorsie thanks, ... this is a real pain, so there seem two be 2 possible solutions in an OSGI setting

  1. Add the patch from https://sjhannah.com/blog/2018/11/21/jaxb-hell-on-jdk-9/ then directly deliver all required libraries with the osgi bundle (each added to the runtime) - this somehow seems to work out, but is not a viable solution
  2. Extend the JRE with --add-modules to include all jaxb requirements - I made this to some point but am stuck with Module com.sun.xml.txw2 not found, required by com.sun.xml.bind

Why does the classloader in at org.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:135) ~[na:na] not simply resolve com.sun.xml.bind.v2.ContextFactory if it is available in the runtime in the form of org.glassfish.jaxb.runtime?

Is the whole setting of using Java11/Osgi/JAXB Implementation tested somewhere?

lukasj commented 5 years ago

org.glassfish.jaxb* artifacts we're never intended for usage in OSGi environment (this will very likely change rather sooner than later); if you need OSGi, then com.sun.xml.bind:jaxb-osgi is what one needs (it's being consumed by GlassFish - which is OSGi based, or latest eclipselink)

col-panic commented 5 years ago

@lukasj Thank you very much for that hint, I think it works now! With jaxb-api 2.4.0-b180830.0359 and com.sun.xml.bind.jaxb-osgi(2.4.0b180830_0438)

col-panic commented 5 years ago

@lukasj it only works with my manually modified version of jaxb-api, where I additionally add Import-Package: com.sun.xml.bind.v2;resolution:=optional to MANIFEST.MF

lukasj commented 5 years ago

it may not be required if methods taking classloader as an argument (such as JAXBContext.newInstance(String contextPath, ClassLoader classLoader)) are used. Problem here is related to the behaviour of ServiceLoader in OSGi

bravehorsie commented 5 years ago

Is the whole setting of using Java11/Osgi/JAXB Implementation tested somewhere?

Its tested in Glassfish for Java8. However in OSGi, where it is all loaded from classpath it should not matter if it is used on 11.

It is tested externally to be usable on module path outside of OSGi. OSGi and JPMS doesn't relate to each other.

col-panic commented 5 years ago

@lukasj now it seems to work out! I added Import-Package: com.sun.xml.bind.v2 to my consumer bundle, and extended JAXBContext.newInstance with my own classloader! Thanks a lot!

col-panic commented 5 years ago

Although the approach with extending JAXBContext.newInstance works - I don't like it that much, as it forces me to change a lot of code.

So instead I built a multi-release fragment attaching to jaxb-api, that imports the package com.sun.xml.bind.v2 for java > 8.

See https://github.com/elexis/elexis-3-core/commit/5ee9a7ee589e31563a8e6df19cae2c46b4e96e6b for the resp. patch provided to our project.

col-panic commented 5 years ago

I did a short blog post summing all the steps and troubles http://www.descher.at/descher-vu/2019/01/java-11-jaxb-and-osgi/

lukasj commented 5 years ago

you should use 2.3.2 instead of 2.4.0-b1808whaever or wait for some 2.4.0 build from this year coming from this repo

col-panic commented 5 years ago

will do, as soon as jaxb-api is publicly available in version 2.3.2, will do for the others (jaxb-osgi) right now

lukasj commented 5 years ago

It already is: https://repo1.maven.org/maven2/jakarta/xml/bind/jakarta.xml.bind-api/2.3.2/

col-panic commented 5 years ago

And with 2.3.2 we face the original error ... [java.lang.ClassNotFoundException: com.sun.xml.internal.bind.v2.ContextFactory - reminds me why I have to use 2.4.0whatever

bravehorsie commented 5 years ago

Does your environment support Multi-Release JAR Files, or does it override this functionality provided by JDK9+ in any way? On JDKs > 1.8 a class ModuleUtil referencing the old factory should not be loaded.

col-panic commented 5 years ago

I'm not sure. I use OSGi (Equinox), which from R7 supports Multi-Release Jars. It could well be, that it's behaviour is different, to that of the "plain multi-release jar support".

RaHehl commented 5 years ago

Similar problem: https://bugs.eclipse.org/bugs/show_bug.cgi?id=541264 Is there any update in this topic?

vladimirfx commented 5 years ago

And with 2.3.2 we face the original error ... [java.lang.ClassNotFoundException: com.sun.xml.internal.bind.v2.ContextFactory - reminds me why I have to use 2.4.0whatever

It is because javac inline constants. Event with Multi-Release jar support JDK 9+ implementation of ModuleUtil not used as source of constants. I've attached decompiled ContextFinder.

cf.zip

vladimirfx commented 5 years ago

Provided fix tested with Karaf 4.2.5-4.2.6 + Java 11.

krishnaUsharani commented 5 years ago

Facing same issue with jaxb 2.2.11 version. Please suggest in fixing this issue:

javax.xml.bind.DataBindingException: javax.xml.bind.JAXBException: Implementation of JAXB-API has not been found on module path or classpath.

vladimirfx commented 5 years ago

It would be nice to see 2.3.3 release ;)

CardContact commented 5 years ago

Any news on this issue ?

The latest CXF 3.3.2 in Equinox is also failing with "Implementation of JAXB-API has not been found on module path or classpath", when wired to com.sun.xml.bind:jaxb-osgi:2.3.2.

CXF also uses the JABXContext.newInstance(Class...) variant that does not allow overwriting the context class loader (see #99).

StepeCZ commented 5 years ago

Hi, I read all information on this issue, including the blog summary, but still I´m unable to get it resolved. In my case I´m not using Java modules explicitly, Im just trying to compile Java8 project on Java11/12. Based on information gathered I should be fine with adding the right dependencies on classpath in the old-school style, i.e. declaring them in Gradle.

Can someone explain why the ContextFactory class is not found despite I´m instructing the use of correct package (i.e. without "internal") via system property and I can see very well the package/class exists and the jaxb-runtime.jar is on classpath.

I have following, but still the same ClassNotFoundException:

dependencies { compile gradleApi(), localGroovy(), "com.sun.activation:javax.activation:1.2.0", "jakarta.xml.bind:jakarta.xml.bind-api:2.3.2", "com.sun.xml.bind:jaxb-osgi:2.3.2", "org.glassfish.jaxb:jaxb-xjc:2.3.2", "org.glassfish.jaxb:jaxb-core:2.3.0.1",

lukasj commented 5 years ago

@StepeCZ how does your javac configuration look like? Generally speaking passing '-release 8' with no jaxb api/impl on the classpath/modulepath to javac from JDK 11 should just work as long as there is no dependency on implementation specific classes in your sources since JAXB as such was included in JDK 8. If you have some dependency on the implementation classes then all you should need is just an implementation on the classpath (jaxb-core and/or jaxb-impl is enough for just runtime - dependening on the specific version, -osgi is just all in one bundle of core/impl/xjc/jxc, api is included in JDK 8).

StepeCZ commented 5 years ago

@lukasj Thanks for the response. The project uses JAXB as part of the Gradle build to generate classes from XSD files etc. This is done by plugin which has all these JAXB related dependencies it works well on Java 8 but fails with this error on anything > Java 11. I still havent understood why JAXB classes are not visible to the Gradle build process, perhaps there is some special treating needed ... I added the dependency to buildscript section as well, but no luck so far. I can see it is picked but error is thrown:

`` [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Resolve jaxb-runtime.jar (org.glassfish.jaxb:jaxb-runtime:2.3.2)' completed [org.gradle.internal.component.model.ComponentAttributeMatcher] Selected match org.glassfish.jaxb:jaxb-runtime:2.3.2 configuration runtime from candidates [org.glassfish.jaxb:jaxb-runtime:2.3.2 configuration runtime] for {org.gradle.dependency.bundling=external, org.gradle.jvm.version=12, org.gradle.usage=java-runtime}

lukasj commented 5 years ago

@StepeCZ I'm sorry but I have no idea about what gradle plugin nor it's version are you talking about. It could be a bug there as well. Another thing is that you said it's a problem on JDK11 first and now it is on 12. The best would be to file new issue and provide either some minimal project or steps to reproduce problems you're seeing together with environment description (OS/JDK at least). Thanks!

mseele commented 5 years ago

When will the 2.3.3 release be pushed to repositories? https://mvnrepository.com/artifact/jakarta.xml.bind/jakarta.xml.bind-api still lists 2.3.2 as latest version.

lukasj commented 5 years ago

@mseele central repository is the source of truth. Not having something available in mvnrepository.com does not necessarily imply it does not exist.

In any case, 2.3.3 is mostly ready and pushing the release itself to central is currently out of my control. I assume it is going to take ~2 weeks till it passes all necessary reviews required by https://jakarta.ee/about/jesp/

mseele commented 5 years ago

@lukasj Still no 2.3.3 release. Is there any resource where the progress of reviews, etc. is documented? Like a roadmap for the review!?

lukasj commented 5 years ago

@mseele see https://github.com/jakartaee/specifications/pull/44

zhsc commented 5 years ago

For anyone using bndtools this config seems to work:

add to your central.deps.maven (assuming using MavenBndRepository):

javax.xml.bind:jaxb-api:2.4.0-b180830.0359
com.sun.xml.bind:jaxb-osgi:2.4.0-b180830.0438
com.sun.activation:javax.activation:1.2.0

Then in your .bndrun file:

-runpath: \
    jaxb-api;version='[2.4.0,2.4.1)',\
    com.sun.xml.bind.jaxb-osgi;version='[2.4.0,2.4.1)',\
    com.sun.activation.javax.activation;version='[1.2.0,1.2.1)'

Note: the -runpath instruction will add it to the launcher's regular classpath, but include the bundles and expose those packages to the OSGi world via the systembundle for consumption. See documentation here for details

Not the most ideal since it's really bypassing the OSGi bundle mechanism's here, but it gets you going until this can be resolved.

kevin-cat commented 5 years ago

对于使用bndtools的任何人，此配置似乎都有效：

添加到您的central.deps.maven中（假设使用MavenBndRepository）：

javax.xml.bind:jaxb-api:2.4.0-b180830.0359
com.sun.xml.bind:jaxb-osgi:2.4.0-b180830.0438
com.sun.activation:javax.activation:1.2.0

然后在您的.bndrun文件中：

-runpath: \
  jaxb-api;version='[2.4.0,2.4.1)',\
  com.sun.xml.bind.jaxb-osgi;version='[2.4.0,2.4.1)',\
  com.sun.activation.javax.activation;version='[1.2.0,1.2.1)'

注意：-runpath指令会将其添加到启动器的常规类路径中，但包括捆绑软件，并将这些软件包通过systembundle公开给OSGi世界以供使用。 有关详细信息，请参见此处的文档

这不是最理想的选择，因为它实际上绕过了OSGi捆绑程序机制，但是它可以帮助您解决问题。

我添加了你说的三个依赖,已经解决了问题,3q

mathew-ferry13 commented 5 years ago

@lukasj Any update on a 2.3.3 getting pushed up to mvnrepository?

Sanne commented 5 years ago

@mseele central repository is the source of truth. Not having something available in mvnrepository.com does not necessarily imply it does not exist.

@lukasj true what matters is central, not mvnrepository.com . Please note though that while the request of others might have been unclear, it's not available in Maven Central either.

lukasj commented 5 years ago

still waiting for getting approval from ee4j PMC

mseele commented 4 years ago

@lukasj what is the problem of getting approval from ee4j PMC? Is there anything we can help with?

mathew-ferry13 commented 4 years ago

@lukasj Any update on this?

bravehorsie commented 4 years ago

2.4.0-b180830.0359 version of jsonb-api doesn't have the problematic default factory class included in case anyone is in haste for the fix. I guess it can be safely used besides its beta, because the only significant change between this version and curretnly the latest 2.3.1 in public repository was reintroducing problematic ".internal" package.