log4j vs logback [关闭]


152

我们在自制包装器后面使用log4j。我们计划现在使用它的更多功能。

我们应该更新到登录吗?

(我的意思是框架不是像SLF4J这样的外观)


1
logback听起来非常类似于jakarta commons日志记录-主要区别是什么?
马特b

12
SLF4J(即立面)的声音类似于commons.logging。主要区别在于SLF4J使用静态绑定,而commons.logging使用某种解析策略。Logback(外观的“本机”(即,没有附加的包装层)实现)与LOG4J相当,但具有更丰富的API。
湖西

Answers:


190

Logback本机实现SLF4J API。这意味着,如果您使用的是logback,则实际上是在使用SLF4J API。从理论上讲,您可以直接使用logback API的内部结构进行日志记录,但是不建议这样做。记录器上的所有注销文档和示例均根据SLF4J API编写。

因此,通过使用logback,您实际上将使用SLF4J,并且如果出于任何原因想要切换回log4j,只需在几分钟之内将slf4j-log4j12.jar放到类路径中,就可以这样做。

从logback迁移到log4j时,仍然需要将logback特定部分(尤其是logback.xml配置文件中包含的部分)迁移到其log4j等效项,即log4j.properties。在向另一个方向迁移时,需要将log4j配置(即log4j.properties)转换为其等效的logback。有一个在线工具。迁移配置文件所涉及的工作量少于迁移在所有软件的源代码及其依赖项中分发的记录器调用所需要的工作量。


28
与这样一个广受欢迎的软件的开发人员交谈的机会很大。感谢Ceki提供log4j。
Srujan Kumar Gulla

7
免责声明:这个人是Log4j,SLF4J和Logback的所有原始开发者。但是,不再为Log4j工作。
维克多·斯塔夫萨

56

你应该? 是的

为什么? Log4J实际上已被Logback弃用。

紧急吗 也许不会。

不会痛吗?可能吧,但这可能取决于您的日志记录语句。

请注意,如果您真的想充分利用LogBack(或SLF4J),那么您确实需要编写适当的日志记录语句。这将带来一些优势,例如由于延迟求值而使代码更快,并且由于可以避免使用防护措施而减少了代码行。

最后,我强烈推荐SLF4J。(为什么要用自己的外墙重新制作轮子?)


48
注意:log4j项目不认为log4j已弃用。
托尔比约恩Ravn的安徒生

17
应澄清术语;毫无疑问,log4j项目作者认为logback是 log4j 的后继者。这两个项目的作者相同,因此他的观点应具有一定的分量;“ log4j项目”本身并没有真正“考虑”任何东西。当前与log4j相关的人群意见分歧(有些人实际上同意,有些人毫不奇怪地表示不同意)。有了更多的历史记录(原始评论后的3年),SLF4J + Logback确实在Log4j上获得了发展。
迈克尔,

@michael_n请注意,Log4j 1不是一个人编写的。说“同一作者”是错误的。切基无疑是一位重要的作家,但不是唯一的一位。实际上,很多人帮助使Log4j 1成为了它。
基督教徒

@Christian“没有写...”,当然,这对于任何成熟的apap项目都应该暗示(我的资格是“与log4j相关的当前人员”);尽管如此,如果我可以编辑评论,我会说“ 最初创作”,正如维基百科文章中所述。回复:“实际上,很多人帮助使Log4j 1成为了它”,这是绝对,模棱两可的(即,好是坏)。并且以某种较小的方式促成了slf4j + logback的诞生:-)
michael

3
那么,你们所有人都在为这个或那个日志库而战吗?我们为什么要杀死/推广图书馆?至少提供一些理性的推理,为什么一个比另一个更好。天哪,堆栈溢出是一团糟。
用户

48

在日志记录世界中,有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外观却提供了该API。鉴于很多应用程序都使用slf4j作为包装器,因此使用它可能是有意义的。

slf4j提供了许多不错的API糖,例如slf4j docs中的示例:

logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);

它是变量替换。Log4j 2也支持此功能。

但是,您需要知道slf4j是由QOS开发的,后者还维护着logback。Log4j 2.0在Apache Software Foundation中诞生。在过去的三年中,一个充满活力和活跃的社区再次发展起来。如果您对开放源代码感到满意,因为它是由Apache软件基金会(Apache Software Foundation)做出的,所有这些保证都可以使您重新考虑使用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中使用字节流而不是后台操作String。同样,它在重新配置时不会丢失事件。

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 Logging Services的副总裁,并且也参与log4j。


19

不能完全回答您的问题,但是如果您可以离开自制包装器,那么可以使用Hibernate现已改用的Java简单日志记录外观(SLF4J)(而不是普通日志记录)。

SLF4J没有任何类加载器问题或Jakarta Commons Logging(JCL)所观察​​到的内存泄漏问题。

SLF4J支持JDK日志记录,log4j和logback。因此,在适当的时候从log4j切换到logback应该相当容易。

编辑:我没有说清楚自己的道歉。我建议使用SLF4J使自己不必在log4j或logback之间做出艰难的选择。


3
我知道SLF4J。但是我要求的不是框架的日志记录框架!

4
道歉。我的建议是,如果您使用的是SLF4J而不是自己的自定义外观,那么从log4j切换到logback会不会那么痛苦?
工具包

该引用的来源是什么?Commons日志记录是一个久经考验的组件。我从来没有任何内存泄漏。
Kshitiz Sharma

1
@KshitizSharma-我提供的SLF4J文档链接中:slf4j.org/manual.html
工具包

13

您的决定应基于

  • 您对这些“更多功能”的实际需求;和
  • 您实施更改的预期成本。

您应该抵制更改API的冲动,因为它“更新,更亮,更好”。我遵循“如果没有损坏,请不要踢”的政策。

如果您的应用程序需要非常复杂的日志记录框架,则可能需要考虑原因。


3

成熟的项目,甚至深入到开发阶段的项目,可能会失去从此类升级中获得的收益,恕我直言。Logback在一系列方面无疑要先进得多,但在某种程度上不能完全替代工作系统。我当然会考虑将Logback用于新的开发,但是现有的log4j对于已经发布并满足最终用户需求的东西来说已经足够好和成熟了。这是非常主观的,您应该自己付出代价。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.