Hi,
As mentioned on jakartaee-platform-dev ml , it looks like https://github.com/eclipse-ee4j/jaxrs-api/blob/master/jaxrs-api/src/main/java/jakarta/ws/rs/core/Link.java#L28 depends on (optional in Jakarta EE 9 Full Platform Spec) Jakarta XML Binding.
jakarta.xml.bind (JAXB) is optional in Jakarta EE 9 Platform SPEC as per 6.32. XML Binding 3.0 Requirements (Optional) but Jakarta RESTful Web Services is Required.
How can the jakarta.ws.rs.core.Link class be used in Jakarta EE 9 Full Platform implementations that do not include a jakarta.xml.bind (JAXB) implementation? Other Jakarta RESTful Web Services SPEC API classes do reference the Link class as well.
It's an unfortunate dependency we've been carrying for a while. I don't really see how this could be fixed for EE 9 without introducing a backward incompatible change to JAX-RS, in the Link class. Seems like we're caught between a rock and a hard place on this one.
What is the current goal for what happens when say the Configurable class definition is loaded without JAXB on the classpath?
It looks like within JAX-RS, ClientResponseContext references Link. ClientResponseFilter references ClientResponseContext and Configurable references ClientResponseFilter. Configurable is referenced by other classes.
I tried running the following with java -verbose:class jaxrs | grep jakarta.ws.rs:
public class jaxrs {
public static void main(String args[]) {
try {
jaxrs.class.getClassLoader().loadClass("jakarta.ws.rs.client.ClientResponseContext");
jaxrs.class.getClassLoader().loadClass("jakarta.ws.rs.client.ClientResponseFilter");
jaxrs.class.getClassLoader().loadClass("jakarta.ws.rs.core.Configurable");
} catch(Throwable t) {
}
}
}
Output:
java -verbose:class jaxrs | grep jakarta.ws.rs
[Loaded jakarta.ws.rs.client.ClientResponseContext from file:/home/smarlow/jars/jakarta.ws.rs-api-3.0.0-M1.jar]
[Loaded jakarta.ws.rs.client.ClientResponseFilter from file:/home/smarlow/jars/jakarta.ws.rs-api-3.0.0-M1.jar]
[Loaded jakarta.ws.rs.core.Configurable from file:/home/smarlow/jars/jakarta.ws.rs-api-3.0.0-M1.jar]
As mentioned on https://github.com/eclipse-ee4j/jakartaee-tck/pull/511#issuecomment-696717963, we tried to run the jaxrs TCK without jaxb on the classpath however, glassfish wouldn't start.
https://github.com/eclipse-ee4j/jakartaee-tck/pull/511 is approved and tested for updating the TCK, so please expect that to be merged today.
As far as I'm concerned I think this issue can be closed, unless others have suggestions for other changes that should be made for this issue.
Thanks for testing that Scott. I updated your test case to also load
jakarta.ws.rs.core.Link to see if it would automatically load the "Jaxb*"
inner classes.
public class jaxrs {
public static void main(String args[]) {
try {
jaxrs.class.getClassLoader().loadClass("jakarta.ws.rs.client.ClientResponseContext");
jaxrs.class.getClassLoader().loadClass("jakarta.ws.rs.client.ClientResponseFilter");
jaxrs.class.getClassLoader().loadClass("jakarta.ws.rs.core.Configurable");
jaxrs.class.getClassLoader().loadClass("jakarta.ws.rs.core.Link");
} catch(Throwable t) {
}
}
}
Output:
class load: jakarta.ws.rs.client.ClientResponseContext from:
file:/Users/andymc/dev/jakarta-jaxrs/jaxrs-api/jaxrs-api/target/jakarta.ws.rs-api.jar
class load: jakarta.ws.rs.client.ClientResponseFilter from:
file:/Users/andymc/dev/jakarta-jaxrs/jaxrs-api/jaxrs-api/target/jakarta.ws.rs-api.jar
class load: jakarta.ws.rs.core.Configurable from:
file:/Users/andymc/dev/jakarta-jaxrs/jaxrs-api/jaxrs-api/target/jakarta.ws.rs-api.jar
class load: jakarta.ws.rs.core.Link from:
file:/Users/andymc/dev/jakarta-jaxrs/jaxrs-api/jaxrs-api/target/jakarta.ws.rs-api.jar
class load: java/util/IdentityHashMap$IdentityHashMapIterator from:
jrt:/java.base
class load: java/util/IdentityHashMap$KeyIterator from: jrt:/java.base
class load: com/ibm/tools/attach/target/AttachHandler$1 from:
jrt:/java.base
class load: java/util/Vector$Itr from: jrt:/java.base
class load: java/lang/Thread$State from: jrt:/java.base
So, loading the Link "outer" class does not automatically load the
JaxbAdapter / JaxbLink inner classes. I'm in agreement that we shouldn't
need to make any further changes to the spec or javadocs.
Do we also need to update the TCK to avoid reporting failures when XML
Binding is not present? (i.e. assumeThat(canLoadXMLBindingClasses())?)
If so, I can try to take a look at making some of those changes.
Thanks,
Andy
On Tue, Sep 22, 2020 at 8:48 AM Scott Marlow notifications@github.com
wrote:
I tried running the following with java -verbose:class jaxrs | grep
jakarta.ws.rs:public class jaxrs {
public static void main(String args[]) {
try {
jaxrs.class.getClassLoader().loadClass("jakarta.ws.rs.client.ClientResponseContext");
jaxrs.class.getClassLoader().loadClass("jakarta.ws.rs.client.ClientResponseFilter");
jaxrs.class.getClassLoader().loadClass("jakarta.ws.rs.core.Configurable");
} catch(Throwable t) {
}
}
}Output:
java -verbose:class jaxrs | grep jakarta.ws.rs
[Loaded jakarta.ws.rs.client.ClientResponseContext from file:/home/smarlow/jars/jakarta.ws.rs-api-3.0.0-M1.jar]
[Loaded jakarta.ws.rs.client.ClientResponseFilter from file:/home/smarlow/jars/jakarta.ws.rs-api-3.0.0-M1.jar]
[Loaded jakarta.ws.rs.core.Configurable from file:/home/smarlow/jars/jakarta.ws.rs-api-3.0.0-M1.jar]As mentioned on eclipse-ee4j/jakartaee-tck#511 (comment)
https://github.com/eclipse-ee4j/jakartaee-tck/pull/511#issuecomment-696717963,
we tried to run the jaxrs TCK without jaxb on the classpath however,
glassfish wouldn't start.eclipse-ee4j/jakartaee-tck#511
https://github.com/eclipse-ee4j/jakartaee-tck/pull/511 is approved and
tested for updating the TCK, so please expect that to be merged today.As far as I'm concerned I think this issue can be closed, unless others
have suggestions for other changes that should be made for this issue.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/eclipse-ee4j/jaxrs-api/issues/906#issuecomment-696733737,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFDAEM5LZEYEPW7GKP5CGXDSHCTK5ANCNFSM4RQ4KUSA
.
Do we also need to update the TCK to avoid reporting failures when XML Binding is not present? (i.e.
assumeThat(canLoadXMLBindingClasses())?) If so, I can try to take a look at making some of those changes.
No, currently, when running the TCK with xml_binding keyword specified a ClassNotFoundException should let the JAXRS implementor know that they forgot to include the XML binding classes on the test classpath.
@andymc12 Tested that type of loading as well today after I saw the comment from @scottmarlow. Must admit I was a bit surprised, but it seems that all the JAXB deps are in the static inner classes and those are not eagerly loaded, which is great.
This was in informative analysis of the dependency problem, but as stated by others, no need to keep this one open anymore.
Most helpful comment
@andymc12 Tested that type of loading as well today after I saw the comment from @scottmarlow. Must admit I was a bit surprised, but it seems that all the JAXB deps are in the static inner classes and those are not eagerly loaded, which is great.