我们在自制包装器后面使用 log4j。我们计划现在使用它的更多功能。
我们应该更新到 logback 吗？
（我的意思是框架不是像 SLF4J 这样的外观）
TimmiB
问问题
120562 次
6 回答
215
Logback 原生实现了 SLF4J API。这意味着如果你使用 logback，你实际上是在使用 SLF4J API。从理论上讲，您可以直接使用 logback API 的内部进行日志记录，但非常不鼓励这样做。所有关于记录器的 logback 文档和示例都是根据 SLF4J API 编写的。
因此，通过使用 logback，您实际上是在使用 SLF4J，如果您出于任何原因想要切换回 log4j，只需将 slf4j-log4j12.jar 放到您的类路径中即可在几分钟内完成。
当从 logback 迁移到 log4j 时，logback 特定部分，特别是那些包含在logback.xml配置文件中的部分，仍然需要迁移到它的 log4j 等价物，即log4j.properties。当向另一个方向迁移时，需要将 log4j 配置（即log4j.properties）转换为其等效的 logback。有一个在线工具可以做到这一点。迁移配置文件所涉及的工作量远少于迁移分布在所有软件源代码及其依赖项中的记录器调用所需的工作量。
于 2009-05-29T09:08:04.973 回答
53
在日志世界中，有 Facades（如 Apache Commons Logging、slf4j 甚至 Log4j 2.0 API）和实现（Log4j 1 + 2、java.util.logging、TinyLog、Logback）。
基本上你应该用 slf4j IF 替换你的自制包装器，并且只有当你出于某种原因对它不满意时。虽然 Apache Commons Logging 并没有真正提供现代 API，但 slf4j 和新的 Log4j 2 外观正在提供它。鉴于相当多的应用程序使用 slf4j 作为包装器，使用它可能是有意义的。
slf4j 提供了许多不错的 API 糖，例如 slf4j 文档中的这个示例：
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
这是变量替换。Log4j 2 也支持这一点。
但是你需要知道 slf4j 是由 QOS 开发的，他们也维护 logback。Log4j 2.0 在 Apache Software Foundation 中诞生。在过去的三年里，一个充满活力和活跃的社区再次在那里成长。如果你喜欢开源，因为它由 Apache 软件基金会提供所有保证，你可能会重新考虑使用 slf4j 以支持直接使用 Log4j 2。
请注意：
过去 log4j 1 没有被主动维护，而 Logback 是。但今天情况不同了。Log4j 2 得到积极维护，几乎定期发布。它还包括许多现代功能，并且 -imho- 使一些事情比 Logback 更好。这有时只是一个品味问题，您应该得出自己的结论。
我写了一篇关于 Log4j 2.0 新特性的快速概述：http: //www.grobmeier.de/the-new-log4j-2-0-05122012.html
阅读时您会发现 Log4j 2 的灵感来自 Logback，但也受到其他日志框架的启发。但是代码库不同；它与 Log4j 1 几乎没有任何共享，而与 Logback 共享零。这导致了一些改进，例如示例 Log4j 2 使用字节流而不是引擎盖下的字符串进行操作。此外，它在重新配置时不会丢失事件。
Log4j 2 可以以比我知道的其他框架更高的速度记录：http: //www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html
而且用户社区似乎仍然比 Logbacks 大得多：http: //www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html
总而言之，最好的主意是您选择最适合您想要实现的目标的日志框架。如果我在生产环境中禁用日志记录并仅在我的应用程序中执行基本日志记录，我不会切换完整的框架。但是，如果您在日志记录方面做得更多，只需查看框架及其开发人员提供的功能即可。虽然您通过 QOS 获得了对 Logback 的商业支持（我听说），但目前还没有对 Log4j 2 的商业支持。另一方面，如果您需要进行审计日志记录并且需要异步附加程序提供的高性能，那么这样做很有意义检查 log4j 2。
请注意，尽管它们提供了所有舒适，但外墙总是会吃一点性能。它可能根本不会影响您，但如果您的资源不足，您可能需要保存所有可以拥有的东西。
如果不更好地了解您的要求，几乎不可能给出建议。只是：不要因为很多人切换而切换。切换只是因为你看到了它的价值。而关于 log4j 已死的论点也不再重要了。它还活着，而且很热。
免责声明：我目前是 Apache 日志服务副总裁，也参与了 log4j。
于 2014-03-01T14:06:43.617 回答
20
不完全回答您的问题，但是如果您可以摆脱自制的包装器，那么Hibernate 现在已切换到Java 的简单日志记录外观 (SLF4J) （而不是公共日志记录）。
SLF4J 没有遇到使用 Jakarta Commons Logging (JCL) 观察到的类加载器问题或内存泄漏。
SLF4J 支持 JDK 日志记录、log4j 和 logback。所以在合适的时候从 log4j 切换到 logback 应该是相当容易的。
编辑：我没有说清楚的道歉。我建议使用 SLF4J 来隔离自己，不必在 log4j 或 logback 之间做出艰难的选择。
于 2008-10-07T13:39:39.497 回答
14
你的决定应该基于
- 您对这些“更多功能”的实际需求；和
- 您实施变更的预期成本。
您应该抵制仅仅因为它“更新、更闪亮、更好”而改变 API 的冲动。我遵循“如果它没有坏，不要踢它”的政策。
如果您的应用程序需要一个非常复杂的日志框架，您可能需要考虑原因。
于 2008-10-07T14:28:25.327 回答
3
Mature project or even project deep into development stages would probably loose more than gain from such upgrade, IMHO. Logback is certainly much more advanced in an array of points, but not to an extent for complete replacement in a working system. I would certainly consider logback for a new development, but existing log4j is good enough and mature for anything already released and met end user. This is very subjective, you should see cost yourself.
于 2012-08-14T19:33:33.483 回答