从源码角度深入分析log4j配置文件使用

log4j在日常开发中经常使用，但有时候对 配置文件应该放到什么位置有疑惑。现在我们通过从代码的角度来看待这个问题，

看完后你也许会恍然大悟哦。

开始吧。

Log4j的组成及架构：

Log4j由三个重要的组成构成：日志记录器(Loggers)，输出端(Appenders)和日志格式化器(Layout)。

1.日志记录器(Loggers)：控制要输出哪些日志记录语句，对日志信息进行级别限制。
2.输出端(Appenders)：指定了日志将打印到控制台还是文件中。

3.日志格式化器(Layout)：控制日志信息的显示格式。

类图结构如下（不要眼花缭乱，我辛辛苦苦一个一个画出来的）：

log4j初始化

从架构上我们可以看出logger的实现是从logManager来具体完成的，因此初始化在logManager的static块中，如下：

 static {
    // By default we use a DefaultRepositorySelector which always returns ‘h‘.
    Hierarchy h = new Hierarchy(new RootLogger(Level.DEBUG));
    repositorySelector = new DefaultRepositorySelector(h);

    /** Search for the properties file log4j.properties in the CLASSPATH.  */
    String override =OptionConverter.getSystemProperty(DEFAULT_INIT_OVERRIDE_KEY,
                               null);

    // if there is no default init override, then get the resource
    // specified by the user or the default config file.
    if(override == null || "false".equalsIgnoreCase(override)) {

      String configurationOptionStr = OptionConverter.getSystemProperty(
                              DEFAULT_CONFIGURATION_KEY,
                              null);

      String configuratorClassName = OptionConverter.getSystemProperty(
                                                   CONFIGURATOR_CLASS_KEY,
                           null);

      URL url = null;

      // if the user has not specified the log4j.configuration
      // property, we search first for the file "log4j.xml" and then
      // "log4j.properties"
      if(configurationOptionStr == null) {
    url = Loader.getResource(DEFAULT_XML_CONFIGURATION_FILE);
    if(url == null) {
      url = Loader.getResource(DEFAULT_CONFIGURATION_FILE);
    }
      } else {
    try {
      url = new URL(configurationOptionStr);
    } catch (MalformedURLException ex) {
      // so, resource is not a URL:
      // attempt to get the resource from the class path
      url = Loader.getResource(configurationOptionStr);
    }
      }

      // If we have a non-null url, then delegate the rest of the
      // configuration to the OptionConverter.selectAndConfigure
      // method.
      if(url != null) {
        LogLog.debug("Using URL ["+url+"] for automatic log4j configuration.");
        try {
            OptionConverter.selectAndConfigure(url, configuratorClassName,
                       LogManager.getLoggerRepository());
        } catch (NoClassDefFoundError e) {
            LogLog.warn("Error during default initialization", e);
        }
      } else {
        LogLog.debug("Could not find resource: ["+configurationOptionStr+"].");
      }
    } else {
        LogLog.debug("Default initialization of overridden by " +
            DEFAULT_INIT_OVERRIDE_KEY + "property.");
    }
  }

让我们深入进去看看是怎么初始化的？

第一步：创建一个默认的RepositorySelector，RepositorySelector在logManager中使用，它的实现类对特定的应用上下文提供了一个LoggerRespository。LoggerRespository的实现类负责追踪应用上下文。ResponsitorySelector提供了一个方法：

public LoggerRepository getLoggerRepository();

LoggerRepository从字面上理解，它是一个Logger的容器，它会创建并缓存Logger实例，从而具有相同名字的Logger实例不会多次创建，以提高性能。它的这种特性有点类似Spring的IOC概念。Log4J支持两种配置文件：properties文件和xml文件。Configurator解析配置文件，并将解析后的信息添加到LoggerRepository中。LogManager最终将LoggerRepository和Configurator整合在一起。

LoggerRepository是一个Logger的容器，它负责创建、缓存Logger实例，同时它也维护了Logger之间的关系，因为在Log4J中，所有Logger都组装成以RootLogger为根的一棵树，树的层次由Logger的Name来决定，其中以’.’分隔。

除了做为一个Logger容器，它还有一个Threshold属性，用于过滤所有在Threshold级别以下的日志。以及其他和Logger操作相关的方法和属性。

