这就是为什么现在每个人都用SLF4J的原因:)
下面是如何追踪和更新你的SLF4J日志:
- 首先,查询slf4j绑定的类路径。
- 然后,确保只有一个这样的绑定。
- 最后,当你找到正在被使用的绑定:查阅它的配置特性。
另一方面-下面是如何追踪通用日志:
首先,你得找到日志绑定是如何实现。
检查commons-logging.properties 里的org.apache.commons.logging.log的属性是否设置,或通过应用里的Commons Logging API设置。
如果没有设置,检查路径下的log4j,如果有JDKLogger(IDK1.4+),或最后,如果简单logger已被使用(当没有其他可用logger时,common logging会使用默认logger)。
然后,查阅logging配置里的配置特性。
编译时绑定和运行时绑定
当我第一次阅读关于编译时绑定时,感觉很模糊:一个java库如何能用不同的依赖编译时绑定的框架来记录日志?答案是“编译时”绑定只适用于这样的情况-对SLF4J logger的实现时,SLF4J“被编译”。然而,你仍可以在运行时使用不同的绑定。
SLF4J不使用类加载器,而是,很简单:它加载org.slf4j.impl.StaticLoggerBinder。每一个SLF4J的实现(例如slf4j-log4j 绑定)提供一个有确切名称的类。所以这里没有疑惑,在运行时,相同的情况发生了:类被从类路径里直接取出,没有任何魔术运行。如果在类路劲下没有slf4j实现方法会怎么样? 怎样…然后会没有任何日志。
有时候魔术运行很好。其他时候,很烦人。
唯一你可以决定的方法是:在这个情况后,如果你应用中可用的魔术运行是值得的。所以我任何common-logging是个很重要的尝试:它表明,依靠明确的绑定,可以用许多不同的方式实现,在java社区不能很好地工作。
从复杂的commons-logging API吸取的经验,已经给SLF4J提供了更简单、更明确和同样动态的方法。
是什么使SLF4J这么好?老实说,可能是现代的java开发者在依赖管理上非常有效,因为他们通常 使用maven来管理依赖。
因此,SLF4J纯粹的JAR绑定策略超容易实现的(基于现代java依赖管理工具)。
大概10年前,在java依赖管理问题解决前,commons-logging是一个简单的,快速而粗糙,同事没有太多配置开销的方式,以确保您的应用程序可以记录动态。