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

Allow better configuration of WebAppContext classloader #10163

Merged
merged 4 commits into from
Aug 11, 2023

Conversation

gregw
Copy link
Contributor

@gregw gregw commented Jul 27, 2023

Moved the creation of a WebAppContext classloader into an extensible method.

Moved the creation of a WebAppContext classloader into an extensible method.
@gregw gregw added the Sponsored This issue affects a user with a commercial support agreement label Jul 27, 2023
Copy link
Contributor

@lachlan-roberts lachlan-roberts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need this for EE8/EE9.

if (loader instanceof URLClassLoader)
((URLClassLoader)loader).close();
if (loader instanceof URLClassLoader urlClassLoader)
urlClassLoader.close();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this break a restart of the context?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good question... But existing behavior

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lachlan-roberts I cleaned this up. Can you re-review?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I understand the purpose of this... Can you explain the logic behind this change?

loader will always be a WebAppClassLoader so this will never be true, unless there is an overridden configureClassLoader configured to return a URLClassLoader. If this is the case can't they also override stopContext and close it themselves?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lachlan-roberts WebAppClassLoader is-a URLClassLoader, so this will always be true when the current loader is not the initial loader (i.e. we created the loader during doStart). So probably could assume that, but instanceof check is nice way to do the caste without a warning.

Only close loader if context created it.
@joakime
Copy link
Contributor

joakime commented Aug 1, 2023

Punting this to 12.0.1

@gregw gregw merged commit 16b00e2 into jetty-12.0.x Aug 11, 2023
@gregw gregw deleted the fix/12.0.x/webapp-classloader-configuration branch August 11, 2023 01:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Sponsored This issue affects a user with a commercial support agreement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants