复杂Spring项目中SLF4J最佳使用姿势

一、Java日志体系概述

复杂Spring项目中SLF4J最佳使用姿势_第1张图片
图1-1 Java日志体系概况

图1-1 展示了Java日志体系的三个主要部分:

  1. 日志门面接口(SLF4J、JCL)
  2. 一系列绑定和桥接
  3. 具体的日志实现

先来两个例子:

  • Spring项目中通过Commons Logging直接使用log4j


    复杂Spring项目中SLF4J最佳使用姿势_第2张图片
    图1-2 通过Commons Logging使用log4j

    本例中由于spring-core中原生依赖commons-logging,所以只需要添加log4j和log4j的配置文件就能work(当然引入其它依赖还会有解冲突的工作要做)。

  • Spring项目中通过SLF4J使用log4j


    复杂Spring项目中SLF4J最佳使用姿势_第3张图片
    图1-3 Spring中通过SLF4J使用log4j

    此例中比之前多引入了3个jar包并且还排除了commons-logging依赖。如果对此有疑问,请看后面的详细解说。

二、为什么要使用SLF4J

复杂Spring项目中SLF4J最佳使用姿势_第4张图片
图2-1 列举几点简单的原因

三、SLF4J的最佳实践

现在越来越多项目使用SLF4J (为什么要使用SLF4j)作为一个日志门面,而不是使用古老的Commons Logging。这给复杂的Maven构建带来了新的挑战,因为SLF4J仅当依赖被正确配置时才能正常工作。为了搞清楚为什么如此,让我们来看看组成SLF4J中不同的组件。

  • slf4j-api 包含了SLF4J API,比如,使用SLF4J的一个应用或者库直接依赖的所有classes。
  • 一系列绑定,它们(slf4j-log4j12,slf4j-jdk14和slf4j-jcl)基于一个已存在的日志框架来实现了SLF4J API,或者为SLF4J开发原生实现(slf4j-nop和slf4j-simple)。
    绑定的原理是因为slf4j-api中的LogFactory通过StaticLoggerBinder.getSingleton()获取具体实现logger,一个绑定包实现了org/slf4j/impl/StaticLoggerBinder.class,所以它们在编译时刻就绑定在一起,而绑定包中的StaticLoggerBinder类会绑定对应的实现。这部分看看源码就一目了然了。
  • 一系列桥接,它们把已存在的日志门面适配到SLF4J(jul-to-slf4j)。或者仿效已存在的日志门面或者实现(jcl-over-slf4j和log4j-over-slf4j)。
    桥接的原理是把对应的门面日志接口重新实现了一遍,包名、类名、接口都一样,只是具体实现它委托给SLF4J了。

SLF4J要在一个Maven构建的项目中正确工作,下列条件必须满足:

  1. 项目必须依赖slf4j-api。如果项目本身使用SLF4J,而且并不依赖任何绑定或者桥接,那么这应该是一个直接依赖。如果SLF4J被项目中的一个或者多个依赖使用,但是并不被项目本身使用,那么可以优先让Maven的依赖管理(dependency management)系统把它作为一个传递依赖给包含进来。
  2. 如果一个项目生成一个可执行的构建(有Main-Class的JAR,WAR,EAR或者二进制distribution),那么它必须有一个依赖,并且和仅一个绑定。一个binding在运行时总是必须的,但是多个bindings将会导致不可预期的行为。
  3. 项目可以有任意个SLF4J桥接依赖,这不包括被binding使用的API的桥接。比如,如果slf4j-log4j12被作为一个binding,那么项目不能依赖log4j-over-slf4j。否则应用可能因为无限循环而崩溃。
  4. 如果项目依赖一个桥接,emulate一个已存在的日志API,那么它一定不能同时依赖你这个API。比如,如果jcl-over-slf4j被使用,那么项目一定不能依赖commons-logging。否则行为将不可预测。
  5. 依赖不能混用SLF4J 1.4.x的构建和1.5.x的构建,因为它们相互不兼容。
    应当注意规则2仅适用可执行构建。一个生成一个库构建的项目不应该依赖任何SLF4J binding,除了在test scope。原因是在编译或者运行scope依赖一个指定的SLF4J binding将会在下游项目中impose一个特殊的日志实现。在每个库都遵循这个实践的完美世界里,将会非常容易地验证以上5个条件:在从SLF4J 1.5.x到每一个生成可执行构建的Maven项目中,期望的binding(任何必要的桥接)上简单添加一个依赖就足够了。
    但是世界并不完美,并且有很多第三方库并没有依赖特定的SLF4J bindings和日志实现。如果一个项目开始依赖这种库的依赖,如果没有采取对策,事情很容易失控。对于有很多依赖的项目这尤其明显,它几乎总会让以上5条规则不再被满足。

Maven并没有一些必要的特性,这些特性强制这些条件实现校验,并且强制它们具备一些准则和人工干预。另一方面,当系统地应用时有一个非常简单和高效的策略:

  • 确保在你控制下的项目中,总是遵循上诉描述的策略。
  • 对于不遵循这些最佳实践的第三方库,在对应的依赖声明上排除依赖来移除对SLF4J binding上的传递依赖。需要注意,如果在一个库在多模块Maven项目的多种模块中被使用,那么在父POM中的dependency management section里声明这些排除会很方便,这就不需要再依赖中重复排除。

四、SLF4J官方说明

  1. SLF4J与每种具体日志框架的绑定规则。


    复杂Spring项目中SLF4J最佳使用姿势_第5张图片
    图4-1 slf4j官方逻辑图
  2. 把Commons logging,log4j和java.util.logging桥接到SLF4J,底层使用logback的case。


    复杂Spring项目中SLF4J最佳使用姿势_第6张图片
    图4-2 桥接到SLF4J,并使用logback日志框架

    比如我们项目中依赖了spring-core,因为它原生依赖commons-logging,所以需要用jcl-over-slf4j.jar桥接包来代替commons-logging把具体实现委托给slf4j。jcl-over-slf4j和commons-logging拥有相同的包名、类名、接口,所以项目中要排除掉commons-logging。

  3. 把commons-logging和java.util.logging桥接到SLF4J,底层用log4j


    复杂Spring项目中SLF4J最佳使用姿势_第7张图片
    图4-3 桥接到SLF4J,底层用log4j
  4. 把commons-logging和log4j桥接到SLF4J,底层用java.util.logging


    复杂Spring项目中SLF4J最佳使用姿势_第8张图片
    图4-4 桥接到SLF4J,底层用java.util.logging

总结:
在Spring中,我们通常会依赖很多jar,它们使用不同的日志门面接口或者不同的日志框架,只要遵循第三节中的5点规则,加上排除冲突的依赖就能正常使用日志啦。

附录,推荐排除冲突的两种方式:

  1. 如果有多个子模块依赖相同的包,那么放在 中来管理:


    com.acme
    java-coffee-machine
    7.5.194.3


    org.slf4j
    slf4j-log4j12



  2. 在自己公司的maven仓库中放一个空包,scope=provided,这样可以全局排除依赖:

    commons-logging
    commons-logging
    ${empty.version}
    provided

参考资料:

  • 复杂Maven项目中管理SLF4J依赖
  • java日志工具之SLF4J
  • slf4J官网
  • slf4j在maven仓库中的相关包
  • How to use log4j 2.0 and slf4j and Commons Logging together
  • log4j-over-slf4j与slf4j-log4j12共存stack overflow异常分析

你可能感兴趣的:(复杂Spring项目中SLF4J最佳使用姿势)