Apache Commons Logging 的运行时发现算法有什么问题 [英] What is the issue with the runtime discovery algorithm of Apache Commons Logging
问题描述
Dave Syer (SpringSource) 写入他的博客:
Dave Syer (SpringSource) writes in his blog:
不幸的是，commons-logging 最糟糕的事情，以及使它不受新工具欢迎的原因，也是运行时发现算法.
Unfortunately, the worst thing about commons-logging, and what has made it unpopular with new tools, is also the runtime discovery algorithm.
为什么?它的运行时发现算法有什么问题?性能?
Why? What is the issue with its runtime discovery algorithm? Performance?
推荐答案
为什么?它的运行时发现算法有什么问题?性能?
Why? What is the issue with its runtime discovery algorithm? Performance?
不，这不是性能，而是类加载器的痛苦.JCL 发现过程依赖于类加载器 hack 在运行时找到日志框架，但这种机制会导致许多问题，包括意外行为、难以调试的类加载问题导致复杂性增加.Ceki(Log4J、SLF4J 和 Logback 的作者)在 在采用 commons-logging 之前再三考虑API(其中还提到了使用 JCL 观察到的内存泄漏问题).
No, it's not performance, it's classloader pain. JCL discovery process relies on classloader hacks to find the logging framework at runtime but this mechanism leads to numerous problems including unexpected behavior, hard to debug classloading problems resulting in increased complexity. This is nicely captured by Ceki (the author of Log4J, SLF4J and Logback) in Think again before adopting the commons-logging API (which also mentions memory leaks problems observed with JCL).
这就是创建使用静态绑定的 SLF4J 的原因.
And this is why SLF4J, which uses static bindings, has been created.
Ceki 是 SLF4J 的作者，您可能认为他的文章有偏见，但相信我，事实并非如此，他提供了大量参考资料(证据)来证明他的观点.
Ceki being the author of SLF4J, you might think his articles are biased but, believe me, they are not and he is providing lots of references (evidences) to prove his point.
总结:
- 是的，众所周知，JCL 已损坏，最好远离它.
- 如果您想使用日志 Facade(并非所有项目都需要)，请使用 SLF4J.
- SLF4J 为仍然使用 JCL 的框架提供了一个 JCL 到 SLF4J 的桥梁，比如 Spring :(
- 我发现 Log4J 的继任者 Logback 是一种出色的日志记录实现.
- Logback 原生实现了 SLF4J API.这意味着，如果您使用的是 Logback，那么您实际上是在使用 SLF4J API.
这篇关于Apache Commons Logging 的运行时发现算法有什么问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
