Conversation
When the JUL-to-SLF4J bridge is installed, the default java.util.logging root ConsoleHandler is removed. When the logging system is cleaned up (for example when an ApplicationFailedEvent is published), the bridge is uninstalled but the ConsoleHandler was not restored, leaving the JUL root logger with no handlers. Anything subsequently logged through JUL, such as a startup failure reported via a JUL-backed commons-logging Log, was then silently discarded. Restore the default ConsoleHandler when uninstalling the bridge so that JUL logging continues to work after cleanup. See spring-projectsgh-50404 Signed-off-by: Rameel Rizvi <rrizvi@alumni.cmu.edu>
spring-projects-issues
added
the
status: waiting-for-triage
wilkinsona
requested changes
Sep 10, 2026
wilkinsona
left a comment
wilkinsona
left a comment
Member
There was a problem hiding this comment.
Thank you for the proposal. I've left a comment for your consideration. Additionally, similar changes would have to be made to Log4J2LoggingSystem as it too manipulates the root handler.
| // was installed. Without this, anything logged through JUL after cleanup | ||
| // (for example a startup failure reported via a JUL-backed commons-logging | ||
| // Log) would be silently discarded (see gh-50404). | ||
| restoreDefaultRootHandler(); |
Member
There was a problem hiding this comment.
We're calling removeJdkLoggingBridgeHandler() which may remove the default root handler and then immediately restoring it. I suspect that the remove will be a no-op in this code path, but the structure of the proposed code is confusing as it appears that we're removing and then immediately restoring. It would be better if the no-op remove didn't happen at all in this codepath.
wilkinsona
added
the
status: waiting-for-feedback
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.
When the JUL-to-SLF4J bridge is installed, the default java.util.logging root ConsoleHandler is removed. When the logging system is cleaned up (for example when an ApplicationFailedEvent is published), the bridge is uninstalled but the ConsoleHandler was not restored, leaving the JUL root logger with no handlers. Anything subsequently logged through JUL, such as a startup failure reported via a JUL-backed commons-logging Log, was then silently discarded.
Restore the default ConsoleHandler when uninstalling the bridge so that JUL logging continues to work after cleanup.
See gh-50404