日志是每个应用程序在开发的过程中必不可少的组件,通过日志输出可以获取项目的一些运行信息,监控项目的运行指标等,同时,通过学习Java日志框架还可以学习到桥接器与适配器模式等。
日志框架
- log4j (日志实现)
log4j是最早出现的一个日志框架,由Apache组织开源,相应的依赖为:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
-
jul (日志实现)
jul在log4j之后才出现,是JDK自带的一个日志包,主要是怕影响了日志市场。jul的使用与log4j大同小异,主要的差异在于如果使用jul,则不需要导入额外的jar包。 -
jcl (jakatar commons logging 日志门面)
jcl是一个日志门面,也就是日志的抽象层与接口层,jcl不提供具体的日志实现,而是提供接口层,jcl中内置了许多日志实现类,在获取Logger对象时,jcl会依次加载一些实现类,如果有classpath下有实现,且没有抛出NoClassDefFoundError,则就会使用当前加载到的日志实现。
- logback(日志实现)
logack同log4j一样,出自同一个人之手,同样都是日志实现,但性能超过log4j,作者在设计logback的时候想到了log4j,于是也开发了一个日志抽象层,也就是日志门面。logack的依赖如下
<!-- https://mvnrepository.com/artifact/ch.qos.logback/logback-core -->
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>1.4.7</version>
</dependency>
logback-core是logback的核心包,实现了logback的所有功能。还有一个包为logback-classic,这个包除了引入了logback的核心包,还引入了适配slf4j的一些包。
<!-- https://mvnrepository.com/artifact/ch.qos.logback/logback-classic -->
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.4.6</version>
</dependency>
- slf4j(日志门面)
slf4j与logback一样都是一个人写的,兼容起来比较合适。slf4j只提供日志门面,不负责具体的日志实现,具体的日志实现原理为StaticLoggerBinder这个类,每一个实现了slf4j门面日志实现的jar包中都应该有这个类,只要一加载这个类,就会触发这个类的初始化和静态代码块方法,返回一个ILoggerFactory,这个对象负责具体的日志实现框架的创建。
slf4j日志门面的依赖如下:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.36</version>
</dependency>
- log4j2
apache在看到logback的 成功之后,借鉴了logback的实现思想,写了一个全新的日志框架,名为log4j2。log4j2的性能优于logback,除此之外,log4j2还是一个日志门面,由此可见,log4j2真是狼子野心,不仅提供了日志实现,还想做全新的日志门面,但是虽然它提供了日志门面,市面上绝大多数项目还是用slf4j做日志门面,至于日志实现,就看项目中选择用哪个jar包了。
log4j2的日志门面
<!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-api -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.19.0</version>
</dependency>
log4j2的日志实现
<!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.18.0</version>
</dependency>
日志适配包
我们知道,slf4j是个日志门面,要想在项目中进行具体的日志输出,肯定还是要靠日志实现的,由于 slf4j与logback的作者都是同一个人,只要引入了logback那么就会自动实现到logback。那其他的日志框架是怎么桥接到slf4j呢?slf4j的核心代码在这里
public static Logger getLogger(String name) {
ILoggerFactory iLoggerFactory = getILoggerFactory();
return iLoggerFactory.getLogger(name);
}
private static final void bind() {
try {
String msg;
try {
Set<URL> staticLoggerBinderPathSet = null;
if (!isAndroid()) {
staticLoggerBinderPathSet = findPossibleStaticLoggerBinderPathSet();
reportMultipleBindingAmbiguity(staticLoggerBinderPathSet);
}
StaticLoggerBinder.getSingleton();
INITIALIZATION_STATE = 3;
reportActualBinding(staticLoggerBinderPathSet);
} catch (NoClassDefFoundError var7) {
msg = var7.getMessage();
if (!messageContainsOrgSlf4jImplStaticLoggerBinder(msg)) {
failedBinding(var7);
throw var7;
}
INITIALIZATION_STATE = 4;
Util.report("Failed to load class \"org.slf4j.impl.StaticLoggerBinder\".");
Util.report("Defaulting to no-operation (NOP) logger implementation");
Util.report("See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.");
} catch (NoSuchMethodError var8) {
msg = var8.getMessage();
if (msg != null && msg.contains("org.slf4j.impl.StaticLoggerBinder.getSingleton()")) {
INITIALIZATION_STATE = 2;
Util.report("slf4j-api 1.6.x (or later) is incompatible with this binding.");
Util.report("Your binding is version 1.5.5 or earlier.");
Util.report("Upgrade your binding to version 1.6.x.");
}
throw var8;
} catch (Exception var9) {
failedBinding(var9);
throw new IllegalStateException("Unexpected initialization failure", var9);
}
} finally {
postBindCleanUp();
}
}
slf4j是直接调用了classpath下的StaticLoggerBinder.getSingleton();这个类的这个方法的。StaticLoggerBinder这个类在哪个包里呢?其实不是在slf4j-api这个包里,而是在每个与slf4j绑定的适配包中,也就是说,你导入了哪个日志框架与slf4j的适配包,这个适配包里就会有StaticLoggerBinder这个类,但是ILoggerFactory是每个日志框架提供的不同的实现,这样每个Factory工厂就可以跟据导入的实现生产不同的日志配置。
也就是说slf4j的适配包提供了日志工厂、slf4j的Logger的实现等。
- jul - slf4j的适配包
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
<version>1.7.32</version>
</dependency>
这是jul适配的相关类
- logj4 - slf4j的适配包
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.2</version>
</dependency>
可以看到这个jar包的包名和类名与slf4j-jdk14是差不多的。
- logback - slf4j
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.2.8</version>
</dependency>
logback的日志实现也是绑定了相关slf4j的类的。
- log4j2 - slf4j
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>2.12.4</version>
</dependency>
log4j2适配slf4j
日志桥接包
什么是日志桥接包?因为slf4j出现的比较晚,很多的项目可能项目中直接用的是log4j、jul、jcl等,那么如果是用到了这些实现,该如何全部统一到slf4j + logback呢?
从这张官方图就可以看出来了,如果想要替换到项目中已有的jar包,则需要做以下三个步骤:
- 排除掉原有jar包 (例如排除掉其他框架引入的log4j)。
- 如果直接把原有jar包排除了,程序肯定就直接运行不起来了,所以此时需要导入这个jar包的桥接包,这个桥接包就是一个狸猫换太子包,偷天换日包,这个包模仿了原有实现包所有的包名和类名,但是确实掉的slf4j的API。
- 引入slf4j和具体的日志实现。
- log4j 桥接到 slf4j
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>1.7.32</version>
</dependency>
模仿了log4j的包与类,伪造了log4j但是真正调用的slf4j。
- jcl桥接到slf4j
有些项目可能没有用具体的日志实现,而是用的jcl作为日志门面,这个时候还是同样的道理,排除掉真正的jcl包,导入到jcl与slf4j的桥接包。
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.32</version>
</dependency>
可以看到,虽然jar包名是叫jcl-over-slf4j,但是包名都是apache commons logging的,这个包也是和commons-logging这个包一模一样的包名和类名,但是调用的是Slf4j的API,包括原有的Log对象,也是适配了Slf4j的log对象。
- jul桥接到slf4j
Java Logging API相关类由JDK提供,我们不能排除掉JDK,因而,在"Java Logging API转SLF4J"过程中采用的转换方案跟"JCL转SLF4J"和"Log4J转SLF4J"采用的转换方案不同,具体思路是以jul-to-slf4j提供的"org.slf4j.bridge.SLF4JBridgeHandler"替换掉Java Logging API使用的Handler(Handler即是Appender),Java Logging API原来使用的Handler将日志输出到Console,文件,数据库等,现在"org.slf4j.bridge.SLF4JBridgeHandler"将日志输出到SLF4J日志框架。简单来说,就是将原本Java Logging API的日志输出重定向到SLF4J日志框架。
我们看一下jul-over-slf4j的jar包实现
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>1.7.32</version>
</dependency>
Slf4jBridgeHandler
//JUL发布日志的方法
public void publish(LogRecord record) {
if (record != null) {
org.slf4j.Logger slf4jLogger = this.getSLF4JLogger(record);
String message = record.getMessage();
if (message == null) {
message = "";
}
if (slf4jLogger instanceof LocationAwareLogger) {
this.callLocationAwareLogger((LocationAwareLogger)slf4jLogger, record);
} else {
this.callPlainSLF4JLogger(slf4jLogger, record);
}
}
}
//获取slf4j的logger
protected org.slf4j.Logger getSLF4JLogger(LogRecord record) {
String name = record.getLoggerName();
if (name == null) {
name = "unknown.jul.logger";
}
return LoggerFactory.getLogger(name);
}
//真正调用slf4j的方法发布
protected void callPlainSLF4JLogger(org.slf4j.Logger slf4jLogger, LogRecord record) {
String i18nMessage = this.getMessageI18N(record);
int julLevelValue = record.getLevel().intValue();
if (julLevelValue <= TRACE_LEVEL_THRESHOLD) {
slf4jLogger.trace(i18nMessage, record.getThrown());
} else if (julLevelValue <= DEBUG_LEVEL_THRESHOLD) {
slf4jLogger.debug(i18nMessage, record.getThrown());
} else if (julLevelValue <= INFO_LEVEL_THRESHOLD) {
slf4jLogger.info(i18nMessage, record.getThrown());
} else if (julLevelValue <= WARN_LEVEL_THRESHOLD) {
slf4jLogger.warn(i18nMessage, record.getThrown());
} else {
slf4jLogger.error(i18nMessage, record.getThrown());
}
}
jul-to-slf4j这个包相对来说比较特殊,因为jdk自带的包是没法排除的,那么这个时候slf4j设计了一个桥接器,这个桥接器是如何把jul的日志全部用slf4j输出的。SLF4JBridgeHandler 这个类设计了两个方法:
public static void install() {
LogManager.getLogManager().getLogger("").addHandler(new SLF4JBridgeHandler());
}
public static void removeHandlersForRootLogger() {
Logger rootLogger = getRootLogger();
Handler[] handlers = rootLogger.getHandlers();
for(int i = 0; i < handlers.length; ++i) {
rootLogger.removeHandler(handlers[i]);
}
}
removeHandlersForRootLogger 这个方法的作用是将rootLog的所有Handler全都移除,install方法的作用是将slf4j的桥接Handler添加到rootLog的Handler中。那这样的话,如果项目中有其他地方获取到Logger的话,只要不针对这个log做定制化设置,都是继承的rootLog,而rootLog在发布日志的时候,就是调用了Slf4j的API。
这行代码就是根据log的name获取日志对象,就可以具体桥接到某个日志实现框架了。
可以看到,这样就桥接到slf4j了,记得一定要先调用绑定器的两个方法。
而jul-to-slf4j 唯一无法解决的就是,如果针对jul的某个logger做了定制化设计,此时就桥接就失效了,因为jdk的源码是修改不了的。