我有多个微服务,有些运行在tomcat上,有些是独立的jar。我们以前使用java.util.logging框架进行日志记录。后来我们切换到log4j2,但是保留了用于日志记录的julapi,这样就不必重写代码了。这个工作(它不能改变,虽然我想)。显然有一些日志级别的转换,因为jul和log4j2使用不同的日志级别。在非tomcat服务中,日志级别如下所示:
14:49:58.612 FINEST - t1 Log level FINEST enabled
14:49:58.612 TRACE - t1 Log level FINER enabled
14:49:58.613 DEBUG - t1 Log level FINE enabled
14:49:58.613 CONFIG - t1 Log level CONFIG enabled
14:49:58.613 INFO - t1 Log level INFO enabled
14:49:58.613 WARN - t1 Log level WARNING enabled
14:49:58.614 ERROR - t1 Log level SEVERE enabled
这是预期的行为。
但是,在tomcat上,我们得到了以下结果:
14:46:38.393 TRACE - t1 Log level FINEST enabled
14:46:38.394 DEBUG - t1 Log level FINER enabled
14:46:38.394 DEBUG - t1 Log level FINE enabled
14:46:38.395 INFO - t1 Log level CONFIG enabled
14:46:38.396 INFO - t1 Log level INFO enabled
14:46:38.396 WARN - t1 Log level WARNING enabled
14:46:38.397 ERROR - t1 Log level SEVERE enabled
这是不对的。我相信这和从到七月的翻译有关,因为tomcat的juli是基于七月的。
为了证实我的怀疑,我将tomcat的内部日志也改为log4j2,这解决了日志级别的问题,但带来了另一个问题。线程上下文不再注入log4j2日志。我怀疑是因为现在有两个log4j示例在运行——一个用于tomcat,一个用于我们的应用程序。
为了解决我的问题,我会很高兴与任何一个解决方案
使用juli修复tomcat以显示正确的log4j2日志级别或
使用tomcat和log4j代替juli,但保持threadcontext工作
如果可能的话,首选1号解决方案。
1条答案
按热度按时间qltillow1#
看起来不同的是log4j2的版本
2.14.0
. 使用levelconverter接口diff的每个更新leveltranslator:提交已标记
2.14.0
所以我可以想象,非tomcat服务使用的是2.14.0
或更高版本,并且tomcat服务的版本比2.14.0
似乎您需要能够升级tomcat正在使用的log4j2,或者您的服务包含多个不同版本的log4j2,而tomcat类加载只是加载旧版本。确保从项目中删除重复的lib。请记住,您必须检查完整的类加载器树。如果tomcat本身没有使用log4j,那么默认为org.apache.juli.logging.directjdklog。将跟踪级别转换为
FINER
所以我们知道这不是你看到的处决之路。另一种可能性是,slf4j桥处理程序是您看到的Map到trace to finest的输出。