java Apache Commons Logging 的运行时发现算法有什么问题
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3222895/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is the issue with the runtime discovery algorithm of Apache Commons Logging
提问by Ta Sas
Dave Syer (SpringSource) writesin his blog:
Dave Syer (SpringSource)在他的博客中写道：
Unfortunately, the worst thing about commons-logging, and what has made it unpopular with new tools, is also the runtime discovery algorithm.
不幸的是，commons-logging 最糟糕的事情，以及使它不受新工具欢迎的，也是运行时发现算法。
Why? What is the issue with its runtime discovery algorithm? Performance?
为什么？它的运行时发现算法有什么问题？表现？
回答by Pascal Thivent
Why? What is the issue with its runtime discovery algorithm? Performance?
为什么？它的运行时发现算法有什么问题？表现？
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).
不，这不是性能，而是类加载器的痛苦。JCL 发现过程依赖于类加载器 hack 在运行时找到日志框架，但这种机制会导致许多问题，包括意外行为、难以调试的类加载问题导致复杂性增加。Ceki（Log4J、SLF4J 和 Logback 的作者）在采用 commons-logging API 之前再次在Think 中很好地捕捉到了这一点（其中还提到了 JCL 观察到的内存泄漏问题）。
And this is why SLF4J, which uses static bindings, has been created.
这就是创建使用静态绑定的 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.
Ceki 是 SLF4J 的作者，您可能认为他的文章有偏见，但相信我，事实并非如此，他提供了大量参考资料（证据）来证明他的观点。
To sum up:
总结：
- Yes, JCL is known to be broken, better stay away from it.
- If you want to use a logging facade (not all projects need that), use SLF4J.
- SLF4J provides a JCL-to-SLF4J bridge for frameworks still using JCL like Spring :(
- I find Logback, Log4J's successor, to be a superior logging implementation.
- Logback natively implements the SLF4J API. This means that if you are using Logback, you are actually using the SLF4J API.
- 是的，众所周知，JCL 已损坏，最好远离它。
- 如果您想使用日志外观（并非所有项目都需要），请使用 SLF4J。
- SLF4J 为仍然使用 JCL 的框架提供了一个 JCL 到 SLF4J 的桥接，比如 Spring :(
- 我发现 Logback（Log4J 的继任者）是一个出色的日志记录实现。
- Logback 原生实现了 SLF4J API。这意味着如果您使用 Logback，您实际上是在使用 SLF4J API。
See also
也可以看看
回答by krock
Commons logging is a light weight logging facade which is placed on top of the heavy weight logging API be that log4j, java.util.logging or another supported logging API.
Commons logging 是一个轻量级的日志外观，它位于重量级日志 API 之上，是log4j， java.util.logging 或其他支持的日志 API。
The discovery algorithmis what commons logging uses to determine what logging API you use at runtime so it can direct log calls through its API to the underlying logging API. The benefit of this is that if you wanted to create a library that does logging, you do not want to tie down users of your library to any particular heavy weight logging system. Callers of your code can configure logging via log4j, java.util.logging etc. and commons logging will forward to that API at runtime.
该发现算法就是公共记录使用，以确定你用什么记录API在运行，因此它可以通过其API底层记录API直接调用日志。这样做的好处是，如果您想创建一个进行日志记录的库，您不希望将库的用户绑定到任何特定的重量级日志记录系统。您的代码的调用者可以通过 log4j、java.util.logging 等配置日志记录，并且公共日志记录将在运行时转发到该 API。
Common gripes for commons logging:
公共日志记录的常见抱怨：
- Even though you don't use it, a library you depend on might so you have to include it in your classpath anyway.
- Runs the discovery algorithm for each classloader you want to do logging in, which can produce unwanted resultsso make sure you put commons-logging.jar in the right classloader.
- Greater complexity than the underlying logging framework.
- Less features that underlying logging framework.
- 即使您不使用它，您依赖的库也可能如此，因此无论如何您都必须将其包含在类路径中。
- 为您想要登录的每个类加载器运行发现算法，这可能会产生不需要的结果，因此请确保将 commons-logging.jar 放在正确的类加载器中。
- 比底层日志框架更复杂。
- 底层日志框架的功能较少。
A perceived greater complexity as well as unpredictability in complex classpath hierarchies without any perceived benefits make users of commons-logging agitated. Given also that this choice may be forced on you does not make users sympathetic. See this articlefor a compelling argument against using commons-logging.
复杂的类路径层次结构中感知到的更大的复杂性以及不可预测性，而没有任何感知到的好处，这让 commons-logging 的用户感到不安。考虑到这个选择可能会被强加给你，这并不会让用户产生共鸣。 有关反对使用 commons-logging 的令人信服的论据，请参阅本文。
回答by Carl Smotricz
I can't speak about the "believed unpopular" aspect, I can only speak for myself:
我不能说“相信不受欢迎”的方面，我只能为自己说：
Commons Logging is a facade over top of whatever your "real" logging framework may be: Log4j, Logback or whatever.
Commons Logging 是任何“真实”日志框架之上的外观：Log4j、Logback 或其他任何东西。
The idea of a logging facade is that your app gains the flexibility to decide at runtime which logging implementation it wants to work with. The facades are clever enough to find logging implementations at runtime.
日志外观的想法是，您的应用程序可以灵活地在运行时决定要使用哪个日志记录实现。Facades 足够聪明，可以在运行时找到日志记录实现。
My older Java apps use Log4j, directly. Works fine, I see no need to change them. My newer Java apps will probably use Logback. I think the ability to dynamically choose a logging framework is something none of my apps will ever need. Of course, other peoples' mileage may vary.
我的旧 Java 应用程序直接使用 Log4j。工作正常，我认为没有必要改变它们。我较新的 Java 应用程序可能会使用 Logback。我认为动态选择日志框架的能力是我的应用程序永远不需要的。当然，其他人的里程可能会有所不同。
EDIT: Looks like I was wrong about the rationale for Commons Logging. The links given by @Pascal Thivent, especially the first one, explain this far better.
编辑：看起来我对 Commons Logging 的理由是错误的。@Pascal Thivent 给出的链接，尤其是第一个链接，更好地解释了这一点。
回答by Thorbj?rn Ravn Andersen
Commons Logging contains logic to determine at runtime whether to use log4j or java.util.logging.*.
Commons Logging 包含在运行时确定是使用 log4j 还是 java.util.logging.* 的逻辑。
That code used to be seriously broken, essentially only working with JUL.
该代码曾经严重损坏，基本上只能与 JUL 一起使用。
Based on the experiences with this, slf4j was written which uses static binding (or used to, Im not sure with version 1.6) to choose the appropriate framework to use of log4j, JUL or the log4j fork logback (and more), and it includes a bridge to allow existing Commons Logging code to use slf4j transparently.
根据这方面的经验，编写了 slf4j，它使用静态绑定（或曾经使用过，我不确定 1.6 版）来选择合适的框架来使用 log4j、JUL 或 log4j fork logback（以及更多），它包括允许现有 Commons Logging 代码透明地使用 slf4j 的桥梁。
If you can, then go for slf4j.
如果可以，请选择 slf4j。
