Commons-logging + Log4j 入门指南

三篇文章混在一起的感觉！！！O(∩_∩)O哈哈~

Apache组织开发了一套用于支持Logging的Log4J，Java?1.4版本也引入了一套内置的 Logging框架，如果开发者想在这两套Logging系统之间自由的切换，该怎么办呢？答案就是，使用Commons?Logging。 Commons?Logging定义了一套抽象的Logging接口，用户可以通过配置，使这些接口指向任何一个已存在的Logging系统。

⑴ 首先在classpath下寻找自己的配置文件commons-logging.properties，如果找到，则使用其中定义的Log实现类；这个属性文件至少必须定义org.apache.commons.logging.Log属性，它的值应该是上述任意Log接口实现的完整限定名称。
⑵ 如果上面的步骤失败，Commons的Logging接着检查系统属性org.apache.commons.logging.Log。
System.setProperty("org.apache.commons.logging.Log","org.apache.commons.logging.impl.Log4JLogger");
⑶ 如果找不到org.apache.commons.logging.Log系统属性，Logging接着在CLASSPATH中寻找log4j的类。如果找到了，Logging就假定应用要使用的是log4j。不过这时log4j本身的属性仍要通过log4j.properties文件正确配置。
通过jar的Service Provider Discovery机制查找 "META-INF/services/org.apache.commons.logging.Log"对应的资源，Service Provider Discovery是JDK1.3之后出现的，我们熟知的XML解析器的查找过程就是利用这个机制.
⑷ 如果上述查找均不能找到适当的Logging API，但应用程序正运行在JRE 1.4或更高版本上，则默认使用JRE 1.4的日志记录功能。
⑸ 最后，如果上述操作都失败，则应用将使用内建的SimpleLog。SimpleLog把所有日志信息直接输出到System.err。

可见，commons-logging总是能找到一个日志实现类，并且尽可能找到一个“最合适”的日志实现类。我说它“很贴心”实际上是因为：1、可以不需要配置文件；2、自动判断有没有Log4j包，有则自动使用之；3、最悲观的情况下也总能保证提供一个日志实现（SimpleLog）。
可以看到，commons-logging对编程者和Log4j都非常友好。
为了简化配置commons-logging，一般不使用commons-logging的配置文件，也不设置与commons-logging相关的系统环境变量，而只需将Log4j的Jar包放置到classpash中就可以了。这样就很简单地完成了commons-logging与Log4j的融合。如果不想用Log4j了怎么办？只需将classpath中的Log4j的Jar包删除即可。
就这么简单！

Commons logging的关键点：

    * 提供一个日志记录功能的抽象
    * 提供一种从该抽象到具体日志记录实现的映射
    * 提供默认的映射和发现机制，提高自身的易用性
看花的人多，懂花的少哦。------俺们力争去做懂花人。等老了，一边夕阳西下，一边品茶赏花，岂不乐哉。

日志的级别从高到低依次为:fatal,error,warn,info,debug,trace.
自己只适用三种就够了,调试用debug,运行时有意义的信息用info,错误用error

log4j.rootLogger是最最重要的一个属性了，它定义日志信息的“输出级别”和“输出目的地”。
设置分两部分,第一个逗号之前的是第一部分，指定“输出级别”；后面的是第二部分，指定“输出目的地”。可以同时指定多个“输出目的地”，以逗号隔开。

不同的appender,打印的基本可以单独设置,例如log4j.appender.logfile.Threshold =debug

输出格式里%t指线程

“同时使用commons-logging和Log4j”的原因是，简化使用和配置。
强调一点，“同时使用commons-logging和Log4j”，与“单独使用Log4j”相比，并不会带来更大的学习、配置和维护成本，反而更加简化了我们的工作。我想这也是为什么“所有用到Log4j的项目一般也同时会用到commons-loggin”的原因之一吧。
Commons-logging能帮我们做什么？
提供一个统一的日志接口，简单了操作，同时避免项目与某个日志实现系统紧密a耦合
很贴心的帮我们自动选择适当的日志实现系统（这一点非常好！）它甚至不需要配置

private static Log log = LogFactory.getLog(YouClassName.class);
注意这里定义的是static成员，以避免产生多个实例。
LogFactory.getLog()方法的参数使用的是当前类的class，这是目前被普通认为的最好的方式。为什么不写作LogFactory.getLog(this.getClass())？因为static类成员访问不到this指针！
将commons-logging和Log4j的jar包都放置到classpath下，同时也将Log4j的配置文件放到classpath中，两者就可以很好的合作。

