现在java世界中，流行了两个日志门面：SLF4j、Commons Logging。真正使用到的日志框架则会有：JDK Log、Log4j、Simple Log、Logback等。之前已经对SLF4j作了个简单的介绍，这里也对Commons-Logging做一个简单的介绍。Commons Logging，也就是原来 的jakarta commons logging ，jakarta项目已加入到apache 基金会了，所以Commons Logging是众所周知。如果有地方使用JCL，也应该知道 说的就是commons logging。

      1、使用说明 ：

           从API上看，与SLF4j使用还是类似的：

import org.apache.commons.logging.Log; 
import org.apache.commons.logging.LogFactory; 

public class CLASS
{
    private Log log = LogFactory.getLog(CLASS.class);
    ...
    ;

       2、日志级别说明：

• fatal - Severe errors that cause premature termination. Expect these to be immediately visible on a status console. See also Internationalization.
• error - Other runtime errors or unexpected conditions. Expect these to be immediately visible on a status console. See also Internationalization.
• warn - Use of deprecated APIs, poor use of API, ‘almost‘ errors, other runtime situations that are undesirable or unexpected, but not necessarily "wrong". Expect these to be immediately visible on a status console. See also Internationalization.
• info - Interesting runtime events (startup/shutdown). Expect these to be immediately visible on a console, so be conservative and keep to a minimum. See also Internationalization.
• debug - detailed information on the flow through the system. Expect these to be written to logs only.
• trace - more detailed information. Expect these to be written to logs only.

        3、日志框架查找过程

        Commons-Logging中提供了两个API：Log、LogFactory。 Log就是基本的Logger，LogFactory则是创建Log实例的Factory。commons-logging是一个日志facade，它运行时会先找到实际的Log实现，而在找Log实现之前，则要先找到LogFactory的实现。

         上面的代码中：LogFactory.getLog(CLASS.class);的执行过程是：     

public static Log getLog(Class clazz) throws LogConfigurationException {
        return getFactory().getInstance(clazz);
}

　　也就是会先使用static方法getFactory()找到LogFactory的实现，然后根据LogFactory实例找到Log实现。

           getFactory（）查找自定义LogFactory的过程：

           1）从系统属性中找到由org.apache.commons.logging.LogFactory定义的LogFactory。如果未找到，则进入2）。

           2）根据JDK中的Service自动发现机制找到META-INF/services/org.apache.commons.logging.LogFactory配置的LogFactory。如果未找到则进入3）。

           3）从classpath下的commons-logging.properties文件中找到org.apache.commons.logging.LogFactory定义的LogFactory。如果未找到则进入4）。

           如果是在前3步找到了LogFactory，则由自定义的LogFactory来获取Log对象。如果是由内置的LogFactory，它在获取Log实例时，遵循下面次序：

           1）在classpath下找到commons-logging.properties。如果未找到该文件，则进入2）。如果找到该文件，则会找一个名为org.apache.commons.logging.Log （老版本的可能是org.apache.commons.logging.log）的属性。如果未找到该属性，则进行2）。

           2）找系统属性中名为org.apache.commons.logging.Log （老版本的可能是org.apache.commons.logging.log）的属性。仍未找到，则进入3）。

           3）如果在classpath下找到了log4j的相关配置，则自动使用log4j的包装类 Log4jLogger。否则进入4）。

           4）如果是运行在JDK 1.4及之上版本，则自动关联JDK 1.4的包装类Jdk14Logger。否则进入5）。

           5）使用Jdk13Logger。如果出错进入6）。

           6）使用默认的simple logger包装：SimpleLogger。

         4、在Web环境中，如果使用了Commons-Logging ,在解部署、重部署war时，会引发内存泄漏，该如何解决？

class ContextManager implements javax.servlet.ServletContextListener {
  public void contextDestroyed(ServletContextEvent sce) {
    ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
    LogFactory.release(contextClassLoader);

    // Optionally, clean up the underlying concrete logging library too. This might
    // require direct calls to methods on library-specific methods. 

    // And optionally call java.beans.Introspector.flushCaches if your app does any
    // bean introspection and your container doesn‘t flush the caches for you on
    // servlet undeploy. Note that this isn‘t a commons-logging problem; it‘s something
    // quite unrelated which can also cause memory leaks on undeploy.
  }
}

Commons Logingg