Apache Commons Logging 是如何决定使用哪个日志实现类的

Apache Commons Logging 像 SLF4J 一样,是个通用日志框架,广泛应用在各个开源组件中。说其通用,是因为它本身只提供了简单的日志输出的实现 (org.apache.commons.logging.impl.SimpleLog和 org.apache.commons.logging.impl.NoOpLog),主要是为你统一使用其他专业日志实现(Log4j、jdk1.4 Logger、aavalon-Logkit)的方式,让你在程序中看不到具体日志实现的代码,以配置方式解藕。

那么 commons-logging 是怎么决定程序执行时该使用哪个具体的日志实现呢?这里 commons-logging 有两个步骤要做:

1. 定位 org.apache.commons.logging.LogFactory 的实现类(这一步是关键)
2. 定位到的 LogFactory 实现类决定使用哪个 org.apache.commons.logging.Log 实现

那现在我们把注意力主要集中在 commons-logging 如何定位 LogFactory 实现类上来。org.apche.commons.logging.LogFactory 是一个抽象类,所以需要一个 LogFactory 具体类。

通常我们用使用 commons-logging 时是在代码中声明:

Log log = LogFactory.getLog(UnmiTestLog.class);

在 getLog() 中是通过 getFactory() 方法获得具体的 LogFactory 实现类,究竟也体现在这个方法中,所以这里非常有必要把这个方法的代码拉出来。下面是 commons-loggin1.0.3 的 LogFactory.getFactory() 代码,在新版代码定位 LogFactory 的逻辑是一样的。

