Log4J学习【四】复杂一点的例子二

上面我们演示了一个稍微复杂一点的例子，在那个例子中，我们使用了不同的日志打印级别，并且控制了打印级别，但是上面的例子仍然是对于一个类的日志控制，我们在这个例子中，来看看，控制不同模块的日志打印。

在上面的例子中，我们加入一个新的类，这个类放在一个额外的包中：
package cd.itcast.core;

import org.apache.log4j.Logger;

import cd.itcast.log4j.Configure;

public class LogicProcessor {

    private static Logger log=Logger.getLogger(LogicProcessor.class);

    public void init(Configure conf){

        log.info("init logic processor using conf");

    }

    public void process(){

        log.info("process some logic");

        log.debug("process some detail logic");

    }

}

在这个类中，我们创建了一个模拟某种核心处理器的类，这个类放在了cd.itcast.core包里面，然后在这个类里面使用不同的日志级别打印了一些日志。

然后我们来完成一个测试：
package cd.itcast.log4j;

import org.apache.log4j.BasicConfigurator;

import org.junit.Test;

import cd.itcast.core.LogicProcessor;

public class LogTest3 {

    @Test

    public void testLog(){

        BasicConfigurator.configure();

        Configure conf=new Configure();

        conf.config();

        LogicProcessor processor=new LogicProcessor();

        processor.init(conf);

        processor.process();

    }

}

注意，这个测试我们仍然是放在cd.itcast.log包中的，这个没有任何关系。在这个测试中，我们综合使用到了之前的Configure类和新的LogicProcessor类来完成一些业务逻辑。同样，我们先简单使用BasicConfigurator.configure()完成基础设置。运行测试，输出：
0 [main] INFO cd.itcast.log4j.Configure  - using default db.properties

0 [main] INFO cd.itcast.log4j.Configure  - using config file in classpath:db.properties

15 [main] DEBUG cd.itcast.log4j.Configure  - load properties file success

31 [main] DEBUG cd.itcast.log4j.Configure  - [properties] driverClass : com.mysql.jdbc.Driver

31 [main] DEBUG cd.itcast.log4j.Configure  - [properties] url : jdbc:mysql:///log4j

31 [main] DEBUG cd.itcast.log4j.Configure  - [properties] password : admin

31 [main] DEBUG cd.itcast.log4j.Configure  - [properties] username : log4j

31 [main] INFO cd.itcast.core.LogicProcessor  - init logic processor using conf

31 [main] INFO cd.itcast.core.LogicProcessor  - process some logic

31 [main] DEBUG cd.itcast.core.LogicProcessor  - process some detail logic

    观察输出，两个类里面的所有的日志都输出了，根据上一个例子，我们基本能够猜到，默认情况下，rootLogger的日志级别被设置为了Level.DEBUG。下面，我们来模拟一个场景。假如现在我们已经完成了cd.itcast.log.Configure类的详细测试，我们只想这个类做WARN级别之上的日志输出，但是现在我们还没有确定LogicProcessor是否正常运行，所以对于LogicProcessor类我们要做DEBUG级别的日志。

    怎么控制这个输出？其实我们根据前一个例子解释的Logger的继承的体系结构，我们能有两种方式来完成这个目的。

1，设置rootLogger日志级别为DEBUG；设置cd.itcast.log4j.Configure日志级别为WARN。

2，设置rootLogger日志级别为WARN；设置cd.itcast.core.LogicProcessor日志级别为DEBUG。

    我们随意选择一种模式，比如第二种，那么，修改我们的代码：
import org.junit.Test;

import cd.itcast.core.LogicProcessor;

public class LogTest3 {

    @Test

    public void testLog(){

        BasicConfigurator.configure();

        Logger.getRootLogger().setLevel(Level.WARN);

        Logger.getLogger("cd.itcast.core.LogicProcessor").setLevel(Level.DEBUG);

        Configure conf=new Configure();

        conf.config();

        LogicProcessor processor=new LogicProcessor();

        processor.init(conf);

        processor.process();

    }

}

    再次运行测试，输出：
