Log management in Java

Logs are an integral part of running an application, and there are many proven scenarios in Java, although logging is an essential feature of application development and does not include logging-related APIs and implementations in the initial version of the JDK. Related APIs (java.util.logging package, JUL) and implementation until JDK 1.4 is added. So in this area of logging, the community has contributed a lot of open source implementations. Among them the more popular include log4j and its successor Logback. In addition to the true logging implementation, there is a class of encapsulation APIs related to logging, such as Apache Commons Logging and slf4j. The role of this type of library is to provide an encapsulated API hierarchy based on the logging implementation, providing a unified interface to the users of the logging API, allowing for the freedom to switch between different log records implementations. For example, the default logging from the JDK enables JUL to switch to log4j. This type of encapsulation API library is commonly used in framework implementations because of the need to take into account the different needs of the framework's users. There is less use in actual project development, as very few projects switch different logging implementations in development.

implementation of the log

Java has java.util.logging, log4j, logback,log4j2 and other log implementations. Among them Logback is log4j author think log4j already too rotten don't want to change again, re-write an implementation. Log4j originally Unified Lake Good, later was said method on too many synchronous modifier, in high concurrency performance is too bad. Netflix's blitz4j has re-implemented a log4j project, removing a lot of sync modifiers, but its owner says the new project is still recommended for direct use of logback. However, later the Apache community felt slf4j and Logback are log4j author of the qos.ch company's products, log is a very important thing, should not be manipulated in the hands of a company. So the pure community driven to engage in log4j2, reference to Logback, also made some of their own changes.

slf4j

http://www.slf4j.org/manual.html
SLF4J, the simple log façade (easy Logging facade for Java), is not a specific log solution, it provides a simple, unified interface for a variety of log implementations, enabling end users to configure their own
The realization of the hope. SLF4J is just a log shell that requires you to join Slf4j-jdk14.jar, Slf4j-log4j12.jar, or Logback.jar to forward log calls to the actual log frame. There is a jar in the Classpath, SLF4J will choose which implementation. If there are multiple jar packages at the same time as the error. For example: Select the JDK with the log system, you only need to put Slf4j-api-xxx.jar and Slf4j-jdk14-xxx.jar into the classpath, if you can not tolerate the JDK's own log system, want to change to log4j day
Only need to replace Slf4j-jdk14-xxx.jar with Slf4j-log4j12-xxx.jar (and log4j jar and config file, of course).
Replace the default common-logging
Some third-party toolkits have been used directly by log4j, common-logging or java.util.logging. If we finally decide to use log4j to do the final output, we need to put a jcl-over-slf4j.jar and Jul-to-slf4j.jar to replace the common-logging or Java.util.logging API and forward the log request to SLF4J,SLF4J again sent to log4j, at this time also need to ensure that classpath there is no common-logging.jar. and the original direct use of log4j do not need to make any changes.
Use SLF4J to replace common-logging in MAVEN (e.g. default spring relies on common-logging)

<Dependencies>    <Dependency>        <groupId>Org.springframework</groupId>        <Artifactid>Spring-context</Artifactid>        <version>4.1.3.RELEASE</version>    </Dependency></Dependencies>

You can exclude common-logging and use JCL-OVER-SLF4J to replace the binding relationship.

<!--slf4j -      <Dependency>          <groupId>Org.slf4j</groupId>          <Artifactid>Slf4j-api</Artifactid>          <version>${slf4j.version}</version>      </Dependency>      <Dependency>          <groupId>Org.slf4j</groupId>          <Artifactid>Jcl-over-slf4j</Artifactid>          <version>${slf4j.version}</version>      </Dependency>      <!--Spring -      <Dependency>          <groupId>Org.springframework</groupId>          <Artifactid>Spring-context</Artifactid>          <version>${spring.version}</version>          <Exclusions>              <exclusion>                  <Artifactid>Commons-logging</Artifactid>                  <groupId>Commons-logging</groupId>              </exclusion>          </Exclusions>      </Dependency>

If slf4j cannot find the corresponding binding, it will prompt the following error

slf4j:failed to load Class "Org.slf4j.impl.StaticLoggerBinder". Slf4j:defaulting to No-operation (NOP) Logger Implementationslf4j:see http://www.slf4j.org/codes.html# Staticloggerbinder for further details.

Binding Relationship Table

As mentioned previously, SLF4J supports various logging frameworks. The SLF4J distribution ships with several jar files referred to as "SLF4J bindings" with each binding corresponding to a Supported framework.

Slf4j-log4j12-1.7.9.jar

Binding for log4j version 1.2, a widely used logging framework. You also need- Log4j.jar on your class path.

Slf4j-jdk14-1.7.9.jar

Binding for Java.util.logging, also referred to as JDK 1.4 logging

Slf4j-nop-1.7.9.jar

Binding for NOP, silently discarding all logging.

Slf4j-simple-1.7.9.jar

Binding for simple implementation, which outputs all events to System.err. Only messages of level INFO and higher is printed. This binding is useful in the context of small applications.

Slf4j-jcl-1.7.9.jar

Binding for Jakarta Commons Logging. This binding would delegate all slf4j logging to JCL.

Logback-classic-1.0.13.jar (Requires Logback-core-1.0.13.jar)

Native Implementation There is also SLF4J bindings external to the SLF4J project, e.g. Logback which implements SLF 4J natively. Logback ' s ch.qos.logback.classic.Logger class is a direct implementation of SLF4J ' s org.slf4j.Logger interface. Thus, using SLF4J in conjunction with logback involves strictly zero memory and computational overhead.

Log4j

Logback

Logback is a native realization of slf4j

Log4j2
Logstash

Refer:
Java Log Management best Practices
http://www.ibm.com/developerworks/cn/java/j-lo-practicelog/

Log management in Java