-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
AbstractConfiguration clears Configuration name if some conditions are met (i.e. no defined loggers) #3431
Comments
@ppkarwasz - trying to take care of some of my many small bug reports - created a PR for this issue. Under the assumption that the above mentioned change for LOG4J-1176 was only added to ensure that a configuration gets a default name for testing the fix, I wrapped it so that the default name is only set if no name has already been set. |
Thanks a lot! I will have some time next week to look at the open PRs. |
…pache#3431) + moved changelog file to .2.x.x
Log4j 2.24.3 - AbstractConfiguration
If I create a BuiltConfiguration that defines a Configuration 'name' (i.e. "FooBar") and no loggers, the
AbstractConfigurat#doConfigure()
method calls thesetToDefault()
method for example if the following conditions are met:For example,
The first thing the
setToDefault
method does is clear the given name and replace it with a default.It should however (IMHO) be a perfectly valid scenario to create a configuration with no content but with a custom name - specifically where I discovered this in testing. But maybe I want to only define global filters and otherwise rely on default behaviour.
In my opinion the name should only be set here if no name has yet been set.
Generally it should be OK to set a configuration with no loggers and no root logger. Consider a CompositeConfiguration named "FooBar" with an initially empty BuiltConfiguration. Some runtime event might create appenders and loggers dynamically (ie. for a new service). But it is no longer possible to lookup that configuration by name because a default has been applied.
NOTE: The referenced bug/fix (https://issues.apache.org/jira/browse/LOG4J2-1176) doesn't seem to make any mention of the name being a problem.
The text was updated successfully, but these errors were encountered: