Issue Details (XML | Word | Printable)

Key: GLASSFISH-20444
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Jakub Podlesak
Reporter: Jakub Podlesak
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

EclipseLink MOXy bundle throws CNFE in Web Profile due to unsatisfied javax.xml.bind package import

Created: 30/Apr/13 07:09 PM   Updated: 09/May/13 05:10 PM   Resolved: 09/May/13 05:10 PM
Component/s: jax-rs
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0

Time Tracking:
Not Specified

Issue Links:
Related
 

Tags: 4_0-approved
Participants: blaise_doughan, Jakub Podlesak, Marek Potociar, Sanjeeb Sahoo and Tom Mueller


 Description  « Hide

This was revealed when integrating final Jersey 2.0 bits into GF. (Jersey auto-discoverable MOXy providers has been enabled in the final Jersey 2.0 version)

Following is an excerpt from modules/org.eclipse.persistence.moxy.jar:

Import-Package: com.sun.xml.bind;resolution:=optional,com.sun.xml.bind
 .annotation;resolution:=optional,javax.activation;resolution:=optiona
 l,javax.ws.rs;resolution:=optional,javax.ws.rs.core;resolution:=optio
 nal,javax.ws.rs.ext;resolution:=optional,javax.xml.bind;version="2.0.
 0";resolution:=optional,javax.xml.bind.annotation;version="2.0.0";res
 olution:=optional,javax.xml.bind.annotation.adapters;version="2.0.0";
 resolution:=optional,javax.xml.bind.attachment;version="2.0.0";resolu
 tion:=optional,javax.xml.bind.helpers;version="2.0.0";resolution:=opt
 ional

javax.xml.bind.* packages should not be marked optional, but that is IMHO only a minor bug,
that i am going to file separately.

Now in the full GlassFish profile, the java.xml.bind dependency gets resolved just fine from the bundled JAXB implementation:

gogo$ inspect p r 216 | grep jaxb
javax.xml.bind.annotation.adapters; version=2.2.7 -> jaxb-api [2]
javax.xml.bind.annotation; version=2.2.7 -> jaxb-api [2]
javax.xml.bind.attachment; version=2.2.7 -> jaxb-api [2]
javax.xml.bind; version=2.2.7 -> jaxb-api [2]
javax.xml.bind.helpers; version=2.2.7 -> jaxb-api [2]
gogo$

While in web profile distribution, JAXB is taken from the Java runtime, and exported with the default
version (0.0.0.0), which leaves the import unsatisfied:

gogo$ inspect p r 166 | grep jaxb
gogo$
gogo$ inspect p r 166
org.eclipse.persistence.moxy [166] imports packages:
----------------------------------------------------
javax.activation; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.namespace; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.stream; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform.dom; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform.sax; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform.stax; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform.stream; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.validation; version=0.0.0 -> org.apache.felix.framework [0]
org.w3c.dom; version=0.0.0 -> org.apache.felix.framework [0]
org.xml.sax; version=0.0.0 -> org.apache.felix.framework [0]
javax.ws.rs; version=2.0.0 -> javax.ws.rs-api [112]
javax.ws.rs.core; version=2.0.0 -> javax.ws.rs-api [112]
javax.ws.rs.ext; version=2.0.0 -> javax.ws.rs-api [112]
org.eclipse.persistence.internal.libraries.asm; version=3.3.1 -> org.eclipse.persistence.asm [160]
...


Jakub Podlesak added a comment - 30/Apr/13 07:11 PM

The following patch resolves the bug for me:

Index: nucleus/osgi-platforms/felix/src/main/resources/config/osgi.properties
===================================================================
--- nucleus/osgi-platforms/felix/src/main/resources/config/osgi.properties      (revision 61743)
+++ nucleus/osgi-platforms/felix/src/main/resources/config/osgi.properties      (working copy)
@@ -410,12 +410,12 @@

 endorsed-standard-packages=\
  javax.annotation, \
- javax.xml.bind, \
- javax.xml.bind.annotation, \
- javax.xml.bind.annotation.adapters, \
- javax.xml.bind.attachment, \
- javax.xml.bind.helpers, \
- javax.xml.bind.util, \
+ javax.xml.bind;version="2.0.0", \
+ javax.xml.bind.annotation;version="2.0.0", \
+ javax.xml.bind.annotation.adapters;version="2.0.0", \
+ javax.xml.bind.attachment;version="2.0.0", \
+ javax.xml.bind.helpers;version="2.0.0", \
+ javax.xml.bind.util;version="2.0.0", \
  javax.jws, \
  javax.jws.soap, \
  javax.xml.ws, \

Jakub Podlesak added a comment - 30/Apr/13 07:33 PM

Including also excerpt from the server.log, when the bug was first revealed:

