java 新项目应该使用 logback 而不是 log4j 吗？

Should new projects use logback instead of log4j?

提问by Huxi

Should new projects use logback instead of log4j as a logging framework ?

新项目是否应该使用 logback 而不是 log4j 作为日志框架？

Or with other words :'Is logback better than log4j (leaving the SLF4J-'feature' of logback beside)?'

或者换句话说：'logback 是否比 log4j 更好（将 SLF4J-logback 的'功能'放在一边）？'

回答by Huxi

You should use SLF4J+Logback for logging.

您应该使用 SLF4J+Logback 进行日志记录。

It provides neat features like parametrized messages and (in contrast to commons-logging) a Mapped Diagnostic Context (MDC, javadoc, documentation).

它提供了简洁的功能，如参数化消息和（与公共日志相反）映射诊断上下文（MDC、javadoc、文档）。

Using SLF4J makes the logging backend exchangeable in a quite elegant way.

使用 SLF4J 可以以一种非常优雅的方式交换日志后端。

Additionally, SLF4J supports bridgingof other logging frameworks to the actual SLF4J implementation you'll be using so logging events from third party software will show up in your unified logs - with the exception of java.util.logging that can't be bridged the same way that other logging frameworks are.

此外，SLF4J支持将其他日志框架桥接到您将使用的实际 SLF4J 实现，因此来自第三方软件的日志事件将显示在您的统一日志中 - 除了无法桥接的 java.util.logging与其他日志框架相同的方式。

Bridging jul is explained in the javadocsof SLF4JBridgeHandler.

SLF4JBridgeHandler的javadocs中解释了桥接 jul 。

I've had a very good experience using the SLF4J+Logback combination in several projects and LOG4J development has pretty much stalled.

我在几个项目中使用 SLF4J+Logback 组合的体验非常好，LOG4J 开发几乎停滞不前。

SLF4J has the following remaining downsides:

SLF4J 还存在以下缺点：

• It does not support varargs to stay compatible with Java < 1.5
• It does not support using both parametrized message and an exception at the same time.
• It does not contain support for a Nested Diagnostic Context (NDC, javadoc) which LOG4J has.

• 它不支持可变参数以与 Java < 1.5 保持兼容
• 它不支持同时使用参数化消息和异常。
• 它不包含对LOG4J 具有的嵌套诊断上下文（NDC，javadoc）的支持。

回答by James McMahon

The author (of both Logback and Log4j) has a list of reasons to change at http://logback.qos.ch/reasonsToSwitch.html.

作者（Logback 和 Log4j 的作者）在http://logback.qos.ch/reasonsToSwitch.html 上列出了更改的原因。

Here are a few that stuck out at me;

这里有一些让我印象深刻的；

• Faster implementation

  Based on our previous work on log4j, logback internals have been re-written to perform about ten times faster on certain critical execution paths. Not only are logback components faster, they have a smaller memory footprint as well.

• Automatic reloading of configuration files

  Logback-classic can automatically reload its configuration file upon modification. The scanning process is both fast and safe as it does not involve the creation of a separate thread for scanning. This technical subtlety ensures that logback plays well within application servers and more generally within the JEE environment.

• Stack traces with packaging data

  When logback prints an exception, the stack trace will include packaging data. Here is a sample stack trace generated by the logback-demo web-application.

  14:28:48.835 [btpool0-7] INFO c.q.l.demo.prime.PrimeAction - 99 is not a valid value java.lang.Exception: 99 is invalid
  at ch.qos.logback.demo.prime.PrimeAction.execute(PrimeAction.java:28) [classes/:na] at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) [struts-1.2.9.jar:1.2.9] at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) [struts-1.2.9.jar:1.2.9] at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) [struts-1.2.9.jar:1.2.9] at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) [servlet-api-2.5-6.1.12.jar:6.1.12]
  at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) [jetty-6.1.12.jar:6.1.12] at ch.qos.logback.demo.UserServletFilter.doFilter(UserServletFilter.java:44) [classes/:na] at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) [jetty-6.1.12.jar:6.1.12] at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361) [jetty-6.1.12.jar:6.1.12] at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) [jetty-6.1.12.jar:6.1.12] at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) [jetty-6.1.12.jar:6.1.12]

  From the above, you can recognize that the application is using Struts version 1.2.9 and was deployed under jetty version 6.1.12. Thus, stack traces will quickly inform the reader about the classes invervening in the exception but also the package and package versions they belong to. When your customers send you a stack trace, as a developer you will no longer need to ask them to send you information about the versions of packages they are using. The information will be part of the stack trace. See "%xThrowable" conversion word for details.

  This feature can be quite helpful to the point that some users mistakenly consider it a feature of their IDE.

