从common-logging到slf4j
common-logging
common-logging 是apache提供的一个通用的日志接口。用户可以自由选择第三方的日志组件作为具体实现,像log4j
,或者jdk自带的logging
。common-logging
会通过动态查找的机制,在程序运行时自动找出真正使用的日志库。当然,common-logging
内部有一个Simple logger
的简单实现,但是功能很弱。
所以使用common-logging
,通常都是配合着log4j
来使用。使用它的好处就是,代码依赖是common-logging
而非log4j
, 避免了和具体的日志方案直接耦合,在有必要时,可以更改日志实现的第三方库。
使用common-logging
的常见代码:
动态查找原理:Log
是一个接口声明。LogFactory
的内部会去装载具体的日志系统,并获得实现该Log
接口的实现类。LogFactory
内部装载日志系统的流程如下:
- 首先,寻找
org.apache.commons.logging.LogFactory
属性配置。- 否则,利用JDK1.3开始提供的service发现机制,会扫描classpah下的
META-INF/services/org.apache.commons.logging.LogFactory
文件,若找到则装载里面的配置,使用里面的配置。- 否则,从classpath里寻找
commons-logging.properties
,找到则根据里面的配置加载。- 否则,使用默认的配置:如果能找到
Log4j
则默认使用log4j实现,如果没有则使用JDK14Logger
实现,再没有则使用commons-logging内部提供的SimpleLog
实现。
从上述加载流程来看,只要引入了log4j
并在classpath配置了log4j.xml
,则commons-logging就会使log4j使用正常,而代码里不需要依赖任何log4j的代码。
slf4j
slf4j 全称为Simple Logging Facade for JAVA,java简单日志门面。类似于Apache Common-Logging,是对不同日志框架提供的一个门面封装,可以在部署的时候不修改任何配置即可接入一种日志实现方案。但是,他在 编译时 静态绑定真正的Log库。使用SLF4J时,如果你需要使用某一种日志实现,那么你必须选择正确的SLF4J的jar包的集合(各种桥接包)。
使用slf4j的常见代码:
静态绑定原理:SLF4J 会在编译时绑定import org.slf4j.impl.StaticLoggerBinder
, 该类里面实现对具体日志方案的绑定接入。任何一种基于slf4j的实现都要有一个这个类。
如:org.slf4j.slf4j-log4j12-1.5.6: 提供对log4j的一种适配实现。注意:如果有任意两个实现slf4j的包同时出现,那么就可能出现问题。
slf4j 与 common-logging 比较
common-logging通过动态查找的机制,在程序运行时自动找出真正使用的日志库。由于它使用了ClassLoader寻找和载入底层的日志库,导致了象OSGI这样的框架无法正常工作,因为OSGI的不同的插件使用自己的ClassLoader。OSGI的这种机制保证了插件互相独立,然而却使Apache Common-Logging无法工作。
slf4j在编译时静态绑定真正的Log库,因此可以在OSGI中使用。另外,SLF4J 支持参数化的log字符串,避免了之前为了减少字符串拼接的性能损耗而不得不写的if(logger.isDebugEnable())
,现在你可以直接写:logger.debug(“current user is: {}”, user)
。拼装消息被推迟到了它能够确定是不是要显示这条消息的时候,但是获取参数的代价并没有幸免。
slf4j + logback使用
pom.xml中引入依赖
|
|
之后,需要在resources中加入logback.xml
配置文件。
logback先找logback-test.xml
,没有则找logback.xml
文件,都找不到就使用BasicConfigurator
基本配置,BasicConfigurator
就是相当于等会贴出的logback.xml
文件内容的配置。
tips:以前的log4j.properties
文件可以用PropertiesTranslator
转换成logback.xml
文件内容。
logback.xml配置说明
先给一个简单的示例:
下面根据这个博客来讲解一下具体配置项:
logback 配置详解
根节点包含的属性
- scan 当此属性设置为true时,配置文件如果发生改变,将会被重新加载,默认值为true。
- scanPeriod 设置监测配置文件是否有修改的时间间隔,如果没有给出时间单位,默认单位是毫秒。当scan为true时,此属性生效。默认的时间间隔为1分钟。
- debug 当此属性设置为true时,将打印出logback内部日志信息,实时查看logback运行状态。默认值为false。
子节点
(1)设置上下文名称:<contextName>
每个logger都关联到logger上下文,默认上下文名称为default。但可以使用
(2)设置变量: <property>
用来定义变量值的标签,
通过<property>
定义的值会被插入到logger上下文中。定义变量后,可以使“${}”来使用变量。
例如使用
(3)获取时间戳字符串:<timestamp>
两个属性:
- key: 标识此
的名字; - datePattern: 设置将当前时间(解析配置文件的时间)转换为字符串的模式,遵循java.txt.SimpleDateFormat的格式。
例如将解析配置文件的时间作为上下文名称:
下面介绍与日志重点相关的三个子标签:
(1)<logger>
用来设置某一个包或者具体的某一个类的日志打印级别、以及指定<appender>
。<logger>
仅有一个name属性,一个可选的level和一个可选的addtivity属性。
- name: 用来指定受此loger约束的某一个包或者具体的某一个类。
- level: 用来设置打印级别,大小写无关:TRACE, DEBUG, INFO,WARN,ERROR,ALL和OFF,还有一个特俗值INHERITED或者同义词NULL,代表强制执行上级的级别。
如果未设置此属性,那么当前logger将会继承上级的级别。- addtivity: 是否向上级logger传递打印信息。默认是true。
这里所谓的向上级logger打印:<root>
是根级别,自己建立的其他<logger>
是子级别。如果<logger>
采用了默认的addtivity,那么它的日志也会打到<root>
中。
(2)<root>
也是logger元素,但是它是根logger。只有一个level属性,因为已经被命名为”root”.
level: 用来设置打印级别,大小写无关:TRACE, DEBUG, INFO, WARN, ERROR, ALL 和 OFF,不能设置为INHERITED或者同义词NULL。 默认是DEBUG。
<logger>
和<root>
可以包含零个或多个<appender-ref>
元素,标识这个appender将会添加到这个logger。
(3)<appender>
<appender>
是<configuration>
的子节点,是负责写日志的组件。<appender>
有两个必要属性name和class。name指定appender名称,class指定appender的全限定名。
(3.1)ConsoleAppender:
把日志添加到控制台,有以下子节点:
<encoder>
:对日志进行格式化。(具体参数稍后讲解 )<target>
:字符串 System.out 或者 System.err ,默认 System.out
(3.2)FileAppender
把日志添加到文件,有以下子节点:
<file>
:被写入的文件名,可以是相对目录,也可以是绝对目录,如果上级目录不存在会自动创建,没有默认值。<append>
:如果是 true,日志被追加到文件结尾,如果是 false,清空现存文件,默认是true。<encoder>
:对记录事件进行格式化。(具体参数稍后讲解 )<prudent>
:如果是 true,日志会被安全的写入文件,即使其他的FileAppender也在向此文件做写入操作,效率低,默认是 false。
(3.3)RollingFileAppender
滚动记录文件,先将日志记录到指定文件,当符合某个条件时,将日志记录到其他文件。有以下子节点:
<file>
:被写入的文件名,可以是相对目录,也可以是绝对目录,如果上级目录不存在会自动创建,没有默认值。<append>
:如果是 true,日志被追加到文件结尾,如果是 false,清空现存文件,默认是true。<encoder>
:对记录事件进行格式化。(具体参数稍后讲解 )<rollingPolicy>
:当发生滚动时,决定 RollingFileAppender 的行为,涉及文件移动和重命名。<triggeringPolicy >
: 告知 RollingFileAppender 合适激活滚动。<prudent>
:当为true时,不支持FixedWindowRollingPolicy。支持TimeBasedRollingPolicy,但是有两个限制,1不支持也不允许文件压缩,2不能设置file属性,必须留空。
rollingPolicy:
a.TimeBasedRollingPolicy: 最常用的滚动策略,它根据时间来制定滚动策略,既负责滚动也负责出发滚动。有以下子节点:<fileNamePattern>
:
必要节点,包含文件名及“%d”转换符, “%d”可以包含一个java.text.SimpleDateFormat指定的时间格式,如:%d{yyyy-MM}。如果直接使用 %d,默认格式是 yyyy-MM-dd。RollingFileAppender 的file字节点可有可无,通过设置file,可以为活动文件和归档文件指定不同位置,当前日志总是记录到file指定的文件(活动文件),活动文件的名字不会改变;如果没设置file,活动文件的名字会根据fileNamePattern 的值,每隔一段时间改变一次。“/”或者“\”会被当做目录分隔符。
<maxHistory>
:
可选节点,控制保留的归档文件的最大数量,超出数量就删除旧文件。假设设置每个月滚动,且
b.FixedWindowRollingPolicy: 根据固定窗口算法重命名文件的滚动策略。有以下子节点:<minIndex>
:窗口索引最小值<maxIndex>
:窗口索引最大值,当用户指定的窗口过大时,会自动将窗口设置为12。<fileNamePattern >
:
必须包含“%i”例如,假设最小值和最大值分别为1和2,命名模式为 mylog%i.log,会产生归档文件mylog1.log和mylog2.log。还可以指定文件压缩选项,例如,mylog%i.log.gz 或者 没有log%i.log.zip
triggeringPolicy:
SizeBasedTriggeringPolicy: 查看当前活动文件的大小,如果超过指定大小会告知RollingFileAppender 触发当前活动文件滚动。只有一个节点:<maxFileSize>
:这是活动文件的大小,默认值是10MB。
例如:每天生成一个日志文件,保存30天的日志文件。
例如:按照固定窗口模式生成日志文件,当文件大于20MB时,生成新的日志文件。窗口大小是1到3,当保存了3个归档文件后,将覆盖最早的日志。
另外还有SocketAppender、SMTPAppender、DBAppender、SyslogAppender、SiftingAppender,并不常用,这些就不在这里讲解了,大家可以参考官方文档。当然大家可以编写自己的Appender。
encoder:
负责两件事,一是把日志信息转换成字节数组,二是把字节数组写入到输出流。
目前PatternLayoutEncoder是唯一有用的且默认的encoder ,有一个<pattern>
节点,用来设置日志的输入格式。使用“%”加“转换符”方式,如果要输出“%”,则必须用“\”对“\%”进行转义。
桥接commons-logging
另外,如果需要桥接老的commons-logging,需要进入桥接器: