Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue #12094 restore classloader association during comp/env creation #12107

Conversation

janbartel
Copy link
Contributor

Closes #12094

We removed explicit association/disassociation of the webapp classloader to use to create or find the appropriate java:comp/env naming context from EnvConfiguration. This is not a problem for code running in the distribution. However, if embedded code:

  • fails to create an EE level classloader as the parent loader for all webapps
  • pre-creates the java:comp naming Context using the common application classloader
  • starts multiple WebAppContexts

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:

void run() throws Exception
{
        new InitialContext().lookup("java:comp");

       WebAppContext webappA = new WebAppContext();
       WebAppContext webbappB = new WebAppContext();
}

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):

void run() throws Exception
{
      //create useless "EE" parent classloader for webapps before creating java:comp
       Thread.currentThread().setContextClassLoader(new URLClassLoader(new URL[]{}, Thread.currentThread().getContextClassLoader());
        new InitialContext().lookup("java:comp");

       WebAppContext webappA = new WebAppContext();
       WebAppContext webbappB = new WebAppContext();
}

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.

@janbartel janbartel merged commit 54fde0e into jetty-12.0.x Aug 4, 2024
10 checks passed
@janbartel janbartel deleted the jetty-12.0.x-12094-restore-classloader-association-for-jndi branch August 4, 2024 06:48
@erdi
Copy link

erdi commented Aug 5, 2024

I would like to test this fix out, @janbartel. Are there any nightly builds being published for the project? I tried googling for nightlies but sadly without any luck.

@olamy
Copy link
Member

olamy commented Aug 5, 2024

@erdi snapshots are deployed daily here https://oss.sonatype.org/content/repositories/jetty-snapshots

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

Possible regression in ContextFactory.getObjectInstance() between Jetty 11.0.22 and 12.0.11
3 participants