public interface LoggerRepository {
public void addHierarchyEventListener(HierarchyEventListener listener);
 boolean isDisabled(int level);
 public void setThreshold(Level level);
 public void setThreshold(String val);
public void emitNoAppenderWarning(Category cat);
 public Level getThreshold();
 public Logger getLogger(String name);
public Logger getLogger(String name, LoggerFactory factory);
 public Logger getRootLogger();
public abstract Logger exists(String name);
public abstract void shutdown();
public Enumeration getCurrentLoggers();
 public abstract void fireAddAppenderEvent(Category logger, Appender appender);
 public abstract void resetConfiguration();
}

Hierarchy类

Hierarchy是Log4J中默认对LoggerRepository的实现类，它用于表达其内部的Logger是以层次结构存储的。在对LoggerRepository接口的实现中，getLogger()方法是其最核心的实现，因而首先从这个方法开始。Hierarchy中用一个Hashtable来存储所有Logger实例，它以CategoryKey作为key，Logger作为value，其中CategoryKey是对Logger中Name字符串的封装，之所以要引入这个类是出于性能考虑，因为它会缓存Name字符串的hash code，这样在查找过程中计算hash code时就可以直接取得而不用每次都计算。

第二步：从classpath路径查找log4j.properties属性配置文件。

1. 判断配置文件有没有重写？

    /** Search for the properties file log4j.properties in the CLASSPATH.  */
    String override =OptionConverter.getSystemProperty(DEFAULT_INIT_OVERRIDE_KEY,null); 
//public static final String DEFAULT_INIT_OVERRIDE_KEY = "log4j.defaultInitOverride";
 publicstatic String getSystemProperty(String key, String def) {
    try {
      return System.getProperty(key, def);
    } catch(Throwable e) { // MS-Java throws com.ms.security.SecurityExceptionEx
      LogLog.debug("Was not allowed to read system property \""+key+"\".");
      return def;
    }
  }

