While it is true that `LevelChangePropagator`'s purpose it to optimize the performance of JUL when redirected to SLF4J with `SF4JBridgeHandler`, it is also implicitly assumed that logbbak's configuration is the driver, with JUL configuration taking the backseat.
Yes, I agree. In my example above, I set -Djava.util.logging.config.file only because when LevelChangePropagator is disabled so resetJUL does not exist, I had to increase the verbosity of JUL so that CONFIG messages would be logged to the SLF4JBridgeHandler, which performs filtering based on the logback config. By default, JUL’s level is INFO. So step 1 is to increase the verbosity of JUL to ALL. Once the verbosity of JUL is initialized at ALL, then both SLF4JBridgeHandler and LevelChangePropagator apply filtering based on logback.xml to messages that come from JUL, and enabling LevelChangePropagator should only be a performance optimization. This change is necessary to make LevelChangePropagator consistent with SLF4JBridgeHandler. But when you set the logger level to INFO within logback.xml, then SLF4JBridgeHandler enables CONFIG messages, but LevelChangePropagator disables CONFIG messages. This is a bug. Please reconsider this issue. |