Community
Participate
Working Groups
If the javax.xml.bind bundle is used with com.sun.xml.bind on Java 5 which does not ship with a JAXB binding (only Java 6 does) a ClassNotFoundException exception occurs when a JAXBContext.newInstance() is invoked (see bug 325176). I believe javax.xml.bind needs to specify a dependency or buddy policy in order to be able to load classes from com.sun.xml.bind.
Created attachment 178779 [details] fix
(In reply to comment #0) > I believe javax.xml.bind needs to specify a dependency or buddy policy in order > to be able to load classes from com.sun.xml.bind. Well, javax.xml.bind should be able to load classes from com.sun.xml.bind just fine ... are you saying the reverse? That javax.xml.bind "finds" the factory in com.sun.xml.bind but then the sun package class tries to load something from java.xml.bind? I think that "reversed" situation is what requires buddy class loading.
Oh, you are saying there's no dependency specified between the two?
The com.sun.xml.bind bundle does depend on javax.xml.bind but that does not help with this problem. The standard way of creating a JAXB context is through invoking the factory defined in the javax.xml.bind package. This works fine on Java 6 where the implementation and API live in the system.bundle class loader since the javax.xml.bind package comes from the JDK and not the Orbit bundle. On Java 5 the javax.xml.bind Orbit bundle tries to create an instance of a class that comes from com.sun.xml.bind which fails since it can't actually see it (no idea how it knows what class to create but it does know). This is very similar to how factories such as TransferFormerFactory in the Java XML API work. Did this problem ever arise with the javax.xml bundle?
We have a similar requirement with SLF4J bundles. It tries to load classes from other bundles contributed at runtime. Buddy-Classloading is one option but not the best one. A better one could be fragments in combination with the extensible API header.
I've not see it with the javax.xml bundle, but never saw a case there the factory was in a different bundle (either in vm, or a bundle dependency). Can't say I understand it completely, but I've not issue applying the patch if you know for sure that'll help, and you really (really) need it to run on Java 1.5 (I say it that way, since sounded like in original post, the user was accidentally use java 1.5, that he didn't need to). There's a lot of "contact names" listed for this one ... so, I'll add them to CC and see if any of them have any advice.
There's a number of versions of JAXB and the Sun implementation registered with Orbit, and I am pretty sure that this worked without issue for the version of JAXB that I had submitted (2.1.9), because we shipped it as product with Galileo. I'm certainly not against applying the patch if it fixes the issue.
Was this patch tested with multiple versions of com.sun.xml.bind in place? I think there is an issue which might cause incompatible versions registered with each other in future releases.
I don't see any differences with the 2.1.9 version of the JAXB bundle but I'll try it. Does Orbit have JUnit tests?
(In reply to comment #9) > ... Does Orbit have JUnit tests? No. There are a few "releng tests" ran, just to confirm results are in right form, etc., but nothing really "runs".
The solution should not require that the javax.xml.bind bundle load com.sun.xml.bind bundle. This is because a JAXB impl other than the reference implementation may be used, such as EclipseLink JAXB.
(In reply to comment #9) > I don't see any differences with the 2.1.9 version of the JAXB bundle but I'll > try it. Does Orbit have JUnit tests? Sorry, I was talking about running multiple versions concurrently (OSGi is about running multiple versions at the same time). It should only tie versions together that belong together. (In reply to comment #11) > The solution should not require that the javax.xml.bind bundle load > com.sun.xml.bind bundle. This is because a JAXB impl other than the reference > implementation may be used, such as EclipseLink JAXB. How do you currently enable this? Lets say both impl bundles are installed, who decides which one to instantiate and how?
Created attachment 178886 [details] simple test
> Sorry, I was talking about running multiple versions concurrently (OSGi is about > running multiple versions at the same time). It should only tie versions > together that belong together. The package imports in the com.sun.xml.bind packages would need to specify version constraints accordingly to ensure that right versions get wired together. Currently com.sun.xml.bind does not specify any constraints on the javax.xml.bind imports which would need to get fixed. > (In reply to comment #11) > > The solution should not require that the javax.xml.bind bundle load > > com.sun.xml.bind bundle. This is because a JAXB impl other than the reference > > implementation may be used, such as EclipseLink JAXB. > > How do you currently enable this? Lets say both impl bundles are installed, who > decides which one to instantiate and how? Isn't this non deterministic to some degree? The JAXB API has some sort of lookup order to find the implementation but in the end it might depend on what bundle it comes across first. I ran a few more tests with various version of JAXB and Java. If I specify a version constraint on javax.xml.bind in the package import of the test bundle and run on Java 6 I get this error: java.lang.NullPointerException at javax.xml.bind.ContextFinder.handleClassCastException(ContextFinder.java:95) at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:204) at javax.xml.bind.ContextFinder.find(ContextFinder.java:375) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565) at org.eclipse.orbit.tests.javax.xml.bind.JAXBTest.testNewInstance(JAXBTest.java:14) I believe this is caused by the javax.xml.bind package coming from two different sources, the JRE and the javax.xml.bind bundle. This should be solved by adding a requirement on system.bundle to javax.xml.bind. I'll attach a new patch which worked in the various combinations of package imports and Java versions but we'll probably end up wiring Mylyn to the concrete JAXB implementation in com.sun.xml.bind and not rely on the factory provided by javax.xml.bind to avoid any funny problems.
Created attachment 178888 [details] fix for all versions expect javax.xml.bind 2.0.0
This is getting pretty old. Still an issue? What action is desired here? (I've only skimmed previous comments ... just enough to make my head spin :)
I believe that using JAXBContext.newInstance() with the current javax.xml bundles does not work. Allowing JAXB implementations to register as a buddy as proposed in the patch would be one way to fix it. Another work-around, which we used for Mylyn, is to instantiate the JAXB implementation directly instead of going through the factory. So... it's not fixed but there is a work-around. I can't tell if it's worth taking action or if there are better solutions than the proposed patch. I would leave this report open though for documentation purposes and to gather more input in case other consumers run into the same problem.
Ok, we'll just leave this open as an enhancement request, and see if anyone has any other advice or needs. Maybe if nothing comes up by Indigo release, close as 'won't fix'. Thank you.
There is another related problem that causes the Mylyn Hudson integration to fail when it is used on Java 1.6 with the JEE package: bug 345149: java.lang.VerifyError when connecting to Jenkins server with JEE package. As far as I can tell, this is happening because javax.xml.bind 2.1.9 is already part of the JEE package and getting javax.xml.bind 2.2.0 installed in addition causes the VerifyError. I haven't verified if the patch fixes it but wanted to record it here in case someone else encounteres the same problem.
Assigning to Blaise as most recent "contact" for this bundle. Blaise, can you assess and/or commit patches if appropriate? I'm assuming, at this late date, this would be for Juno only ... not part of Indigo SR2.
