Hardens PropertiesUtil against recursive property sources
#3263
+173
−120
Conversation
This file contains 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
As showed in #3252, Spring's `JndiPropertySource` not only can throw exceptions, but can also perform logging calls. Such a call causes a recursive call to `PropertiesUtil.getProperty("log4j2.flowMessageFactory"`) and a `StackOverflowException` in the best scenario. The worst scenario includes a deadlock. This PR: - Moves the creation of the default `MessageFactory` and `FlowMessageFactory` to the static initializer of `LoggerContext`. This should be close enough to the pre-2.23.0 location in `AbstractLogger`. The `LoggerContext` class is usually initialized, before Spring Boot adds its property sources to `PropertiesUtil`. - Adds a check to `PropertiesUtil` to ignore recursive calls. Closes #3252.
vy
approved these changes
Dec 2, 2024
| new LoggerContext(LoggerMessageFactoryCustomizationTest.class.getSimpleName())) { | ||
| Logger logger = new Logger( | ||
| loggerContext, | ||
| "arguments_should_be_honored", |
There was a problem hiding this comment.
You can use @TestInfo instead of hardcoding the method name. (Same goes for the other test methods too.)
| import org.junitpioneer.jupiter.SetSystemProperty; | ||
|
|
||
| @SetSystemProperty( |
There was a problem hiding this comment.
By making this test-scoped, aren't you changing the arguments_should_be_honored() test? That is,
- Before: there are no property-provided configurations, but only arguments passed to
Logger::new - New: there are property-provided configurations, and also arguments passed to
Logger::new
In the new case, you cannot know which configuration source has kicked in.
| @Test | ||
| @ResourceLock(value = Resources.SYSTEM_PROPERTIES, mode = ResourceAccessMode.READ) | ||
| @Issue("https://github.com/apache/logging-log4j2/issues/3252") | ||
| void testRecursivePropertySource() { |
There was a problem hiding this comment.
Shall we also verify the status logger warning?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
As showed in #3252, Spring's
JndiPropertySourcenot only can throw exceptions, but can also perform logging calls. Such a call causes a recursive call toPropertiesUtil.getProperty("log4j2.flowMessageFactory") and aStackOverflowExceptionin the best scenario. The worst scenario includes a deadlock.This PR:
MessageFactoryandFlowMessageFactoryto the static initializer ofLoggerContext. This should be close enough to the pre-2.23.0 location inAbstractLogger. TheLoggerContextclass is usually initialized, before Spring Boot adds its property sources toPropertiesUtil.PropertiesUtilto ignore recursive calls.Closes #3252.