001. public static LogFactory getFactory() throws LogConfigurationException {
002.  
003.      // Identify the class loader we will be using
004.      // 找到应用自身所用的加载器
005.      //在 WAS 5.1 下是 com.ibm.ws.classloader.CompoundClassLoader
006.      ClassLoader contextClassLoader =  
007.          (ClassLoader)AccessController.doPrivileged(
008.              new PrivilegedAction() {
009.                  public Object run() {
010.                      return getContextClassLoader();
011.                  }
012.              });
013.  
014.  
015.      // Return any previously registered factory for this class loader
016.      // 看看是否有缓存的与此类加载器关联的 LogFactory 实例,有则返回
017.      LogFactory factory = getCachedFactory(contextClassLoader);
018.      if (factory != null )
019.          return factory;
020.  
021.  
022.      // Load properties file..
023.      // will be used one way or another in the end.
024.      // 加载应用的 Classpath 下的属性文件 commons-logging.properties
025.      // FACTORY_PROPERTIES 常量值是 commons-logging.properties
026.      // commons-logging 一般在这个文件里指定 LogFactory 的实现类
027.      // 注意,它只是去加载这个属性文件,并不马上用里面配置的 LogFactory 类
028.      Properties props= null ;
029.      try {
030.          InputStream stream = getResourceAsStream(contextClassLoader,
031.                                                   FACTORY_PROPERTIES);
032.  
033.          if (stream != null ) {
034.              props = new Properties();
035.              props.load(stream);
036.              stream.close();
037.          }
038.      } catch (IOException e) {
039.      } catch (SecurityException e) {
040.      }
041.  
042.      /**** 从下面开始就是 commons-logging 按什么顺找到 LogFactory 实现类 ****/
043.  
044.      // First, try the system property
045.      // 1. 查找系统属性 FACTORY_PROPERTY(org.apache.commons.logging.LogFactory)
046.      // 的值所对应的 LogFactory 实现类
047.       
048.      try {
049.          String factoryClass = System.getProperty(FACTORY_PROPERTY);
050.          if (factoryClass != null ) {
051.              factory = newFactory(factoryClass, contextClassLoader);
052.          }
053.      } catch (SecurityException e) {
054.          // ignore
055.      }
056.  
057.  
058.      // Second, try to find a service by using the JDK1.3 jar
059.      // discovery mechanism. This will allow users to plug a logger
060.      // by just placing it in the lib/ directory of the webapp ( or in
061.      // CLASSPATH or equivalent ). This is similar with the second
062.      // step, except that it uses the (standard?) jdk1.3 location in the jar.
063.      // 2. 使用 JDK1.3 jar 的 Service Provider Interface(SPI) 类发现机制
064.      // 从配置文件 SERVICE_ID(META-INF/services/org.apache.commons.logging.LogFactory)
065.      // 的第一行读取 LogFactory 的实现类名
066.      // 这个 META-INF 目录可以是 WebRoot 的 META-INF,也可以是 classpath 下的 META-INF 目录
067.  
068.      if (factory == null ) {
069.          try {
070.              InputStream is = getResourceAsStream(contextClassLoader,
071.                                                   SERVICE_ID);
072.  
073.              if ( is != null ) {
074.                  // This code is needed by EBCDIC and other strange systems.
075.                  // It's a fix for bugs reported in xerces
076.                  BufferedReader rd;
077.                  try {
078.                      rd = new BufferedReader( new InputStreamReader(is, "UTF-8" ));
079.                  } catch (java.io.UnsupportedEncodingException e) {
080.                      rd = new BufferedReader( new InputStreamReader(is));
081.                  }
082.                   
083.                  String factoryClassName = rd.readLine();
084.                  rd.close();
085.                   
086.                  if (factoryClassName != null &&
087.                      ! "" .equals(factoryClassName)) {
088.                       
089.                      factory= newFactory( factoryClassName, contextClassLoader );
090.                  }
091.              }
092.          } catch ( Exception ex ) {
093.              ;
094.          }
095.      }
096.  
097.  
098.      // Third try a properties file.
099.      // If the properties file exists, it'll be read and the properties
100.      // used. IMHO ( costin ) System property and JDK1.3 jar service
101.      // should be enough for detecting the class name. The properties
102.      // should be used to set the attributes ( which may be specific to
103.      // the webapp, even if a default logger is set at JVM level by a
104.      // system property )
105.      // 3. 现在才轮到用前面加载的 commons-logging.properties 文件中的
106.      // FACTORY_PROPERTY(org.apache.commons.logging.LogFactory) 属性指定的 LogFactory 实现类
107.  
108.      if (factory == null   &&  props != null ) {
109.          String factoryClass = props.getProperty(FACTORY_PROPERTY);
110.          if (factoryClass != null ) {
111.              factory = newFactory(factoryClass, contextClassLoader);
112.          }
113.      }
114.  
115.  
116.      // Fourth, try the fallback implementation class
117.      // 4. 前面几步没有找到 LogFactory 的实现类或有异常的话就用默认的实现类
118.      // 即 LogFactory 为我们准备的 FACTORY_DEFAULT(org.apache.commons.logging.impl.LogFactoryImpl)
119.  
120.      if (factory == null ) {
121.          factory = newFactory(FACTORY_DEFAULT, LogFactory. class .getClassLoader());
122.      }
123.       
124.      if (factory != null ) {
125.          /**
126.           * Always cache using context class loader..
127.           * 缓存所用的实现类,以后直接使用缓冲中的 LogFactory 实现类
128.           */
129.          cacheFactory(contextClassLoader, factory);
130.  
131.          if ( props!= null ) {
132.              Enumeration names = props.propertyNames();
133.              while (names.hasMoreElements()) {
134.                  String name = (String) names.nextElement();
135.                  String value = props.getProperty(name);
136.                  factory.setAttribute(name, value);
137.              }
138.          }
139.      }
140.       
141.      return factory;
142. }



在代码中,我已加上注释,有缓存的 LogFactory 实现类,取缓存中的,注意缓存是与当前应用的类加载器关联的。若缓存中没有的话按 1、2、3、4 的顺序来找,现在就来说说查找 LogFactory 的顺序:


1. 从系统属性中查找键为 org.apache.commons.logging.LogFactory 的值作为 LogFactory 的实现类;却通过 System.getProperty("org.apache.commons.logging.LogFactory") 获得

