Invalid JAXB default factory class on JavaSE 11 #78
Comments
|
Facing the same problem here, porting my application (to java version "11.0.1" 2018-10-16 LTS). Starting the application leaves me with |
|
this should be fixed in 2.3.2, right @bravehorsie ? |
|
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. |
|
Not yet, it's available only for testing in the sonatype's staging repo (so still subject to change) |
|
As soon, as @bravehorsie might confirm that a patch is already provided in 2.3.2 i could test it for my scenario! |
|
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. |
|
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. |
|
@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. |
|
@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? |
|
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 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 com.sun.xml.bind.v2.ContextFactory is in org.glassfish.jaxb:jaxb-runtime artifact. The ClassNotFound error probably means that you either:
Yes, that would work, but after configuring jaxb properly you should not need it. |
|
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:
|
|
@bravehorsie thanks, ... this is a real pain, so there seem two be 2 possible solutions in an OSGI setting
Why does the classloader in Is the whole setting of using Java11/Osgi/JAXB Implementation tested somewhere? |
|
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) |
|
@lukasj Thank you very much for that hint, I think it works now! With |
|
@lukasj it only works with my manually modified version of jaxb-api, where I additionally add |
|
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 |
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. |
|
@lukasj now it seems to work out! I added |
|
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 See elexis/elexis-3-core@5ee9a7e for the resp. patch provided to our project. |
|
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/ |
|
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 |
|
will do, as soon as jaxb-api is publicly available in version 2.3.2, will do for the others (jaxb-osgi) right now |
|
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 |
|
Does your environment support Multi-Release JAR Files, or does it override this functionality provided by JDK9+ in any way? |
|
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". |
|
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.
|
|
It would be nice to see 2.3.3 release ;) |
|
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). |
|
Hi, I read all information on this issue, including the blog summary, but still I´m unable to get it resolved. 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 { |
|
@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). |
|
@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. `` |
|
@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! |
|
When will the 2.3.3 release be pushed to repositories? |
|
@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/ |
|
@lukasj Still no 2.3.3 release. Is there any resource where the progress of reviews, etc. is documented? |
|
For anyone using bndtools this config seems to work: add to your central.deps.maven (assuming using MavenBndRepository): Then in your .bndrun file: 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. 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. |
我添加了你说的三个依赖,已经解决了问题,3q |
|
@lukasj Any update on a 2.3.3 getting pushed up to mvnrepository? |
@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. |
|
still waiting for getting approval from ee4j PMC |
|
@lukasj what is the problem of getting approval from ee4j PMC? Is there anything we can help with? |
|
@lukasj Any update on this? |
|
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. |
|
version 2.4.0-b180830.0359 has different license - may or may not be an issue. in any case ballot for 2.3.3 has already been started, see https://www.eclipse.org/lists/jakarta.ee-spec/msg00593.html for details |
|
Hello,
|
Solved it for me, thank you! |
|
Still having the issue with following dependencies in the classpath running on JDK11 (oracle): <dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>2.3.3</version>
</dependency>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.3</version>
</dependency>What do you suggest ? |
|
See my comment here, when current thread classloader is a |
|
Here is my solution using JAXB 2.3.3 (on jdk8 to 16) to explicitely define the ContextFactory class: |
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
The text was updated successfully, but these errors were encountered: