logging-log4j2

logging-log4j2 copied to clipboard

The current log4j-jul artifact contains four different features:

1. A custom j.u.l.LogManager implementation. This implementation is actually rather generic and can be adapted to any kind of logging backend by implementing an o.a.l.l.j.AbstractLoggerAdapter. The default AbstractLoggerAdapter forwards all logging calls to the Log4j API.
2. An implementation of o.a.l.l.j.AbstractLoggerAdapter called CoreLoggerAdapter that forwards the JUL Logger.setLevel and similar non-logging API method to log4j-core.
3. A custom j.u.l.Handler implementation called Log4jBridgeHandler that forwards LogRecords to Log4j API. This handler can be used if the user can not change the implementation of j.u.l.LogManager.
4. Using the Log4jBridgeHandler is very slow for log statements that are disabled in the Log4j API implementation, but not disabled in the default JUL LogManager implementation. Therefore log4j-jul offers a level propagator that modifies the level of JUL loggers, whenever the level of the corresponding Log4j Core loggers change. This feature of course depends on log4j-core.

This PR:

• Removes CoreLoggerAdapter and related classes. IMHO users should not use j.u.l.Logger to modify the configuration of the logging backend.
• Moves the level propagator to a new module log4j-jul-propagator. Note that the level propagator idea comes from SLF4J/Logback where jul-to-slf4j introduces a LevelChangePropagator interface, but the implementation is in Logback.
• Revamps the o.a.l.l.j.LogManager:
  • It implements JUL methods that were introduced in Java 9.
  • It improves the implementation of methods that accept a sourceClass and sourceMethod parameters, by forwarding these parameters using LogBuilder#withLocation().
  • It fixes location detection, even if JUL Filters are used.

The last part probably could be improved: I don't see why we should support j.u.l.Filters. We could drop the feature in 3.x.