common-logging源码解析

时间  2019-12-05
标签 common logging 源码 解析 栏目 Log4j 繁體版
原文   原文链接

OK，如今咱们来研究下common-logging的源码。这篇博客有参照上善若水的博客，感谢他的无私分享。java

先来随便扯点吧，貌似全部这些流行的Logging框架都和Log4J多少有点关系（不太肯定Commons Logging有多大关系，不过至少也都是Apache下的项目吧）。JDK Logging听说当初是想用Log4J的，可是当时两家好像谈判谈崩了，而后JDK本身实现了一个，貌似结构和Log4J差很少，只是实现的比较烂，基本上也只能在作测试的时候用，而SLF4J和LogBack都是出自Log4J的创始人Ceki Gülcü之手。这家伙也算是闲的蛋疼，光整Logging这些框架貌似就花了很多时间吧。

web

  • common-logging的包结构

原本我要下载这个包的源码而后在本地跑一下的，结果一看jar包就这么几个类，因此呢？这里也就不直接跑源码和调试源码了。common-logging的包结构以下：apache


OK，言归正传，在Logging系统中，目前框架都是基于相同的设计，即从一个LogFactory中取得一个命名的Log（Logger）实例，而后使用这个Log（Logger）实例打印debug、info、warn、error等不一样级别的日志。做为两个门面日志系统，Commons Logging和SLF4J也一样采用这样的设计。所谓门面日志系统，是指它们自己并不实现具体的日志打印逻辑，它们只是做为一个代理系统，接收应用程序的日志打印请求，而后根据当前环境和配置，选取一个具体的日志实现系统，将真正的打印逻辑交给具体的日志实现系统，从而实现应用程序日志系统的“可插拔”，便可以经过配置或更换jar包来方便的更换底层日志实现系统，而不须要改变任何代码。我的感受SLF4J的实现更加灵活，而且它还提供了Maker和MDC的接口。关于SLF4J的整理我在后面会作具体介绍。设计模式

  • LogFactory获取相对应的Log实现类源码

Commons Logging的设计比较简单，它定义了一个Log接口，全部它支持的日志系统都有相应的Log实现类，如Log4JLogger、Jdk14Logger、Jdk13LumberjackLogger、SimpleLog、NoOpLog、AvalonLogger、LogKitLogger等类，在LogFactory中定义了必定的规则，从而根据当前的环境和配置取得特定的Log子类实例。咱们在实际编码中经过下面代码来获取一个log实例： 

public static Log LOG = LogFactory.getLog(CommonsLoggingTest.class);

这里贴出LogFactory获取相对应的Log实现类的核心代码：数组

LogFactory抽象类：
缓存

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

LogFactoryImpl实现类：服务器

public Log getInstance(Class clazz) throws LogConfigurationException {
        return getInstance(clazz.getName());
    }
public Log getInstance(String name) throws LogConfigurationException {
        Log instance = (Log) instances.get(name);
        if (instance == null) {
            instance = newInstance(name);
            instances.put(name, instance);
        }
        return instance;
    }
