New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid JAXB default factory class on JavaSE 11 #78

Open
bravehorsie opened this Issue Nov 8, 2018 · 28 comments

Comments

Projects
None yet
3 participants
@bravehorsie
Copy link
Contributor

bravehorsie commented Nov 8, 2018

    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

This comment has been minimized.

Copy link

col-panic commented Dec 12, 2018

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

This comment has been minimized.

Copy link
Member

lukasj commented Dec 12, 2018

this should be fixed in 2.3.2, right @bravehorsie ?

@col-panic

This comment has been minimized.

Copy link

col-panic commented Dec 12, 2018

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

This comment has been minimized.

Copy link
Member

lukasj commented Dec 12, 2018

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

@col-panic

This comment has been minimized.

Copy link

col-panic commented Dec 12, 2018

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

This comment has been minimized.

Copy link

col-panic commented Dec 12, 2018

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

This comment has been minimized.

Copy link
Contributor Author

bravehorsie commented Dec 12, 2018

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

This comment has been minimized.

Copy link
Contributor Author

bravehorsie commented Dec 12, 2018

@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

This comment has been minimized.

Copy link

col-panic commented Dec 12, 2018

@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

This comment has been minimized.

Copy link

col-panic commented Dec 13, 2018

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

This comment has been minimized.

@bravehorsie

This comment has been minimized.

Copy link
Contributor Author

bravehorsie commented Dec 13, 2018

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

  • haven't put jaxb-runtime jar at class path or module path at all
  • have put it to module path but didn't add com.sun.xml.bind module to module graph with either --add-modules or by requiring in your project module.
  • put jaxb-api to module path and jaxb-runtime to classpath and so API doesn't read the implementation in order to create factory.

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

This comment has been minimized.

Copy link
Member

lukasj commented Dec 13, 2018

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

This comment has been minimized.

Copy link

col-panic commented Dec 13, 2018

@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

This comment has been minimized.

Copy link
Member

lukasj commented Dec 13, 2018

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

This comment has been minimized.

Copy link

col-panic commented Dec 13, 2018

@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

This comment has been minimized.

Copy link

col-panic commented Dec 13, 2018

@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

This comment has been minimized.

Copy link
Member

lukasj commented Dec 13, 2018

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

This comment has been minimized.

Copy link
Contributor Author

bravehorsie commented Dec 13, 2018

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

This comment has been minimized.

Copy link

col-panic commented Dec 13, 2018

@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

This comment has been minimized.

Copy link

col-panic commented Jan 21, 2019

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 elexis/elexis-3-core@5ee9a7e for the resp. patch provided to our project.

@col-panic

This comment has been minimized.

Copy link

col-panic commented Jan 21, 2019

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

This comment has been minimized.

Copy link
Member

lukasj commented Jan 21, 2019

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

This comment has been minimized.

Copy link

col-panic commented Jan 24, 2019

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

This comment has been minimized.

Copy link
Member

lukasj commented Jan 24, 2019

@col-panic

This comment has been minimized.

Copy link

col-panic commented Jan 24, 2019

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

This comment has been minimized.

Copy link
Contributor Author

bravehorsie commented Jan 25, 2019

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

This comment has been minimized.

Copy link

col-panic commented Jan 26, 2019

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".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment