Add Jakarta XML Bind to the bootclasspath #23390
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Steve Millidge <[email protected]>
Signed-off-by: Steve Millidge <[email protected]>
hs536
approved these changes
Feb 26, 2021
|
This bootclasspath has been added to avoid the effects of JEP 320. These packages are heavily involved in starting GlassFish. |
|
I am not able to replicate this issue on a Windows environment with current master (1b7bbe9). Please see attached server logs My reason for not needing the jakarta.xml-bind-api in the bootclasspath is it is anyway going to be loaded by felix at startup. It works in GlassFish 6.0 without bootclasspath. |
|
@smillidge -> succeeded for access and the login to a admin console (https://:4848/). |
lukasj
reviewed
Feb 26, 2021
There was a problem hiding this comment.
adding a library to bootclasspath in order to fix some issues with "end-user" app does not look like a best way to go since there is nothing to override from JDK - at least not in terms of JAXB. I hope it's already resolved by something else - based on other comments ;-)
|
Strange I built latest master and couldn't access admin console and quicklook failed without this fix. Maybe I have an old dependency somewhere. |
|
you may want to try activation 2.0.1 + jaxb-api 3.0.1 + jaxb-osgi 3.0.1-b01 - they are available in staging for testing purposes as it is not yet clear how to proceed with service releases of spec projects. But it should be fine for you as long as you don't publish anything having these dependencies outside of temporary/staging areas. Also note that they may change anytime without prior notice untill they get to central. EDIT: I'm not sure that is going to help. The point is that these dependencies, especially jaxb, have few fixes which may have some impact on things in GF, ie eclipse-ee4j/jaxb-ri#1466 (comment) |
|
OK even weirder this PR now has the exact same test failures that I saw and that this PR was intending to fix!!! |
|
I will close this and investigate my build |
|
I have this issue now in the current master: |
|
Yeah I can't get rid of it. I deleted all my Jersey, JAXB etc. jars in my maven repo to refresh them and still have the issue. |
|
The core problem stems from nasty and obscure class loading hacks and workarounds: public static JAXBContext getJAXBContextFromWadlGenerator(WadlGenerator wadlGenerator) throws JAXBException {
JAXBContext jaxbContextCandidate = null;
final ClassLoader contextClassLoader = AccessController.doPrivileged(ReflectionHelper.getContextClassLoaderPA());
try {
// Nasty ClassLoader magic. JAXB-API has some strange limitation about what class loader can
// be used in OSGi environment - it must be same as context ClassLoader. Following code just
// workarounds this limitation
// see JERSEY-1818
// see JSR222-46
final ClassLoader jerseyModuleClassLoader =
AccessController.doPrivileged(ReflectionHelper.getClassLoaderPA(wadlGenerator.getClass()));
AccessController.doPrivileged(ReflectionHelper.setContextClassLoaderPA(jerseyModuleClassLoader));Maybe having Jersey core import JAX-B explicitly would help here, since it tries to load JAX-B specifically via the |
|
And additionally, the point where the exception is triggered in Class ctxFactory = (Class) ServiceLoaderUtil.lookupUsingOSGiServiceLoader(
"jakarta.xml.bind.JAXBContext", logger);
if (ctxFactory != null) {
return newInstance(contextPath, contextPathClasses, ctxFactory, classLoader, properties);
}
It then specifically tries to execute this line: // first check the method that takes Map as the third parameter.
// this is added in 2.0.
try {
Method m = spFactory.getMethod("createContext", String.class, ClassLoader.class, Map.class);Which causes Java to inspect the type, find cc @lukasj |
|
Actually, come to think of it. @lukasj, why is |
|
@smillidge @lukasj I think the presence of |
|
@arjantijms I haven't had a chance to get there yet. Sill fighting between saaj and jax-ws, metro will follow. But I believe only |
|
The -rt version came in here:
Maybe there are some other issues as well, but this definitely doesn't feel right to start with. After that we need to update jaxb indeed. Thanks! |
|
@lukasj the latest jaxb updates completely destroy GF. It's literally raining exceptions after updating to them. Changes:
Some of the exceptions are: |
|
@arjantijms I have to get there first, I haven't had a chance to test it myself yet, still fixing the road there... QL on v6-final shown no issues on my end. That is the only thing I've tried so far |
|
@lukasj okay, I'll try again when you are a bit further. Thanks! |
|
@arjantijms not sure if you noticed the change in classoladers between JDK 8 and 11, there is nice description in jakartaee/jax-ws-api#161 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #23361
@lukasj @hussainnm you may object to this one as you both advocated removing Jakarta XML Binding from the bootclasspath so I'm open to alternative PRs.
Signed-off-by: Steve Millidge [email protected]