这就是为什么现在每个人都用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是一个简单的，快速而粗糙，同事没有太多配置开销的方式，以确保您的应用程序可以记录动态。
