Apache Commons Logging的运行时发现算法有什么问题

Question

Dave Syer（SpringSource）writes在他的博客中：

  

不幸的是，关于commons-logging的最糟糕的事情，以及使它不受新工具欢迎的因素，也是运行时发现算法。

为什么呢？它的运行时发现算法有什么问题？性能

Answer 1

  

为什么呢？它的运行时发现算法有什么问题？性能

不，这不是表现，而是classloader pain。 JCL发现过程依赖于类加载器黑客在运行时查找日志框架，但是这种机制导致许多问题，包括意外行为，难以调试类加载问题导致复杂性增加。在Think again before adopting the commons-logging API中，Ceki（Log4J，SLF4J和Logback的作者）很好地捕获了这一点（它也提到了JCL观察到的内存泄漏问题）。

这就是为什么创建了使用静态绑定的SLF4J的原因。

Ceki是SLF4J的作者，你可能认为他的文章有偏见，但相信我，他们不是，他提供了很多参考资料（证据）来证明他的观点。

总结一下：

• 是的，众所周知，JCL会被打破，最好远离它。
• 如果要使用日志记录外观（并非所有项目都需要），请使用SLF4J。
• SLF4J为仍然使用JCL的框架提供了一个JCL-to-SLF4J桥接器:(
• 我发现Logback是Log4J的继任者，是一种优秀的日志记录实现。
• Logback本机实现SLF4J API。这意味着如果您使用的是Logback，那么您实际上正在使用SLF4J API。

另见

• Commons Logging was my fault
• Think again before adopting the commons-logging API
• SLF4J Vs JCL / Dynamic Binding Vs Static Binding

Answer 2

Commons logging是一个轻量级日志记录，它位于重量级日志API的顶部，可以是log4j，java.util.logging或其他受支持的日志记录API。

discovery algorithm是公共日志记录用于确定您在运行时使用的日志API的内容，因此它可以通过其API将日志调用定向到底层日志API。这样做的好处是，如果您想创建一个执行日志记录的库，您不希望将库的用户绑定到任何特定的重量级日志记录系统。您的代码的调用者可以通过log4j，java.util.logging等配置日志记录，并且commons日志记录将在运行时转发到该API。

公共记录的常见抱怨：

• 即使您不使用它，您依赖的库也可能因此无论如何都必须将它包含在类路径中。
• 为您要登录的每个类加载器运行发现算法，can produce unwanted results因此请确保将commons-logging.jar放在正确的类加载器中。
• 比底层日志框架更复杂。
• 基础日志框架的功能较少。

在没有任何可察觉的好处的情况下，复杂的类路径层次结构中存在更大的复杂性和不可预测性，这使得公共日志记录的用户变得激动。鉴于这种选择可能会被迫，你不会让用户同情。 See this article提出反对使用公共记录的令人信服的论点。

Answer 3

我不能谈论“相信不受欢迎”的方面，我只能为自己说话：

Commons Logging是一个超越你的“真实”日志框架的顶层：Log4j，Logback或其他。

日志记录外观的想法是，您的应用程序可以灵活地在运行时决定它想要使用哪个日志记录实现。外观足够聪明，可以在运行时找到日志记录实现。

我的旧Java应用程序直接使用Log4j。工作正常，我认为没有必要改变它们。我的新Java应用程序可能会使用Logback。我认为动态选择日志框架的能力是我的应用程序所不需要的。当然，其他人的里程可能会有所不同。

---

编辑：看起来我对Commons Logging的基本原理有误。 @Pascal Thivent给出的链接，尤其是第一个链接，解释得更好。

Answer 4

Commons Logging包含在运行时确定是使用log4j还是java.util.logging的逻辑。*。

该代码曾被严重破坏，基本上只与JUL合作。

基于这方面的经验，编写了slf4j，它使用静态绑定（或习惯，我不确定1.6版本）来选择适当的框架来使用log4j，JUL或log4j fork logback（以及更多），它包含一个桥，允许现有的Commons Logging代码透明地使用slf4j。

如果可以，请转到slf4j。