2.  使用 JDK1.3 jar 的 Service Provider Interface(SPI) 类发现机制,从配置文件 META-INF/services/org.apache.commons.logging.LogFactory 的的第一行读取 LogFactory 的实现类名。这个 META-INF/services/org.apache.commons.logging.LogFactory 文件可以是某个 Web 应用的根目录中;也可以在 classpath 下,如某个 Jar 包中,WebRoot/WEB-INF/classes 中等。这里需多加留心下 META-INF/services/org.apache.commons.logging.LogFactory 这个目录层次及文件名。

3.  在 Classpath 下的 commons-logging.properties 文件中的,找到 org.apache.commons.logging.LogFactory 属性值作为 LogFactory 实现类

4. 前面三步未找个 LogFactory 的实现类,或有任何异常的情况下,就用默认的实现类,即 LogFactory 为我们准备的 org.apache.commons.logging.impl.LogFactoryImpl



明白了以上的顺序,可以帮助我们理解和解决一些实际的问题,例如,为什么可以不用 commons-logging.properties 也是使用的 log4j 日志实现,部署在 WAS 下的应用 log4j 怎么就不能输出日志了呢?

一 般,某个具体的 LogFactory 类对应就会使用与其相应的 Logger 实现,如 Log4jFactory.getLog() 得到的是 Log4JLogger 实例,WAS 的 TrLogFactory.getLog() 返回的是 TrLog 实例。

老师们教我们用 commons-logging 时也许会让我们在 classpath 下放一个 commons-logging.properties 文件,并在这个文件中写上一行:

org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.Log4jFactory

Log4jFactory 已不推荐使用,新的建议的用法是 LogFactory 统一用 LogFactoryImpl,然后在 LogFactoryImpl 中决定声明哪个 Log 实现类

或者是这么两行:

org.apache.cmmons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger


然 而我们基本都是用的 Log4j 来输出日志,其实不管 commons-logging.properties 是第一种写法还是第二种写法或许(有时不是) 都是多余的,回望 LogFactory.getFactory() 方法,还要再看看 org.apache.commons.logging.impl.LogFactoryImpl 的 getLogClassName() 方法便可知。

LogFactory.getFactory() 在前面三步找不到 LogFactory 实现类时,就会用默认的 LogFactoryImpl,而默认的 LogFactoryImpl.getLog() 时,又会根据以下四个顺序来决定返回什么 Log 实例(Log 实例对应到实际的日志实现),在 LogFactoryImpl.getLogClassName() 中体现了:

1. commons-logging.properties 中的 org.apache.commons.logging.Log 指定的 Log 实现类
2. Log4j 可用就用 org.apache.commons.logging.impl.Log4JLogger
3. Jdk1.4 Logger 可用就用 org.apcache.commons.logging.impl.Jdk14Logger(JDK1.4 开始自带)
4. SimpleLog 可用就用 org.apache.commons.logging.impl.SimpleLog(commons-logging 自带)

所 以这就是为什么了,使用了 commons-logging 的框架类,只要扔个 log4j 的 jar,根本不用 commons-logging.properties 文件就会用 log4j 来输出日志,当然 log4j 自己的配置文件 log4j.xml 或 log4j.properties 是需要的。

那为什么在 Tomcat 或别的应用服务器中 log4j  能正常输出日志,一放到 WAS 5 下却不灵了呢?原因是在 $WAS_HOME/lib/ws-commons-logging.jar 中有个文件 commons-logging.properties,其中有一行 org.apache.commons.logging.LogFactory=com.ibm.ws.commons.logging.TrLogFactory, 虽然你的应用中可能也有一个 commons-logging.properties,可是很不幸,WAS  自己的 commons-logging.properties 优先了,原因是类加载器的委托机制在作用,所以最终 log4j 没派上用场,被 com.ibm.ws.commons.logging.TrLog 取而代之了,解决办法是要抢在它之前,比系统属性中声明 LogFactory 实现类,或是在 META-INF/services/org.apache.commons.logging.LogFactory 中指名 org.apache.commons.logging.impl.Log4jFactory 或 org.apache.commons.logging.impl.LogFactoryImpl 作为实现类名。

以后在使用 commons-logging 通用日志框架时,若出现什么问应具体情况具体分析,相信都不会变离本篇中能解释的情况。

  • 0
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值