fix: DH-22426: Disable logback's auto-closing behavior wrt servlets#7958
Open
devinrsmith wants to merge 6 commits intodeephaven:mainfrom
Open
fix: DH-22426: Disable logback's auto-closing behavior wrt servlets#7958devinrsmith wants to merge 6 commits intodeephaven:mainfrom
devinrsmith wants to merge 6 commits intodeephaven:mainfrom
Conversation
…are installed Logback registers an implementation of the service `jakarta.servlet.ServletContainerInitializer` which allows logback to automatically stop when a servlet is stopped. This causes us to lose logging at the end of our shutdown cycle. This PR disables this logic. See https://logback.qos.ch/manual/configuration.html#webShutdownHook
Contributor
No docs changes detected for 43ec199 |
Member
Author
|
Before: After: |
devinrsmith
added
NoDocumentationNeeded
NoReleaseNotesNeeded
Member
Author
|
Green nightlies. |
cpwright
reviewed
Apr 30, 2026
| // have a logback dependency at this level, our applications that depend on this project typically do. It | ||
| // would probably be "more correct" to have a way for the application main's to set or pass along this property | ||
| // themselves, but there is little harm in setting it here unconditionally (if the slf4j implementation is not | ||
| // logback, this setting will have no effect). |
Contributor
There was a problem hiding this comment.
what about server/jetty-11/src/main/java/io/deephaven/server/jetty11/JettyBackedGrpcServer.java
Member
Author
There was a problem hiding this comment.
Yes, I forgot this! Will do, thanks.
Member
Author
There was a problem hiding this comment.
So, we got "lucky" in that our Jetty 11 code doesn't trigger the ServletContainerInitializer. During our migration from Jetty 11 to 12, some of the servlet setup stuff has changed. The main difference is that our Jetty 12 setup uses a top level WebAppContext whereas our Jetty 11 setup uses a top level ServletContextHandler. (See org.eclipse.jetty.annotations.AnnotationConfiguration#getNonExcludedInitializers v org.eclipse.jetty.ee10.annotations.AnnotationConfiguration#getNonExcludedInitializers).
I've added a test that explicitly tests whether ServletContainerInitializer is invoked, with a note about implications if either of them changes.
rcaudy
reviewed
May 7, 2026
Member
rcaudy
left a comment
rcaudy
left a comment
There was a problem hiding this comment.
I'm cool with this if Charles/Colin are.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Logback registers an implementation of the service
jakarta.servlet.ServletContainerInitializerwhich allows logback to automatically stop when a servlet is stopped. Our usage oforg.eclipse.jetty.ee10.webapp.WebAppContextin Jetty 12 causes this to be invoked, and causes us to lose logging at the end of our shutdown cycle. This PR disables this logic.Note: we don't use the equivalent
org.eclipse.jetty.webapp.WebAppContextin Jetty 11, so this was not an issue there.In addition, a Deephaven will install a shutdown hook that will trigger logback shutdown after the ShutdownManager tasks have run. This can be disabled by callers via an overloaded parameter in
MainHelper.init.See https://logback.qos.ch/manual/configuration.html#webShutdownHook