• Automatic removal of old log archives

  By setting the maxHistory property of TimeBasedRollingPolicy or SizeAndTimeBasedFNATP, you can control the maximum number of archived files. If your rolling policy calls for monthly rollover and you wish to keep one year's worth of logs, simply set the maxHistory property to 12. Archived log files older than 12 months will be automatically removed.

• 更快的实施

  基于我们之前在 log4j 上的工作，重新编写了 logback 内部结构，使其在某些关键执行路径上的执行速度提高了大约 10 倍。logback 组件不仅速度更快，而且内存占用也更小。

• 自动重新加载配置文件

  Logback-classic 可以在修改后自动重新加载其配置文件。扫描过程既快速又安全，因为它不涉及创建单独的扫描线程。这种技术上的微妙之处确保 logback 在应用程序服务器中运行良好，更普遍地在 JEE 环境中运行。

• 堆栈跟踪与包装数据

  当 logback 打印异常时，堆栈跟踪将包含打包数据。这是 logback-demo web-application 生成的示例堆栈跟踪。

  14:28:48.835 [btpool0-7] 信息 cqldemo.prime.PrimeAction - 99 不是有效值 java.lang.Exception: 99
  在 ch.qos.logback.demo.prime.PrimeAction.execute(PrimeAction.java) 处无效:28) [classes/:na] 在 org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) [struts-1.2.9.jar:1.2.9] 在 org.apache.struts.action。 RequestProcessor.process(RequestProcessor.java:236) [struts-1.2.9.jar:1.2.9] 在 org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) [struts-1.2.9.jar :1.2.9] 在 javax.servlet.http.HttpServlet.service(HttpServlet.java:820) [servlet-api-2.5-6.1.12.jar:6.1.12]
  在 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) [jetty-6.1.12.jar:6.1.12] 在 ch.qos.logback.demo.UserServletFilter.doFilter(UserServletFilter.java:44 ) [classes/:na] 在 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) [jetty-6.1.12.jar:6.1.12] 在 org.mortbay.jetty.servlet。 ServletHandler.handle(ServletHandler.java:361) [jetty-6.1.12.jar:6.1.12] 在 org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) [jetty-6.1.12.jar] :6.1.12] 在 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) [jetty-6.1.12.jar:6.1.12]

  从上面可以看出该应用程序使用的是Struts 1.2.9版本，并且部署在jetty 6.1.12版本下。因此，堆栈跟踪将很快通知读者有关异常中存在的类以及它们所属的包和包版本。当您的客户向您发送堆栈跟踪时，作为开发人员，您将不再需要要求他们向您发送有关他们正在使用的软件包版本的信息。该信息将成为堆栈跟踪的一部分。有关详细信息，请参阅“%xThrowable”转换字。

  此功能非常有用，以至于某些用户错误地将其视为其 IDE 的功能。

• 自动删除旧的日志档案

  通过设置 TimeBasedRollingPolicy 或 SizeAndTimeBasedFNATP 的 maxHistory 属性，您可以控制归档文件的最大数量。如果您的滚动策略要求每月更新，并且您希望保留一年的日志，只需将 maxHistory 属性设置为 12。超过 12 个月的存档日志文件将被自动删除。

There may be a bias there, but the same guy did write both frameworks and if he is saying use Logback over Log4j he's probably worth listening to.

那里可能存在偏见，但同一个人确实编写了这两个框架，如果他说在 Log4j 上使用 Logback，他可能值得一听。

回答by Thorbj?rn Ravn Andersen

I would use slf4j for logging in all cases. This allow you to choose which actual logging backend you want to use, at deploy time instead of code time.

