将项目从 log4j 迁移到 slf4j+log4j

Question

我有一个直接使用 log4j 的大型 Web 项目，以及许多第 3 方库和日志记录库的组合。

• 我们的代码库 - 直接使用 log4j。
• Hibernate - 使用 slf4j 和 slf4j-log4j 绑定。
• Spring - 使用公共日志记录。因此，它使用 jcl-over-slf4j 桥接 API、slf4j 本身和 slf4j-log4j 绑定。
• 其他许多库，使用公共日志记录或 log4j。

我正在考虑将我们自己的代码库迁移到 slf4j api，但我不确定好处是否足够强大并且值得付出努力。目前我知道以下好处：

• 更干净的 api。
• 性能改进 - 即使用参数化日志记录方法的能力。
• 将来能够轻松切换到 logback（目前 logback 是不可能的）。
• 不需要额外的罐子，因为我已经有了它们。

还有其他好处吗？有什么我还没有意识到的缺点吗？

Answer 1

我认为切换的唯一好处是您可以仅通过一个框架汇集所有日志记录框架，这可能会简化您的配置。

我转向 slf4j（这只适用于 slf4j + logback）的主要原因可能是您可以 通过 JMX 重新加载配置< /a>，当您遇到的问题随着服务器重新启动而消失时，这非常有用。

Answer 2

对我来说，除了你已经提到的那些功能之外，还有四个“杀手级”功能值得转移到 Logback（我个人切换了我当前的主要项目，工作完美）：

• 自动重新加载配置文件. 这对于生产系统来说非常棒。如果您只想将“调试”设置为一个类，但不想关闭整个系统，那么这个是无价的。
• 能够在配置中使用包含文件。这使您可以为所有服务/JVM 拥有一组“主”日志记录设置，然后您可以指定可能需要特殊处理的任何包。目前我们有大约 10 个服务，它们都有一个很大但大部分相似的 log4j.xml 副本。我们现在将其更改为一个主 logback 配置文件，并将该文件包含在每个服务的 logback 配置文件中。主文件仍然很大，但特定于服务的文件应该非常小。更易于维护。
• 条件处理。通过这种方式，您可以指定“if QAServer =>则将日志记录级别设置为“DEBUG”，否则为“INFO”之类的内容。同样，非常适合拥有不具有以下功能的单个配置：在生产和开发/QA 服务器之间进行更改。
• 自动压缩和删除旧日志文件。您可以指定要保留的存档文件数量，并可选择在创建 n+1 文件后压缩它们。 ，它会检测到太多，并会删除最旧的一个，每个文件/服务均可配置，无需执行任何特定于系统的操作（批处理文件和/或脚本）

。 ，切换回 log4j 非常容易，因为迁移到 Logback 需要使用 SLF4J（Log4j 也支持），因此来回切换只需要选择要删除的 jar 文件（Log4j 或 Logback 的）即可。 xml 或 logback 配置文件位于类路径中，日志记录将正常工作。