Configuration of various classes of log4j

Log4j looks like a simple, easy-to-configure log printing technique. But the actual use of the time found that there are a variety of very similar log technology. Many places in the configuration of a chaotic don't know how to correspond. So we should make a simple classification record of all the log4j.

(a) Java.util.logging.Logger

This is in the Java util package, does not need any Maven dependency, is the most basic log printing. function is very imperfect, basically no one in large software to use this.

Example code: (Log critical level increments from top to bottom)

1  Public classTestlog {2      Public Static voidMain (string[] args) {3Logger Logger = Logger.getlogger (testlog.class. toString ());4Logger.log (Level.all, "all");5Logger.log (Level.finest, "FINEST");6Logger.log (Level.finer, "finer");7Logger.log (Level.fine, "FINE");8Logger.log (Level.config, "CONFIG");9Logger.log (Level.info, "INFO");TenLogger.log (level.warning, "WARNING"); OneLogger.log (Level.severe, "SEVERE"); ALogger.log (Level.off, "OFF"); -     } -}

Console output:

January 17, 2017 2:36:23 pm Com.jd.Test.TestLog main info: Info January 17, 2017 2:36:23 pm com.jd.Test.TestLog main warning: Warning January 17, 20 17 2:36:23 pm Com.jd.Test.TestLog main grave: Severe January 17, 2017 2:36:23 pm Com.jd.Test.TestLog Main
Disabled: Off

So why did you start outputting it from info? The reason is that in many practical applications only the log information above a certain level is printed on the console. Otherwise, when debugging, you may face a huge amount of messy logs and do not know how to start. So the design is also used here.

To modify the default log output level, go to the JRE installation directory under Lib:

12 java.util.logging.ConsoleHandler.level = INFO

So, how do you make a log output directory? This can be specified in Java code:

1  Public classTestlog {2      Public Static voidMain (string[] args)throwsSecurityException, IOException {3Logger Logger = Logger.getlogger (testlog.class. toString ());4         5Filehandler Filehandler =NewFilehandler ("/users/davie/file/foo.log");6 Filehandler.setlevel (level.all);7 Logger.addhandler (filehandler);8         9Logger.log (Level.all, "all");TenLogger.log (Level.finest, "FINEST"); OneLogger.log (Level.finer, "finer"); ALogger.log (Level.fine, "FINE"); -Logger.log (Level.config, "CONFIG"); -Logger.log (Level.info, "INFO"); theLogger.log (level.warning, "WARNING"); -Logger.log (Level.severe, "SEVERE"); -Logger.log (Level.off, "OFF"); -     } +}

But the result is an XML that is more difficult to debug.

(ii) common-logging

First of all, it is a common log interface provided by Apache, it is the meaning of the existence of the common sense of the log and the real log implementation of the decoupling. So what does it need to configure itself? In fact, nothing is needed. Because at run time, it will automatically find the implementation. The implementation here may be the most basic log implementation of the JDK Java.util.logging.Logger, or it may be a wide range of log4j.

First, join the dependency on Maven:

1 <Dependency>2     <groupId>Commons-logging</groupId>3     <Artifactid>Commons-logging</Artifactid>4     <version>1.1.1</version>5 </Dependency>

Then write in the Java class:

1 classFoo {2 3     PrivateLog log = Logfactory.getlog (Testlog.class);4 5      Public voidmethod () {6         //log.debug ("Debug");7Log.info ("Info");8Log.warn ("Warn");9Log.error ("Error");Ten         //log.fatal ("fatal"); One     } A}

These two lines of comments do not work if the comments are removed. The reason is that common-logging is currently only added to Maven, it uses the JDK implementation, and the JDK implementation is not debug or fatal. So the question is, which log does the common-logging use? It will look for its implementation class according to the following rules (reprinted from: http://jiangzhengjun.iteye.com/blog/520733):

1)   First look for your own configuration file under Classpath commons-logging.properties, if found, use the log implementation class defined therein;

2)   If the commons-logging.properties file is not found, locate the Log implementation class that uses its definition when looking for a system environment variable ORG.APACHE.COMMONS.LOGGING.LOG that is defined;


give him the value  : - dorg.apache.commons.logging.log =  org.apache.commons.logging.impl.simplelog - dorg.apache.commons.logging.simplelog.defaultlog  = warn 

3)   otherwise, See if there are log4j packages in classpath, and if found, automatically use log4j as the log implementation class;

4)   Otherwise, use the JDK's own log implementation class (JDK1.4 will have the log implementation class later);

5)   otherwise, Use commons-logging to provide a simple log implementation class Simplelog;

In this way, it is often possible to ensure that log is implemented in accordance with the user's wishes.

In addition, the above Maven dependency if added log4j related dependencies, but will run the times wrong, because Common-logging found log4j, so will use log4j to output, but this time log4j has not been configured to then output:

Log4j:warn No Appenders could is found for logger (com.jd.logTest.Foo).

Log4j:warn Initialize the log4j system properly.

Log4j:warn See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

(c) slf4j

This is actually an interface. It does not implement any real log printing itself, but instead transforms it by introducing another package. Its most special benefits are two, the first is that the log can be printed through placeholders, and the second is a simple and decoupled configuration implementation.

For the 1th, in the use of the log system, it is often not just to print out: "* * exception", but also to print out the specific exceptions, and the parameters of the environment when the exception occurred. The simplest examples are as follows:

1      Public void say (String word) {2         if NULL {3             log.error ("Input parameter exception, Word:" + word); 4             return  ; 5         }6        System.out.println (word); 7     }

The problem is that multiple string objects are produced when the parameters to be printed are long. The second is that the code is not intuitive.

For the 2nd, if the interface is not used, the log4j is directly coupled. So if you introduce a module in your code and this module uses a different log system, then you have to introduce that log system into your code and configure it to be well maintained. It is obvious that unnecessary work has been introduced.

So how do you want to use a slf4j? There is a picture on the official website:

This diagram embodies the core idea of slf4j: You only need to bring the right package into your project, and the log system will work as expected.

So how do you use SLF4J? First, you need a basic SLF4J API package:

1 <Dependency>2     <groupId>Org.slf4j</groupId>3     <Artifactid>Slf4j-api</Artifactid>4     <version>${slf4j.version}</version>5 </Dependency>

This package provides a basic API for SLF4J. Next, you need a "converted package". Speaking of conversion, of course, you can associate the adapter design pattern. This place can be understood as an adapter. The understanding of this place refers to the macroscopic understanding: if you introduce the corresponding package as shown, the SLF4J corresponding implementation package is introduced, and SLF4J will automatically find the implementation of the package.

(d) log4j

This can be said to be the most famous of a log system. Make a lot of beginners confused, because 100 degrees of the implementation of the log system, all over the use of a variety of interfaces above the decoupling. This is a common practice in engineering, but at first it does seem messy.

--------------to Be Continued-----------------

Configuration of various classes of log4j