Issue #12094 restore classloader association during comp/env creation #12107
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.
Closes #12094
We removed explicit association/disassociation of the webapp classloader to use to create or find the appropriate
java:comp/env
naming context fromEnvConfiguration
. This is not a problem for code running in the distribution. However, if embedded code:java:comp
namingContext
using the common application classloaderWebAppContexts
then those webapps all wind up trying to share the same
java:comp/env
environment. The relevant example code, paraphrased from #12094, is as follows:Main.java:
So we could require that embedded users create an empty classloader that emulates the EE classloader, but does nothing (because as all classes are on the application classloader instead):
However, I think it's reasonable that "naive" code (ie that doesn't know about the new EE classloader level) should be able to work. So this PR re-introduces the associate/disassociate idiom that was used before. This allows embedded code to work, as well as apps using the distribution.