在所有情况下，我都会使用 slf4j 进行登录。这允许您在部署时而不是代码时选择要使用的实际日志记录后端。

This has proven to be very valuable to me. It allows me to use log4j in old JVM's, and logback in 1.5+ JVM's, and also java.util.logging if needed.

事实证明，这对我来说非常有价值。它允许我在旧 JVM 中使用 log4j，在 1.5+ JVM 中使用 logback，如果需要，还可以使用 java.util.logging。

回答by webstranger

Logback more Java EE aware:
in general (from code to documentation) it's keeping in mind containers – how multiple apps coexist, how class loaders implemented etc. Contexts for loggers, JNDI, JMX configuration included etc.

Logback 更了解 Java EE：
通常（从代码到文档）它牢记容器——多个应用程序如何共存，类加载器如何实现等。记录器的上下文，JNDI，包括 JMX 配置等。

from developer prospective almost same, Logback adds Parameterized logging (no need to use if(logger.isDebugEnabled()) to avoid string concatenation overhead )

从开发人员的角度来看几乎相同，Logback 添加了参数化日志记录（无需使用 if(logger.isDebugEnabled()) 以避免字符串连接开销）

Log4j – only giant plus is old JVM support, small (IMO) NDC (Logback only MDC), some extensions. For example I wrote extension for configureAndWatch for Log4j, no such thing for Logback

Log4j – 唯一的优势是旧的 JVM 支持、小型 (IMO) NDC（仅 Logback MDC）、一些扩展。例如我为 Log4j 编写了 configureAndWatch 的扩展，Logback 没有这样的东西

回答by anjanb

the original log4j and logback were designed and implemented by the same guy.

最初的 log4j 和 logback 是由同一个人设计和实现的。

several open source tools have used SLF4J. I don't see any significant deficiencies in this tool. So unless you have a lot extensions to log4j in your codebase, I would go ahead with logback.

一些开源工具已经使用了 SLF4J。我没有看到这个工具有任何重大缺陷。所以除非你的代码库中有很多 log4j 的扩展，否则我会继续使用 logback。

回答by matt b

I would think that your decision should come down to the same one it would if you were deciding between using log4j or Jakarta Commons Logging - are you developing a library which will be included in other applications? If so, then it doesn't seem fair to force users of your library to also use your logging library of choice.

我认为您的决定应该归结为与在使用 log4j 或 Jakarta Commons Logging 之间做出决定时的决定相同 - 您是否正在开发一个将包含在其他应用程序中的库？如果是这样，那么强制您的库的用户也使用您选择的日志库似乎是不公平的。

If the answer is no, I would just go with what is simpler to add and what you are more comfortable with. Sounds like logback is just as extensible and reliable as log4j, so if you're comfortable using it, go ahead.

如果答案是否定的，我会选择添加更简单且您更喜欢的内容。听起来 logback 与 log4j 一样可扩展和可靠，所以如果您习惯使用它，请继续。

回答by Thomas Owens

I'm not familiar with SLF4J, and I've only taken a brief look at logback, but two things come to mind.

我对 SLF4J 并不熟悉，而且我只是简单地看了一下 logback，但我想到了两件事。

First, why are you excluding a tool from examination? I think it's important to keep an open mind and examine all possibilities to choose the best one.

首先，为什么要从考试中排除工具？我认为保持开放的心态并检查所有可能性以选择最好的很重要。

Second, I think that in some projects one tool is a better than another tool, and the opposite might be true in a different project. I don't think that one tool is always better than another tool. There is, after all, no silver bullet.

其次，我认为在某些项目中，一种工具比另一种工具更好，而在不同的项目中可能恰恰相反。我不认为一种工具总是比另一种工具更好。毕竟，没有灵丹妙药。

To answer your question - Yes and no. It depends on the project, and how familiar the team is with one tool. I wouldn't say "don't use log4j" if the entire team is very comfortable with it, it meets all the needs, and logback doesn't offer anything that we need to complete the task.

回答您的问题 - 是和否。这取决于项目，以及团队对一种工具的熟悉程度。如果整个团队都对它非常满意，它满足所有需求，并且 logback 不提供我们完成任务所需的任何东西，我就不会说“不要使用 log4j”。