0 [main] INFO cd.itcast.core.LogicProcessor  - init logic processor using conf

0 [main] INFO cd.itcast.core.LogicProcessor  - process some logic

0 [main] DEBUG cd.itcast.core.LogicProcessor  - process some detail logic

    达到我们的目的。我们回过头来看看我们到底做了些什么。加了两行代码，第一行代码大家应该熟悉了，设置rootLogger的日志级别为WARN，那么在该rootLogger体系结构中的cd.itcast.log.Configure和cd.itcast.core.LogicProcessor默认日志级别都变成了WARN。接着第二行代码，我们使用Logger.getLogger()方法，传入cd.itcast.core.LogicProcessor参数，就得到了和LogicProcessor类绑定的那个Logger实例。注意这里，通过Logger.getLogger(“cd.itcast.core.LogicProcessor”)得到的Logger实例和我们在LogicProcessor类中使用Logger.getLogger(LogicProcessor.class)得到的Logger实例是一个实例。换句话说，在一个rootLogger体系结构中，绑定到同一个名字的Logger实例只会有一份。接着，我们再设置这个Logger的日志记录级别为Level.DEBUG，那么LogicProcessor绑定的Logger实例就不再继承rootLogger的日志记录级别了。所以，能正常打印。

    通过这段代码，我们可以再次看到这个rootLogger的继承体系结构和继承的关系。当然，Log4J远远不止如此。

    假如现在我们在cd.itcast.log包中和cd.itcast.core包中，不止一个类，换句话说，我现在想让cd.itcast.log包及其子包中的类的日志级别为WARN，而让cd.itcast.core包及其子包中的所有类的日志级别为DEBUG，又该怎么做呢？可能这种情况才是我们在现实应用当中会遇到的吧。其实非常简单，我们只需要改一句代码：
@Test

public void testLog(){

    BasicConfigurator.configure();

    Logger.getRootLogger().setLevel(Level.WARN);

    Logger.getLogger("cd.itcast.core").setLevel(Level.DEBUG);

    Configure conf=new Configure();

    conf.config();

    LogicProcessor processor=new LogicProcessor();

    processor.init(conf);

    processor.process();

}

    再次运行测试，输出：
0 [main] INFO cd.itcast.core.LogicProcessor  - init logic processor using conf

0 [main] INFO cd.itcast.core.LogicProcessor  - process some logic

0 [main] DEBUG cd.itcast.core.LogicProcessor  - process some detail logic

    同样达到了目的。

    加粗的代码是不是很不可思议？我们这次不再得到cd.itcast.core.LogicProcessor绑定的Logger，而是得到cd.itcast.core包对应的Logger，是的，就是这样。当我们绑定cd.itcast.core.LogicProcessor对应的Logger的时候，实际上隐式的绑定了cd、cd.itcast、cd.itcast.core这三个Logger。所以，现在的rootLogger体系结构应该是这样：



    那么，当我设置rootLogger的日志级别为WARN，并得到cd.itcast.core绑定的Logger，设置其日志级别为DEBUG的时候，rootLogger、cd、cd.itcast、cd.itcast.log、cd.itcast.log.Configure的日志级别都是WARN，而cd.itcast.core、cd.itcast.core.LogicProcessor的日志级别为DEBUG。

    通过这个示例，我们对Logger的继承体系应该有了更深入一些的了解，也可以通过这个例子可以看出，当我们对不同级别的Logger做特定的配置的时候，会非常灵活的控制我整个系统的日志输出，这是Log4J最为强大的地方之一。

如果你曾经使用过Log4j，你也许会对上面的代码感到非常奇怪，以前不是这样用Log4J的呀，也不要慌，之后就能慢慢看到平时我们使用Log4J的方式和其使用方式后面的真正含义。

下一节，我们会从一个更高的层次来看看Log4J整个框架的体系结构。