У нас есть собственная сторонняя библиотека, которая использует JUL. Мы используем logback и slf4j, с мостом jul-slf4j и LevelChangePropagator .
По большей части это работает так, как мы ожидаем. Однако при развертывании в Tomcat (или, точнее, , когда менеджер ведения журнала изменяется на org.apache.juli.ClassLoaderLogManager), возникает проблема с распространением. Распространение, кажется, работает, мы проверяем это с помощью JMX, а также путем отладки. Если мы установим для стороннего регистратора "foo" значение TRACE через logback, мы увидим, что
java.util.loggging.LoggingMXBean.getLoggerLevel("foo")
вернет FINEST, как мы ожидаем.
Проблема в том, что в библиотеке есть строки, подобные этому:
logger.isLoggable(Level.FINEST)
, которые возвращают false даже после того, как мы проверили распространение. Когда мы отлаживаем, логгер здесь действительно имеет значение уровня 800 (для FINEST это будет 300). Это как если бы было два регистратора, созданных для «foo», и в одном случае (JMX) у нас есть доступ к одному, а в другом случае (в библиотеке) у нас есть доступ к другому.
Почему / как менеджер ведения журнала org.apache.juli.ClassLoaderLogManager влияет на наше дело и как мы можем решить его или понять, что происходит? Это связано с наличием загрузчиков разных классов?
- Проблема возникает только с менеджером журналов
org.apache.juli.ClassLoaderLogManager. Мы можем отключить это на Tomcat, и это работает так, как мы ожидаем. Самые точные журналы регистрируются через slf4j, но мы хотим понять, что именно происходит, а не просто изменить конфигурацию Tomcat.
- Даже когда проблема возникает, jul-slf4j-bridge работает так, как мы ожидаем, в других случаях, например, уровень INFO для регистратора "foo" регистрирует через slf4j.