将项目从log4j迁移到slf4j + log4j

Question

我有一个直接使用log4j的大型Web项目,以及许多第三方库和各种日志库.

• 我们的代码库 - 直接使用log4j.
• Hibernate - 使用slf4j和slf4j-log4j绑定.
• Spring - 使用commons-loggings.因此,它使用jcl-over-slf4j桥接api,slf4j本身和slf4j-log4j绑定.
• 其他众多的库,使用commons loggings或log4j.

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

• 清洁api.
• 性能改进 - 即使用参数化日志记录方法的能力.
• 能够在将来轻松切换到回溯(目前无法进行回退).
• 不需要额外的罐子,因为我已经拥有它们.

还有其他好处吗？有什么我不知道的缺点吗？

Answer 1

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

可能我移动到slf4j的主要原因(这仅适用于slf4j + logback)是你可以通过JMX重新加载配置,当你有一个问题在服务器重启时消失时这是很好的.

Answer 2

对我来说,有四个"杀手"功能值得你转移到Logback的痛苦,除了你已经提到过的那些(我亲自切换了我现在的主要项目,完美地工作):

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

顺便说一句,在做这个改变之后,切换回log4j很容易.由于Log4j也支持使用SLF4J迁移到Logback,因此来回切换只需要您选择要丢弃的jar文件(Log4j或Logback).只要相应的log4j.xml或logback配置文件位于类路径中,日志记录就能正常工作.