问题
We have a 3rd party proprietary library that uses JUL. We use logback and slf4j, with the jul-slf4j-bridge and the LevelChangePropagator.
For the most part this is functioning as we expect. However, when we deploy to Tomcat (or more specifically when the logging manager is changed to org.apache.juli.ClassLoaderLogManager), there is an issue with the propagation. The propagation appears to work, we verify it by JMX and also by debugging. If we set the 3rd party logger, "foo", to TRACE via logback, we see that
java.util.loggging.LoggingMXBean.getLoggerLevel("foo")
will return FINEST as we expect.
The issue is that there are lines in the library that are like this:
logger.isLoggable(Level.FINEST)
, which return false even after we have verified the propagation. When we debug, the logger here indeed has a level value of 800 (it would be 300 for FINEST). It is as though there are two loggers created for "foo" and in one case (JMX) we have access to one, and in the other case (in the library) we have access to the other.
Why/how does the org.apache.juli.ClassLoaderLogManager logging manager affect our case and how can we resolve it or understand what is happening? Is it related to different class loaders being present?
- The issue only occurs with the
org.apache.juli.ClassLoaderLogManagerlog manager. We can disable this on Tomcat and it works as we would expect. The FINEST logs are logged through slf4j, but we want to understand the exactly what is happening rather than just change the Tomcat configuration. - Even when the issue occurs, the jul-slf4j-bridge works as we expect in other cases, e.g., the INFO level for logger "foo" logs through slf4j.
来源：https://stackoverflow.com/questions/56975903/why-does-using-the-org-apache-juli-classloaderlogmanager-logging-manager-affect