采用Log4j配合commons-logging作为日志系统，是目前Java领域非常非常流行的模式，使用非常非常的普遍。两者的结合带来的结果就是：简单 + 强大。
commons-logging提供了简捷、统一的接口，不需要额外配置，简单；
Log4j功能非常全面、强大；
commons-logging仅仅对Log4j(当然还包括其它LOG实现)作了一层包装，具体的日志输出还是在内部转交给身后的Log4j来处理；而Log4j虽然做了所有的事情，却甘作绿叶，从不以真身示人。
两者堪称绝配。

======================================================================

***为什么要使用commons-logging+log4j
commons-logging和log4j都是[[Apache:http://www.apache.org]]下的开源项目。~
commons-logging的目的是为“所有的Java日志实现”提供一个统一的接口，使项目与日志实现工具解耦，它自身的日志功能比较弱（只有一个简单的 SimpleLog），所以一般不会单独使用它。~
Log4j的功能非常强大，是目前最主流的java日志工具。~
结合使用2者可以避免使项目与log4j紧密耦合，用户可以轻松切换到其他日志工具，同时又可以使用log4j的强大功能。~
***commons-logging如何自动选择适当的日志实现工具
我们在使用commons-logging+日志实现工具时，我们的代码只需要和commons-logging打交道，又commons- logging去选择适当的日志实现工具。这里我们看一下commons-logging是如何去选择实现工具的~
-首先在classpath下寻找自己的配置文件commons-logging.properties，如果找到，则使用其中定义的Log实现类
org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
上面这个配置，commons-logging会使用commons-logging的SimpleLog
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
这个配置，commons-logging就会选择使用log4j
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger
这个配置，commons-logging会选择jdk的logger
-如果找不到commons-logging.properties文件，则在查找是否已定义系统环境变量org.apache.commons.logging.Log，找到则使用其定义的Log实现类
-否则，查看classpath中是否有Log4j的包，如果发现，则自动使用Log4j作为日志实现类
-否则，使用JDK自身的日志实现类（JDK1.4以后才有日志实现类）
-否则，使用commons-logging自己提供的一个简单的日志实现类SimpleLog
可见，commons-logging总是能找到一个日志实现类，并且尽可能找到一个最合适的日志实现类。~
为了简化配置，我们可以不使用commons-logging的配置文件，也不设置commons-logging相关的环境变量，只需将log4j的包放入classpath就可以了，这样就可以完成commons-logging与Log4j的结合。如果以后不想使用log4j，只需将log4j的包从classpath中移除就可以了。
***如何在代码中输出日志
-导入所需commons-logging的类~
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
-在自己的类中定义一个org.apache.commons.logging.Log类的私有静态类变量
private static Log log = LogFactory.getLog(ClassName.class);
-使用静态类变量输出日志信息~
为了方便的控制日志输出,把日志分成了不同的级别，从低到高分别是调试，信息，警告，错误，致命错误。这样我们可以通过log4j的配置决定只输出某个级别以上的日志。例如，在开发时我们将debug(调试)及以上的日志全部输出，而在项目正常运行时，设置为只输出warn(警告)及以上的日志。
//输出调试级别的日志信息
log.debug("debug");
//输出信息级别的日志信息
log.info("information");
//输出警告级别的日志信息
log.warn("warning");
//输出错误级别的日志信息
log.error("error");
//输出致命错误级别的日志信息
log.fatal("fatal");
正因为我们可以通过配置文件来设置日志输出的级别，所以写代码时我们并不知道某条日志是不是会真正输出，比如
log.debug("debug");
在设置了日志输出级别为info(信息)或以上的情况下，是不会被真正输出的。~
这种情况下，为了节省资源，我们可以在输出一条日志前加一个判断语句，判断该日志确实会被输出的情况下才去执行输出代码，如下所示
//输出调试级别的日志信息
if(log.isDebugEnabled()){
     log.debug("debug");
}
//输出信息级别的日志信息
if(log.isInfoEnabled()){
     log.info("information");
}
//输出警告级别的日志信息
if(log.isWarnEnabled()){
     log.warn("warning");
}
//输出错误级别的日志信息
if(log.isErrorEnabled()){
     log.error("error");
}
//输出致命错误级别的日志信息
if(log.isFatalEnabled()){
     log.fatal("fatal");
}
***灵活使用log4j
在classpath下创建log4j.properties,下面讲解log4j的主要配置
-Appender~
Appender用来指明将所有的log信息存放到什么地方，Log4j中支持多种appender，如    console、files、GUI components、NT Event Loggers等，一个Logger可以拥有多个Appender，也就是你既可以将Log信息输出到屏幕，同时存储到一个文件中。~
配置Appender的语法
log4j.appender.appenderName = fully.qualified.name.of.appender.class
log4j.appender.appenderName.option1 = value1
...
log4j.appender.appenderName.optionN = valueN
Log4j提供的appender有以下几种：
org.apache.log4j.ConsoleAppender（控制台）
org.apache.log4j.FileAppender（文件）
org.apache.log4j.DailyRollingFileAppender（每天产生一个日志文件）
org.apache.log4j.RollingFileAppender（文件大小到达指定尺寸的时候产生新文件）
org.apache.log4j.WriterAppender（将日志信息以流格式发送到任意指定的地方）
-Layout~
Layout的作用是控制Appender的输出方式，也就是格式化输出的信息。~
配置Layout的语法
log4j.appender.appenderName.layout = fully.qualified.name.of.layout.class
log4j.appender.appenderName.layout.option1 = value1
....
log4j.appender.appenderName.layout.optionN = valueN
Log4j提供的layout有以下几种：
org.apache.log4j.HTMLLayout（以HTML表格形式布局）
org.apache.log4j.PatternLayout（可以灵活地指定布局模式）
org.apache.log4j.SimpleLayout（包含日志信息的级别和信息字符串）
org.apache.log4j.TTCCLayout（包含日志产生的时间、线程、类别等等信息）
Log4J采用类似C语言中的printf函数的打印格式格式化日志信息，打印参数如下：
%m 输出代码中指定的消息
%p 输出优先级，即DEBUG，INFO，WARN，ERROR，FATAL
%r 输出自应用启动到输出该log信息耗费的毫秒数
%c 输出所属的类目，通常就是所在类的全名
%t 输出产生该日志事件的线程名
%n 输出一个回车换行符，Windows平台为“\r\n”，Unix平台为“\n”
%d 输出日志时间点的日期或时间，默认格式为ISO8601，也可以在其后指定格式
例如：%d{yyyy年MMM月dd日HH:mm:ss,SSS}，输出类似：2008年4月07日15:10:58,857
%l 输出日志事件的发生位置，包括类目名、发生的线程，以及在代码中的行数。
例如：Testlog4.main(TestLog4.java:10)
-Logger~
Logger用来定义日志信息的输出级别和输出目的地。Logger可分为两类
log4j.rootLogger 对所有日志输出起作用
log4j.logger.xx.yy 只对xx.yy包下面的日志输出起作用
例如
log4j.rootLogger=WARN,CONSOLE 指定所有日志级别为warn，采用名为CONSOLE的Appender输出
log4j.logger.com.orsoft=DEBUG,FILE 指定com.orsoft包内的日志，级别为DEBUG，采用名为FILE的Appender来输出。
可以看到，Logger存在类似继承的关系，所有其它Logger均继承自log4j.rootLogger，log4j.logger.xx.yy继承自log4j.logger.xx。~
当某条日志符合多个Logger时，如何判断它的输出级别和输出目的地呢？
我的理解是，输出级别由最底层的Logger决定，输出目的地则是互补关系，将会输出到所有符合条件的Logger所指定的Appender。~
例如
log4j.rootLogger=WARN,CONSOLE
log4j.logger.com.orsoft=DEBUG,FILE
log4j.logger.org.aaa=ERROR
对com.orsoft下的日志，输出级别为DEBUG，输出目的地为CONSOLE和FILE~
对org.aaa下的日志，输出级别为ERROR，输出目的地为CONSOLE~
其它包下的日志，输出级别为WARN，输出目的地为CONSOLE~
log4j.rootLogger=WARN,CONSOLE
log4j.logger.com.orsoft=DEBUG,FILE,CONSOLE
log4j.logger.org.aaa=ERROR
如果这样设置，com.orsoft下的日志，输出级别为DEBUG，输出目的地为CONSOLE和FILE，但是CONSOLE会输出2遍，这是因为2个符合条件的Appender都设置了CONSOLE作为目的地。
***Appender和Layout使用的例子

# 应用于控制台