Another reason that LevelChangePropagator should be consistent with SLF4JBridgeHandler is that it is not supposed to change the logging behavior (except for resetJUL); it is supposed to be a performance optimization. When the logger level is checked in java.util.logging.Logger.log (configured by LevelChangePropagator), this is supposed to arrive at the same decision as the check for logger level in ch.qos.logback.classic.Logger.log. Compare the output with JUL logging enabled, with and without LevelChangePropagator (mvn exec:java -Dexec.mainClass=com.example.logbacksample.JulLoggerLevels -DcustomLogLevel=info -Djava.util.logging.config.file=<(echo .level = ALL)). Without LevelChangePropagator in logback.xml:
Root level is INFO INFO c.e.logbacksample.JulLoggerLevels - Config (should be slf4j info) INFO c.e.logbacksample.JulLoggerLevels - Info WARN c.e.logbacksample.JulLoggerLevels - Warning (should be slf4j warn) ERROR c.e.logbacksample.JulLoggerLevels - Severe (should be slf4j error)
Contrast to the output with LevelChangePropagator enabled in logback.xml:
Root level is INFO INFO c.e.logbacksample.JulLoggerLevels - Info WARN c.e.logbacksample.JulLoggerLevels - Warning (should be slf4j warn) ERROR c.e.logbacksample.JulLoggerLevels - Severe (should be slf4j error)
Since the log output doesn’t match when LevelChangePropagator is enabled, LevelChangePropagator has a bug. |