Should CoreLogger override addHandler/removeHandler to avoid warnings from PR #3125?

[mpritham]

Context

PR #3125 added overrides to ApiLogger for JUL mutator methods (addHandler, removeHandler, setUseParentHandlers, etc.) that log a WARN via StatusLogger:

Ignoring call to `j.u.l.Logger.addHandler(...)`, since the Log4j API does not provide methods to modify the underlying implementation.

I understand how this makes sense for ApiLogger: the JavaDoc describes it as the "Log4j API implementation" that explicitly does not use java.util.logging.Handler, and it only holds a reference to ExtendedLogger (a log4j-api type).

My understanding is that CoreLogger is an implementation of a JUL Logger with direct access to org.apache.logging.log4j.core.Logger, Configurator, and LoggerConfig. It already overrides setLevel, getLevel,
setUseParentHandlers, getUseParentHandlers, and getParent with working implementations.

However, CoreLogger doesn't override addHandler or removeHandler, so it inherits ApiLogger's new warning behavior.

I'm using CoreLoggerAdapter via:

log4j.jul.LoggerAdapter = org.apache.logging.log4j.jul.CoreLoggerAdapter

This means that even with CoreLoggerAdapter configured, calls like SLF4JBridgeHandler.install() (which calls Logger.getLogger("").addHandler(...)) produce the warning.

Question

Was this intentional, or would it make sense for CoreLogger to override addHandler/removeHandler as well — either with a working implementation or at least without the warning?

Thanks for all the work on Log4j!

[ppkarwasz]

Hi @mpritham,

Those methods are not overridden because the JUL-to-Log4j bridge doesn’t provide a way to wrap JUL Handlers into Log4j Core Appenders.

You’re free to implement this as an extension of log4j-jul, but we would need to discuss whether it should be included in the main distribution.

This design is intentional:

1. Native components are preferred: Wrapping external components can introduce performance overhead and semantic differences.
2. Reliability: Log4j Core is designed to avoid losing log events (e.g., during reconfiguration). Supporting arbitrary wrapped components would make this harder and shift responsibility to the user to update components in the correct order (first add the new appender and only then remove the old one)

See: Modifying configuration components