java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2442)
	at java.lang.Class.privateGetPublicMethods(Class.java:2562)
	at java.lang.Class.getMethods(Class.java:1427)
	at org.glassfish.jersey.server.model.MethodList.getMethods(MethodList.java:106)
	at org.glassfish.jersey.server.model.MethodList.<init>(MethodList.java:93)
...
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException not found by org.eclipse.persistence.moxy [168]
	at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)
	at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)

Jakub Podlesak added a comment - 30/Apr/13 07:39 PM

Increased priority, as this bug actually blocks Jersey 2.0 final bits integration into GlassFish.


Jakub Podlesak added a comment - 01/May/13 12:45 AM - edited

Added 4_0-review tag, required info for the review follow:

  • What is the impact on the customer of the bug?
  • Jersey 2.0 can not be integrated without this bug being resolved (full profile would be fine, but there are ql test failures in the web profile)
  • MOXy JAX-RS providers will not work in web profile
  • What is the cost/risk of fixing the bug?
  • a patch is already available, certain risk is there as quite a low level layer is affected, however all ql tests has passed with the patch applied
  • Is there an impact on documentation or message strings?
  • There is no such impact.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
  • JAXB related tests
  • Which is the targeted build of 4.0 for this fix?
  • b87

Sanjeeb Sahoo added a comment - 01/May/13 04:11 PM

Jakub,

I don't know who is responsible for integrating moxy, so I am assigning this to you so that you can reassign if need be. We don't export Java SE packages with versions as SE team does not maintain package versions. They release the whole platform as one version. So, we only version packages that we distribute via our modules. In case moxy can't modify its import to relax the version constraint, I suggest we use a framework extension bundle as discussed in [1] to satisfy its requirement when running in GlassFish environment.

Sahoo

[1] https://weblogs.java.net/blog/ss141213/archive/2009/05/use_of_framewor.html?force=357


blaise_doughan added a comment - 01/May/13 10:24 PM

Sahoo,

The Full Profile doesn't require the extension bundle, shouldn't the Web Profile be changed to match the Full Profile WRT the JAXB dependency instead of pulling it from Java SE?

-Blaise


Sanjeeb Sahoo added a comment - 02/May/13 03:46 AM

No, we don't want to override JAXB in web profile when Java SE provided one is sufficient. Actually, thinking more, there is even a better alternative, but that will require change to moxy. If moxy makes the following change, then we would be fine as well:

Let moxy import JAXB packages with version = 0.0.0. Some had objected that it would mean someone can actually try to run it with JAXB1 and face issues. To avoid that, moxy bundle can add the following header:

Bundle-RequiredExecutionEnvironment: JavaSE-1.6

This would mean that it can run on Java SE 6 and above and all those JREs include JAXB 2. It would prevent moxy to resolve on lesser JREs.

Thanks,
Sahoo


Jakub Podlesak added a comment - 02/May/13 09:31 AM

The above suggestion relies on the fact JAXB packages are exported from the system bundle, but it is not guaranteed IIUC.
So the import could still fail. Also the fact that while JAXB 2.0 is required by the MOXy bundle, it's import
header would state the JAXB version does not matter is alarming. The only thing that needs to be fixed in the MOXy bundle
headers is IMHO to remove the optional import parameter.


Sanjeeb Sahoo added a comment - 02/May/13 10:18 AM - edited

Since there is no real standard governing JAXB package version, moxy requiring javax.xml.bind; version=2.0.0 can be troublesome for moxy bundle in some environment, where as dependence on an execution environment is a more portable solution with same effect. Moreover, it would require no changes in glassfish side. Having said that I just noticed that moxy depends on com.sun.xml.bind, so for that to resolve we may need a framework extension anyway. So, I will let someone experiment to chose one of the alternatives.


Jakub Podlesak added a comment - 03/May/13 06:47 PM

Sending appserver/packager/glassfish-jpa/pom.xml
Adding appserver/persistence/jaxb-exporting-fragment
Adding appserver/persistence/jaxb-exporting-fragment/pom.xml
Sending appserver/persistence/pom.xml
Sending appserver/web
Sending nucleus/pom.xml
Transmitting file data ....
Committed revision 61822.

Fix based on the newly introduced system fragment submitted together with the final 2.0 Jersey integration.


Jakub Podlesak added a comment - 03/May/13 06:47 PM

Fix submitted.


Tom Mueller added a comment - 03/May/13 08:03 PM

Please commit the change to the trunk also and correctly indicate the fixed versions in the fix version field.
When you resolve the bug, please indicate the revision for the trunk as well as the 4.0 branch.
Reopening the issue.


Jakub Podlesak added a comment - 06/May/13 07:24 PM

The change has been backed out from the 4.0 and has never been submitted into the main trunk.
The rollback was done as the fix broke QL tests run against the full profile with security manager turned on.


Marek Potociar added a comment - 09/May/13 05:10 PM

Jersey 2.0 integration has succeeded.