2. override为null或者为false时没有重写，然后从系统属性中查找key：log4j.configuration和log4j.configuratorClass属性。如果没有设置log4j.configuration属性，就查找log4j.xml，然后查找log4j.properties文件。使用方法：

     if(configurationOptionStr == null) {
    url = Loader.getResource(DEFAULT_XML_CONFIGURATION_FILE);
    if(url == null) {
      url = Loader.getResource(DEFAULT_CONFIGURATION_FILE);
    }

使用java2的线程上下文类加载器来查找资源，如果查找失败，则使用加载该类(loader)的类加载器来加载资源。

3.如果设置了log4j.configuration属性，则使用url形式读取，如果资源不是url，则从classpath获取资源：

    try {
      url = new URL(configurationOptionStr);
    } catch (MalformedURLException ex) {
      // so, resource is not a URL:
      // attempt to get the resource from the class path
      url = Loader.getResource(configurationOptionStr);
    }

4. 如果log4j.configuration属性为url形式：

      // If we have a non-null url, then delegate the rest of the
      // configuration to the OptionConverter.selectAndConfigure
      // method.
      if(url != null) {
        LogLog.debug("Using URL ["+url+"] for automatic log4j configuration.");
        try {
            OptionConverter.selectAndConfigure(url, configuratorClassName,
                       LogManager.getLoggerRepository());
        } catch (NoClassDefFoundError e) {
            LogLog.warn("Error during default initialization", e);
        }
      } else {
        LogLog.debug("Could not find resource: ["+configurationOptionStr+"].");
      }

小结：

The exact default initialization algorithm is defined as follows:

  1. Setting the log4j.defaultInitOverride system property to any other value then "false" will cause log4j to skip the default initialization procedure (this procedure).
  2. Set the resource string variable to the value of the log4j.configuration system property. The preferred way to specify the default initialization file is through the log4j.configuration system property. In case the system property log4j.configuration is not defined, then set the string variable resourceto its default value "log4j.properties".
  3. Attempt to convert the resource variable to a URL.
  4. If the resource variable cannot be converted to a URL, for example due to a MalformedURLException, then search for the resource from the classpath by calling org.apache.log4j.helpers.Loader.getResource(resource, Logger.class) which returns a URL. Note that the string "log4j.properties" constitutes a malformed URL.

    See Loader.getResource(java.lang.String) for the list of searched locations.
  5. If no URL could not be found, abort default initialization. Otherwise, configure log4j from the URL.

    The PropertyConfigurator will be used to parse the URL to configure log4j unless the URL ends with the ".xml" extension, in which case the DOMConfiguratorwill be used. You can optionaly specify a custom configurator. The value of the log4j.configuratorClass system property is taken as the fully qualified class name of your custom configurator. The custom configurator you specify must implement the Configurator interface.

参考文献：

1. http://www.2cto.com/kf/201207/139798.html

2. http://logging.apache.org/log4j/1.2/manual.html

时间： 2024-08-25 04:24:01

从源码角度深入分析log4j配置文件使用的相关文章

从源码角度深入分析ant

Ant的基本概念 首先是ant的基本概念:Project,Target,Tasks,Properties,Paths 1.Project <project> build.xml文件最顶层的元素,它有三个可选的属性:名称(name):工程的名称默认(default):默认的目标(target).基础目录(basedir):工程的根目录,工程所有的相对路径从此算起. 2. target 每个project定义了0个或者多个target,是project的次级目录. 一个target是一组要执行的t

ThinkPHP源码阅读2-----C函数配置文件详解

ThinkPHP的配置非常灵活,可自定义加载.大概看了一下,一共有这几个地方会加载配置文件,方便以后的读取 /** * 获取和设置配置参数 支持批量定义 * * @param string|array $name * 配置变量 * @param mixed $value * 配置值 * @return mixed */ function C($name = null, $value = null) { static $_config = array (); // 无参数时获取所有 if (emp

从源码角度来修改PreferenceActivity界面

       从源码角度来修改PreferenceActivity界面,布布扣,bubuko.com

从源码角度入手实现RecyclerView的Item点击事件

转载请注明出处:http://www.cnblogs.com/cnwutianhao/p/6758373.html RecyclerView 作为 ListView 和 GridView 的替代产物,相信在Android界已广为流传. RecyclerView 本是不会有类似 ListView 的那种点击事件,但是知道和会用又是两种情况,跟随我一起从源码角度分析,RecyclerView 点击事件. 首先看一下 Google 对 ListView 家族谱的介绍: 可以看出 ListView 归根

从源码角度深入理解Toast

Toast这个东西我们在开发中经常用到,使用也很简单,一行代码就能搞定: 1: Toast.makeText(this, "333", Toast.LENGTH_LONG).show(); 但是我们经常会遇到这样一种情况,比如说我们有两个按钮,每次点击之后就会弹出一个Toast,但是如果这两个按钮快速点击,我们看到的效果是这样的:   但实际上我们想要的效果应该是这样的:   源码解读 看了上面两张效果图的对比之后,我们应该明白了,第一种情况是在我们点击完之后,Toast还在不断的显示

Snackbar新版Toast 从源码角度完全解析

我们将会从一下几个角度了解Snackbar. 1.什么是Snackbar 2.如何使用Snackbar 3.有哪些常用的API 4.从源码角度分析其实现 5.总结 1.什么是Snackbar Snackbar是一个轻量级的用户操作反馈工具,类似于Toast,但是比Toast更美观和实用,当你操作它的时候,Snackbar会置顶显示一个一定时间的简要的信息在屏幕的底部,并且它还可以添加事件. 2.如何使用Snackbar Snackbar .make(parentLayout, R.string.

Android布局性能优化—从源码角度看ViewStub延迟加载技术

在项目中,难免会遇到这种需求,在程序运行时需要动态根据条件来决定显示哪个View或某个布局,最通常的想法就是把需要动态显示的View都先写在布局中,然后把它们的可见性设为View.GONE,最后在代码中通过控制View.VISIABLE动态的更改它的可见性.这样的做法的优点是逻辑简单而且控制起来比较灵活.但是它的缺点就是,耗费资源,虽然把View的初始可见View.GONE但是在Inflate布局的时候View仍然会被Inflate,也就是说仍然会创建对象,会被实例化,会被设置属性.也就是说,会

从源码角度分析linearLayout测量过程以及weight机制

???上文从源码角度分析了view和viewGroup的measure机制,如果还没有阅读的同志们,可以前往从源码角度分析Android View的绘制机制(一)阅读.下面我再结合linearLayout的measure过程解释以下两个问题的缘由. 问题一: <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent

Android进阶：二、从源码角度看透 HandlerThread 和 IntentService

上篇文章我们讲日志的存储策略的时候用到了HandlerThread,它适合处理"多而小的任务"的耗时任务的时候,避免产生太多线程影响性能,那这个HandlerThread的原理到底是怎样的呢?我们现在从源码角度解读 HandlerThread:继承自Thread,是一个可以使用Handler的Thread.因为在run方法内维护了一个Looper,可以通过Handler发送消息的方式,来通知HandlerThread执行一个具体的任务. public void run() { mTid