Modernize and split log4j-jul

[ppkarwasz]

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.

[vy]

I am not JUL-savvy enough to provide a meaningful review, but skimmed through the changes and dropped some remarks anyway.

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.

Then let's drop it? I guess we can later on add it in a backward compatible manner if needed, right?

[ppkarwasz]

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.

Then let's drop it? I guess we can later on add it in a backward compatible manner if needed, right?

I agree, I will drop the j.u.l.Filter support.

[ppkarwasz]

@vy,

I did some further changes to this PR:

• b416ca5: I encapsulated the existing log4j-jul classes into three packages: spi contains interfaces and classes users can implement, support contains classes that can help implement SPI, internal is of limits and not exported through JPMS.
• 03a70ff: I removed the support for j.u.l.Filter. IMHO this is not used and can provide users with hard to debug surprises if a legacy library messes with the logging configuration behind their back.

[ppkarwasz]

For backward compatibility with e.g. spring-boot-starter-log4j2, which uses Log4jBridgeHandler I would refactor this PR in the following way:

• move the level change propagator back to log4j-jul and add a hard dependency on log4j-core. The lack of a level change propagator can really hurt the experience of spring-boot-starter-log4j2 users.
• move o.a.l.l.j.LogManager out of log4j-jul to a jul-to-log4j artifact that depends on Log4j API only. This will require changes in some applications, which hard code a System.setProperty("java.util.logging.manager", "o.a.l.l.j.LogManager") in their main class (or shell scripts).

Note: a better alternative to a hardcoded o.a.l.l.j.LogManager would be to have a universal j.u.l.LogManager implementation that loads implementation using ServiceLoader like any other modern logging API. I have provided an initial mock-up of such a universal j.u.l.LogManager implementation in ppkarwasz/slf4j/jul-manager and opened qos-ch/slf4j#429 to test for support among Logback users.

Logback users have the most problems with JUL-to-Logback redirection, since they can only use:

• Slf4jBridgeHandler, which as every Handler (appender) is inefficient,
• A combination of log4j-jul + log4j-to-slf4j, which is not a direct path.

[ppkarwasz]

I am merging this first and then we can discuss where to put jul-to-log4j (e.g. in a new repo).