将项目从 log4j 迁移到 slf4j+log4j

2022-09-04 22:01:12

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

  • 我们的代码库 - 直接使用log4j。
  • Hibernate - 使用 slf4j 和 slf4j-log4j 绑定。
  • 春季 - 使用公共日志记录。因此,它使用 jcl-over-slf4j bridge api、slf4j 本身和 slf4j-log4j 绑定。
  • 其他众多的库,使用共享资源日志记录或log4j。

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

  • 更清洁的 api。
  • 性能改进 - 即使用参数化日志记录方法的能力。
  • 能够轻松地切换到将来的日志(目前日志备份是不可能的)。
  • 不需要额外的罐子,因为我已经有了它们。

还有其他好处吗?是否有任何我不知道的缺点?


答案 1

我看到的切换的唯一好处是,您只能通过一个框架汇集所有日志记录框架,这可能会简化您的配置。

我迁移到slf4j的主要原因(这仅适用于slf4j + logback)可能是您可以通过JMX重新加载配置,当您遇到服务器重新启动后消失的问题时,这非常有用。


答案 2

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

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

顺便说一句,完成此更改后,切换回log4j非常容易。由于迁移到Logback需要使用SLF4J(Log4j也支持SLF4J),因此来回切换只需要您选择要删除的jar文件(Log4j或Logback)。只要相应的 log4j.xml 或 logback 配置文件位于类路径中,日志记录就可以正常工作。


推荐