[sharanggupta]

Fixes #4418.
Fixes #3155.

Two independent log4j-core fixes, in one PR as asked on #3155. The first two commits are the #4418 fix (unchanged since the review round), the third commit is the #3155 fix (previously #4423, closed).

Configurator.setAllLevels (#4418)

Configurator.setAllLevels(parentLogger, level) selected the child LoggerConfigs with a plain startsWith, so setAllLevels("com.foo", TRACE) also re-leveled com.foobar and com.foobar.child. This adds the same hierarchy-boundary check that #4414 introduced for LoggerNameLevelRewritePolicy (the parent itself, or names continuing with .; the root logger "" and a trailing-dot parent still cover everything below them), LoggerTest cases that pin each boundary check (a sibling logger keeps its level; root and trailing-dot parents still reach their descendants), and a changelog entry.

main (3.x) carries the identical lines in Configurator.setAllLevels; happy to forward-port once this is merged.

AbstractConfiguration logger mutators (#3155)

AbstractConfiguration.addLoggerAppender, addLoggerFilter and setLoggerAdditive (the implementation behind core.Logger#addAppender, #addFilter and #setAdditive) ignored the result of their putIfAbsent calls:

• addLoggerAppender: when a different appender instance was already registered under the same name, the new instance was not registered but was still attached to the LoggerConfig, so the logger wrote to an appender the configuration never started or stopped while getAppender(name) returned another one. The registered instance is now attached instead (first wins, as addAppender already behaves), with a status-logger warning.
• All three: the result of loggerConfigs.putIfAbsent(loggerName, nlc) is respected; when a config already exists the change is applied to it instead of re-wiring the parents and updating the loggers again. Under the method lock and the exact-name lookup that precedes it this branch is defensive, so it has no test of its own.
• addLoggerFilter and setLoggerAdditive now ignore null arguments like addLoggerAppender does, instead of throwing NullPointerException (side note 1 in the issue).

Tests, one per method in AbstractConfigurationTest: the duplicate-name appender case; the filter case (null arguments ignored, exactly one LoggerConfig created with the right parent, both filters applied); the additive case (null logger ignored, one config created, additivity reflected by the logger). All three fail before the change and pass after. Changelog entry for 2.x included.

Checklist

• Based on 2.x
• ./mvnw verify on log4j-core / log4j-core-test with LoggerTest and AbstractConfigurationTest succeeds (spotless clean)
• Changelog entries in src/changelog/.2.x.x, one per issue
• Tests are provided

[ramanathan1504]

The boundary check matches #4414, and the sibling case fails without the fix.
Removing charAt(...) == '.', isEmpty() or endsWith(".") from Configurator.isChildLogger keeps every test green. Can the test give LoggerTest.child its own level and cover the root and trailing-dot parents, as in the inline suggestions?

[sharanggupta]

As asked on #3155, this PR now also carries the AbstractConfiguration fix for that issue as a separate second commit (941a6a7, previously #4423, now closed). Description updated to cover both issues; the two commits stay independent.

[ramanathan1504]

This branch and the existing.addFilter(filter) and existing.setAdditive(additive) branches below have no test. Removing any of them keeps every test green. A LoggerConfig added with addLogger under a key that differs from its name reaches them, for example:

final LoggerConfig other = new LoggerConfig("other", Level.INFO, true);
config.addLogger("mismatch", other);
config.addLoggerFilter(context.getLogger("mismatch"), filter);
assertThat(other.hasFilter()).isTrue();

[ramanathan1504]

Can the entry be one short line with what the user sees?

Suggested change

	Fix `addLoggerAppender()` attaching an unregistered appender when its name is already registered, and `addLoggerFilter()`/`setLoggerAdditive()` failing on `null` arguments.
	Fix `Logger.addAppender()` attaching an unregistered appender.

[ramanathan1504]

The setAllLevels tests now fail for each removed condition, and each new AbstractConfigurationTest case fails without its fix.
The three existing branches in AbstractConfiguration stay green when removed, and a LoggerConfig added with addLogger under a different key reaches them. Can each get a test, and can the #3155 changelog be one short line?