protected Log newInstance(String name) throws LogConfigurationException {
        Log instance;
        try {
            if (logConstructor == null) {
                instance = discoverLogImplementation(name);
            }
            else {
                Object params[] = { name };
                instance = (Log) logConstructor.newInstance(params);
            }

            if (logMethod != null) {
                Object params[] = { this };
                logMethod.invoke(instance, params);
            }

            return instance;

        }
关于上面代码解释：

若是在获取具体的实例的时候，common-logging的logConstructor属性不为空，则直接抛下反射初始化该实例就OK，若是该属性为空，那么就要按照顺序去找对应的日志实例。核心代码以下：app

 private Log discoverLogImplementation(String logCategory) throws LogConfigurationException {

//1，初始化配置
initConfiguration();
//2，寻找用户自定义的日志实例
Log result = null;
String specifiedLogClassName = findUserSpecifiedLogClassName();
//3，框架开始工做，按照顺序初始化log实例
if (specifiedLogClassName != null) {
    // 初始化log实例
    result = createLogFromClass(specifiedLogClassName,logCategory,true);
    if (result == null) {
        StringBuffer messageBuffer =  new StringBuffer("User-specified log class '");
        messageBuffer.append(specifiedLogClassName);
        messageBuffer.append("' cannot be found or is not useable.");

        // 顺序链接报错字符串，抛出一个异常
        informUponSimilarName(messageBuffer, specifiedLogClassName, LOGGING_IMPL_LOG4J_LOGGER);
        informUponSimilarName(messageBuffer, specifiedLogClassName, LOGGING_IMPL_JDK14_LOGGER);
        informUponSimilarName(messageBuffer, specifiedLogClassName, LOGGING_IMPL_LUMBERJACK_LOGGER);
        informUponSimilarName(messageBuffer, specifiedLogClassName, LOGGING_IMPL_SIMPLE_LOGGER);
        throw new LogConfigurationException(messageBuffer.toString());
    }

    return result;
 }


  • LogFactory获取相对应的Log实现类逻辑

Commons Logging中默认实现的LogFactory（LogFactoryImpl类）查找具体Log实现类的逻辑以下：


1.    查找在commons-logging.properties文件中是否认存在以org.apache.commons.logging.Log或org.apache.commons.logging.log(旧版本，不建议使用)为key定义的Log实现类，若是是，则使用该类。


2.    不然，查找在系统属性中（-D方式启动参数）是否存在以org.apache.commons.logging.Log或org.apache.commons.logging.log(旧版本，不建议使用)为key定义的Log实现类，若是是，则使用该类。


3.    不然，若是在classpath中存在Log4J的jar包，则使用Log4JLogger类。


4.    不然，若是当前使用的JDK版本或等于1.4，则使用Jdk14Logger类。


5.    不然，若是存在Lumberjack版本的Logging系统，则使用Jdk13LumberjackLogger类。


6.    不然，若是能够正常初始化Commons Logging自身实现的SimpleLog实例，则使用该类


7.    最后，以上步骤都失败，则抛出LogConfigurationException。

  • Commons Logging还支持用户自定义的LogFactory实现类


其实，Commons Logging还支持用户自定义的LogFactory实现类。对LogFactory类的查找逻辑为：


1.    查看系统属性中是否存在以org.apache.commons.logging.LogFactory为key的LogFactory实现类，如有，则使用该类实例化一个LogFactory实例。


2.    不然，尝试使用service provider的方式查找LogFactory实现类，即查看classpath或jar包中是否存在META-INF/services/org.apache.commons.logging.LogFactory文件，若是存在，则使用该文件内定义的LogFactory类实例化一个LogFactory实例。


3.    不然，查找commons-logging.properties文件是否存在，而且其中存在以org.apache.commons.logging.LogFactory为key的LogFactory实现类，如有，则使用该类实例化一个LogFactory实例。


4.    不然，使用默认的LogFactoryImpl实现类实例化一个LogFactory实例。


Commons Logging的类设计图以下：




在使用Commons Logging时，常常在服务器部署中会遇到ClassLoader的问题，这也是常常被不少人所诟病的地方，特别是在和Log4J一块儿使用的时候。常见的如，因为Common Logging使用很是普遍，于是不少Web容器（WebSphere）在内也会使用它做为日志处理系统而将其jar包引入到容器自己中，此时LogFactory是使用Web容器自己的ClassLoader装载的，即便Log4J中使用了ContextClassLoader来查找配置文件，此时的Thread依然在容器中，于是它使用的ClassLoader仍是容器自己的ClassLoader实例，此时须要把Log4J的配置文件放到共享目录下，该配置文件才能被正常识别。在WebSphere还能够经过设置类的加载顺序为PARENT_LAST的方法来解决。而在Jboss中则只能将本身的配置加到其conf下的Log4J配置文件中，由于Jboss默认导入Log4J包。

  • Commons Logging的具体实现：



在使用Commons Logging时，通常是经过LogFactory获取Log实例，而后调用Log接口中相应的方法。于是Commons Logging的实现能够分红如下几个步骤：

  • LogFactory类初始化

a.    缓存加载LogFactory的ClassLoader（thisClassLoader字段），出于性能考虑。由于getClassLoader()方法可能会使用AccessController（虽然目前并无使用），于是缓存起来以提高性能。

b.    初始化诊断流。读取系统属性org.apache.commons.logging.diagnostics.dest，若该属性的值为STDOUT、STDERR、文件名。则初始化诊断流字段（diagnosticStream），并初始化诊断消息的前缀（diagnosticPrefix），其格式为：”[LogFactory from <ClassLoaderName@HashCode>] “, 该前缀用于处理在同一个应用程序中可能会有多个ClassLoader加载LogFactory实例的问题。

c.    若是配置了诊断流，则打印当前环境信息：java.ext.dir、java.class.path、ClassLoader以及ClassLoader层级关系信息。

d.    初始化factories实例（Hashtable），用于缓存LogFactory（context-classloader –-> LogFactory instance）。若是系统属性org.apache.commons.logging.LogFactory.HashtableImpl存在，则使用该属性定义的Class做为factories Hashtable的实现类，不然，使用Common Logging实现的WeakHashtable。若初始化没有成功，则使用Hashtable类自己。使用WeakHashtable是为了处理在webapp中，当webapp被卸载是引发的内存泄露问题，即当webapp被卸载时，其ClassLoader的引用还存在，该ClassLoader不会被回收而引发内存泄露。于是当不支持WeakHashtable时，须要卸载webapp时，调用LogFactory.relase()方法。

e.    最后，若是须要打印诊断信息，则打印“BOOTSTRAP COMPLETED”信息

  • 查找LogFactory类实现，并实例化

当调用LogFactory.getLog()方法时，它首先会建立LogFactory实例(getFactory())，而后建立相应的Log实例。getFactory()方法不支持线程同步，于是多个线程可能会建立多个相同的LogFactory实例，因为建立多个LogFactory实例对系统并无影响，于是能够不用实现同步机制。

a.    获取context-classloader实例。

b.    从factories Hashtable（缓存）中获取LogFactory实例。

c.    读取commons-logging.properties配置文件（若是存在的话，若是存在多个，则能够定义priority属性值，取全部commons-logging.properties文件中priority数值最大的文件），若是设置use_tccl属性为false，则在类的加载过程当中使用初始化cache的thisClassLoader字段，而不用context ClassLoader。

d.    查找系统属性中是否存在org.apache.commons.logging.LogFactory值，如有，则使用该值做为LogFactory的实现类，并实例化该LogFactory实例。

e.    使用service provider方法查找LogFactory的实现类，并实例化。对应Service ID是：META-INF/services/org.apache.commons.logging.LogFactory

f.     查找commons-logging.properties文件中是否认义了LogFactory的实现类：org.apache.commons.logging.LogFactory，是则用该类实例化一个出LogFactory

g.    不然，使用默认的LogFactory实现：LogFactoryImpl类。

h.    缓存新建立的LogFactory实例，并将commons-logging.properties配置文件中全部的键值对加到LogFactory的属性集合中。

  • 经过LogFactory实例查找Log实例（LogFactoryImpl实现）

使用LogFactory实例调用getInstance()方法取得Log实例。

a.    若是缓存（instances字段，Hashtable）存在，则使用缓存中的值。

b.    查找用户自定义的Log实例，即从先从commons-logging.properties配置文件中配置的org.apache.commons.logging.Log（org.apache.commons.logging.log，旧版本）类，若不存在，查找系统属性中配置的org.apache.commons.logging.Log（org.apache.commons.logging.log，旧版本）类。若是找到，实例化Log实例

c.    遍历classesToDiscover数组，尝试建立该数组中定义的Log实例，并缓存Log类的Constructor实例，在下次建立Log实例是就不须要从新计算。在建立Log实例时，若是use_tccl属性设为false，则使用当前ClassLoader（加载当前LogFactory类的ClassLoader），不然尽可能使用Context ClassLoader，通常来讲Context ClassLoader和当前ClassLoader相同或者是当前ClassLoader的下层ClassLoader，然而在不少自定义ClassLoader系统中并无设置正确的Context ClassLoader致使当前ClassLoader成了Context ClassLoader的下层，LogFactoryImpl默认处理这种状况，即便用当前ClassLoader。用户能够经过设置org.apache.commons.logging.Log.allowFlawedContext配置做为这个特性的开关。

d.    若是Log类定义setLogFactory()方法，则调用该方法，将当前LogFactory实例传入。

e.    将新建立的Log实例存入缓存中。

  • 调用Log实例中相应的方法

Log实例中其实就是各个插拔日志的一个门面，关于门面能够去看我设计模式相关的文章。这里就以 Log4JLogger为例，解释下该门面log。

下面先贴Log4JLogger核心源码：框架

public class Log4JLogger implements Log, Serializable {

    /** Serializable version identifier. */
    private static final long serialVersionUID = 5160705895411730424L;


    /** The fully qualified name of the Log4JLogger class. */
    private static final String FQCN = Log4JLogger.class.getName();

    /** Log to this logger */
    private transient volatile Logger logger = null;

    /** Logger name */
    private final String name;

    private static final Priority traceLevel;


    static {
        if (!Priority.class.isAssignableFrom(Level.class)) {
            // nope, this is log4j 1.3, so force an ExceptionInInitializerError
            throw new InstantiationError("Log4J 1.2 not available");
        }

        Priority _traceLevel;
        try {
            _traceLevel = (Priority) Level.class.getDeclaredField("TRACE").get(null);
        } catch(Exception ex) {
            // ok, trace not available
            _traceLevel = Level.DEBUG;
        }
        traceLevel = _traceLevel;
    }

    // ------------------------------------------------------------ Constructor

    public Log4JLogger() {
        name = null;
    }

    /**
     * Base constructor.
     */
    public Log4JLogger(String name) {
        this.name = name;
        this.logger = getLogger();
    }

    /**
     * For use with a log4j factory.
     */
    public Log4JLogger(Logger logger) {
        if (logger == null) {
            throw new IllegalArgumentException(
                "Warning - null logger in constructor; possible log4j misconfiguration.");
        }
        this.name = logger.getName();
        this.logger = logger;
    }

    /**
     * Logs a message with <code>org.apache.log4j.Priority.DEBUG</code>.
     *
     * @param message to log
     * @see org.apache.commons.logging.Log#debug(Object)
     */
    public void debug(Object message) {
        getLogger().log(FQCN, Level.DEBUG, message, null);
    }

    /**
     * Logs a message with <code>org.apache.log4j.Priority.DEBUG</code>.
     *
     * @param message to log
     * @param t log this cause
     * @see org.apache.commons.logging.Log#debug(Object, Throwable)
     */
    public void debug(Object message, Throwable t) {
        getLogger().log(FQCN, Level.DEBUG, message, t);
    }

    /**
     * Return the native Logger instance we are using.
     */
    public Logger getLogger() {
        Logger result = logger;
        if (result == null) {
            synchronized(this) {
                result = logger;
                if (result == null) {
                    logger = result = Logger.getLogger(name);
                }
            }
        }
        return result;
    }

    /**
     * Check whether the Log4j Logger used is enabled for <code>DEBUG</code> priority.
     */
    public boolean isDebugEnabled() {
        return getLogger().isDebugEnabled();
    }

    
}

关于上面源码的解释：

1，首先封装log4j的logger类做为属性，而后在封装一个name属性，该属性用来初始化logger时候的构造器参数，在初始化log4jLogger类的时候该name传入，而后用该name来初始化logger实例属性。webapp

2，对外提供一套和log4j一致的API，而后方法中调用logger属性相关API方法就OK了。这里没有直接用属性.方法()，而是用了getLogger()，这样子能够防止logger属性是null的状况，代码比较严谨。这点值得咱们学习。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程