前两篇中介绍了jdk自带的logging,log4j,log4j2,logback等实际的日志框架。对于开发者而言,每种日志都有不同的写法,如果我们以实际的日志框架来进行编写,代码就限制死了,之后很难再更换日志系统,很难做到无缝切换。Java Web开发就经常提到一项原则:面向接口编程,而不是面向实现编程,所以我们应该按照一套统一的api进行日志编程,实际的日志框架来实现这套api,这样的话,即便切换日志框架,也可以做到无缝切换。这就是commons-logging与slf4j的初衷。
jdk自带的logging-->简称jul
Apache commons-logging-->简称jcl
1、Apache commons-logging
先从一个简单的使用案例来说明:
1.1、简单的使用案例
1 private static Log logger=LogFactory.getLog(JulJclTest.class);2
3 public static voidmain(String[] args){4 if(logger.isTraceEnabled()){5 logger.trace("commons-logging-jcl trace message");6 }7 if(logger.isDebugEnabled()){8 logger.debug("commons-logging-jcl debug message");9 }10 if(logger.isInfoEnabled()){11 logger.info("commons-logging-jcl info message");12 }13 }
上述Log、LogFactory都是commons-logging的接口和类。
1.2、使用原理
1 public static Log getLog(Class clazz) throwsLogConfigurationException {2 returngetFactory().getInstance(clazz);3 }
1.2.1、上述获取Log的过程大致分两个阶段
获取LogFactory的过程(从字面意思理解就是生成Log的工厂)
根据LogFactory获取Log的过程
commons-logging默认提供LogFactory实现是LogFactoryImpl,默认提供的Log实现是Jdk14Logger、Log4JLogger、SimpleLogger。
commons-logging包中的大致内容:
1.2.3、详细说明:
获取LogFactory的过程
系统属性中获取,即如下形式
1 System.getProperty("org.apache.commons.logging.LogFactory")
使用Java的SPI机制,来搜索对应的实现
1 META-INF/services/org.apache.commons.logging.LogFactory
简单来说就是搜寻哪些jar包中含有搜寻上述文件,该文件指明了对应的LogFactory实现。
从commons-logging的配置文件中寻找
commons-logging也可以拥有自己的配置文件,名字为commons-logging.properties,只不过目前大多数情况下,我们都没有去使用它,如果使用了该配置文件,常识从该配置文件中读取
属性“org.apache.commons.logging.LogFactory”。
最后还没找到的话,使用默认的org.commons.logging.impl.LogFactoryImpl
LogFactoryImpl是commons-logging提供的默认实现
根据LogFactory获取Log的过程
这个时候就需要寻找底层是选用哪种类型的日志,就以common-logging提供的默认实现为例,来详细看下这个过程
从commons-logging的配置文件中寻找Log实现类的名称
从commons-logging的配置文件中寻找“org.apache.commons.logging.Log”对应的Log类名。
从系统属性中寻找Log实现类名
1 System.getProperty("org.apache.commons.logging.Log")
如果上述方式没找到,则从ClassToDiscover属性中寻找calssToDiscover属性值
1 private static final String[] classesToDiscover ={2 "org.apache.commons.logging.impl.Log4JLogger",3 "org.apache.commons.logging.impl.Jdk14Logger",4 "org.apache.commons.logging.impl.Jdk13LumberjackLogger",5 "org.apache.commons.logging.impl.SimpleLog"
6 };
它会根据上述类名,依次进行创建,如果能创建成功,则使用该Log,然后返回给用户。
2、具体日志框架与commons-logging集成
2.1、commons-logging与jul集成
2.1.1、对应的maven依赖:
1
2 commons-logging
3 commons-logging
4 1.2
5
2.1.2、使用案例
1 private static Log logger=LogFactory.getLog(JulJclTest.class);2
3 public static voidmain(String[] args){4 if(logger.isTraceEnabled()){5 logger.trace("commons-logging-jcl trace message");6 }7 if(logger.isDebugEnabled()){8 logger.debug("commons-logging-jcl debug message");9 }10 if(logger.isInfoEnabled()){11 logger.info("commons-logging-jcl info message");12 }13 }
输出结果如下:
1 四月 27, 2015 11:13:33下午 com.demo.log4j.JulJclTest main2 信息: commons-logging-jcl info message
2.1.3、使用案例分析
获取LogFactory的过程
我们没有配置系统属性“org.apache.commons.logging.LogFactory”
我们没有配置commons-logging的commons-logging.properties配置文件
也没有含有“META-INF/services/org.apache.commons.logging.LogFactory”路径的jar包
所以commons-logging会使用默认的LogFactoryImpl作为LogFactory。
根据LogFactory获取Log过程
我们没有配置commons-logging的commons-logging.properties配置文件
我们没有配置系统属性“org.apache.commons.logging.Log”
所以就需要依次根据classToDiscover中的类名进行重建
先是创建org.apache.commons.logging.impl.Log4JLogger,创建失败,应为该类是依赖org.apache.log4j包中的类。
接着创建org.apache.commons.logging.impl.Jdk14Logger,创建成功,所以我们返回的就是Jdk14Logger,看下它是如何与jul集成的。
它内部有一个java.util.logging.Logger logger属性,所以Jdk14Logger的info("commons-logging-jcl info message")操作都会转化成由java.util.logging.Logger来实现:
1 logger = java.util.logging.Logger.getLogger(name); 就是使用jul原生的方式创建的一个java.util.logging.Logger。
使用jul原生的方式:
1 logger.log(Level.WARNING,"commons-logging-jcl info message");
1 四月 27, 2015 11:41:24下午 com.demo.log4j.JulJclTest main2 信息: commons-logging-jcl info message
原生的jdk的logging的日志级别是FINEST、FINE、INFO、WARNING、SEVERE分别对应我们常见的trace、debug、info、warn、error。
2.2、commons-logging与log4j集成
2.2.1、对应的maven依赖
1
2 commons-logging
3 commons-logging
4 1.2
5
6
7 log4j
8 log4j
9 1.2.17
10
2.2.3、使用案例
在类路径下加入log4j的配置文件log4j.properties
1 log4j.rootLogger =trace, console2 log4j.appender.console =org.apache.log4j.ConsoleAppender3 log4j.appender.console.layout =org.apache.log4j.PatternLayout4 log4j.appender.console.layout.ConversionPattern = %-d{yyyy-MM-dd HH:mm:ss} %m%n
使用方式
1 private static Log logger=LogFactory.getLog(Log4jJclTest.class);2
3 public static voidmain(String[] args){4 if(logger.isTraceEnabled()){5 logger.trace("commons-logging-log4j trace message");6 }7 if(logger.isDebugEnabled()){8 logger.debug("commons-logging-log4j debug message");9 }10 if(logger.isInfoEnabled()){11 logger.info("commons-logging-log4j info message");12 }13 }
代码没有变,还是使用commons-logging的接口编程,没有log4j的任何影子,这样commons-logging就与log4j集成了起来,我们可以通过log4j的配置文件来控制日志的显示级别。上述是trace级别(小于debug),所以trace、debug、info的都会显
示出来。
2.2.4、使用案例分析
1 获取获取LogFactory的过程
同上述jcl的过程一样,使用默认的LogFactoryImpl作为LogFactory
2 根据LogFactory获取Log的过程
同上述jcl的过程一样,最终会依次根据classesToDiscover中的类名称进行创建:
先是创建org.apache.commons.logging.impl.Log4JLogger,创建成功,因为此时含有log4j的jar包,所以返回的是Log4JLogger。
log4j内部有一个org.apache.log4j.Logger logger的属性,这个是Log4j的原生Logger,所以Log4JLogger都是委托这个Logger来完成的。
org.apache.log4j.Logger logger来历,使用原生的log4j的写法来生成,参见之前log4j原生的写法,我们知道下述过程会引发log4j的配置文件的加载,之后就进入了log4j的世界了
1 org.apache.log4j.Logger.getLogger(name)
测试案例中我们使用commons-logging输出的日志的形式如下(这里的logger是org.apache.commons.logging.impl.Log4JLogger类型):
1 logger.debug("commons-logging-log4j debug message");
其实就会转换成log4j原生的org.apache.log4j.Logger对象(就是上述获取的org.apache.log4j.Logger类型的logger对象)
1 logger.debug("log4j debug message");
2.3、commons-logging与log4j2集成
2.3.1 需要的jar包
commons-logging
og4j-api (log4j2的API包)
og4j-core (log4j2的API实现包)
l og4j-jcl (log4j2与commons-logging的集成包)
1
2 commons-logging
3 commons-logging
4 1.2
5
6
7 org.apache.logging.log4j
8 log4j-api
9 2.2
10
11
12 org.apache.logging.log4j
13 log4j-core
14 2.2
15
16
17 org.apache.logging.log4j
18 log4j-jcl
19 2.2
20
2.3.2、编写log4j2的配置文件log4j2.xml
1 <?xml version="1.0" encoding="UTF-8"?>
2
3
4
5
6
7
8
9
10
11
12
13
使用案例如下
private static Log logger=LogFactory.getLog(Log4j2JclTest.class);public static voidmain(String[] args){if(logger.isTraceEnabled()){
logger.trace("commons-logging-log4j trace message");
}if(logger.isDebugEnabled()){
logger.debug("commons-logging-log4j debug message");
}if(logger.isInfoEnabled()){
logger.info("commons-logging-log4j info message");
}
}
仍然使用commons-logging的Log接口和LogFactory来进行编写,但不到log4j2的影子。但是这个时候含有上述几个jar包,log4j2就与commons-logging集成了起来。
2.3.3、使用案例分析
案例过程分析,就是看看上述commons-logging的在执行原理的过程中是如何来走的:
先来看下上述 log4j-jcl(log4j2与commons-logging的集成包)的来历
我们知道,commons-logging原始的jar包中使用了默认的LogFactoryImpl作为LogFactory,该默认的LogFactoryImpl中的classesToDiscover(到上面查看它的内容)并没有log4j2对应的Log实现类。所以我们就不能使用这个原始包中默认
的LogFactoryImpl了,需要重新指定一个,并且需要给出一个apache的Log实现(该Log实现是用于log4j2的),所以就产生了log4j-jcl这个jar包,来看下这个jar包的大致内容:
这里面的LogFactoryImpl就是要准备替换commons-logging中默认的LogFactoryImpl(其中META-INF/services/下的那个文件起到重要的替换作用,下面详细说)
这里面的Log4jLog便是针对log4j2的,而commons-logging中的原始的Log4JLogger则是针对log4j1的。它们都是commons-logging的Log接口的实现
获取获取LogFactory的过程
这个过程就和jul、log4j1的集成过程不太一样了。通过java的SPI机制,找到了org.apache.commons.logging.LogFactory对应的实现,即在log4j-jcl包中找到的,其中META-INF/services/org.apache.commons.logging.LogFactory中的内容是
1 org.apache.logging.log4j.jcl.LogFactoryImpl
即指明了使用log4j-jcl中的LogFactoryImpl作为LogFactory。
根据LogFactory获取Log的过程
就来看下log4j-jcl中的LogFactoryImpl是怎么实现的
1 public class LogFactoryImpl extendsLogFactory {2
3 private final LoggerAdapter adapter = newLogAdapter();4 //略
5 }
这个LoggerAdapter是lo4j2中的一个适配器接口类,根据log4j2生产的原生的org.apache.logging.log4j.Logger实例,将它包装成你指定的泛型类。这里使用的LoggerAdapter实现是LogAdapter,它的内容如下:
1 public class LogAdapter extends AbstractLoggerAdapter{2 @Override3 protected Log newLogger(final String name, finalLoggerContext context) {4 return newLog4jLog(context.getLogger(name));5 }6 @Override7 protectedLoggerContext getContext() {8 return getContext(ReflectionUtil.getCallerClass(LogFactory.class));9 }10 }
我们可以看到,它其实就是将原生的log4j2的Logger封装成Log4jLog。这里就可以看明白了,下面来详细的走下流程,看看是什么时候来初始化log4j2的