Go: Introduction to Java Log components (Common-logging,log4j,slf4j,logback)

Original website: http://www.blogjava.net/daiyongzhi/archive/2014/04/13/412364.html

Common-logging

common-logging is a common log interface provided by Apache. The user is free to choose the third party's log component as a concrete implementation, like log4j, or the logging that comes with the JDK, common-logging will automatically find the log library that is actually used when the program runs by dynamic lookup mechanism. Of course, there is a simple logger implementation of common-logging inside, but the function is very weak. So using common-logging is usually used in conjunction with log4j. The advantage of using it is that the code dependency is common-logging rather than log4j, avoids direct coupling to the specific log scheme, and, if necessary, can change the third-party library of the log implementation.

Common code for using common-logging:
[Java]View Plaincopy

1. Import Org.apache.commons.logging.Log;
2. Import Org.apache.commons.logging.LogFactory;
4. public class A {
5. private static Log logger = Logfactory.getlog (This.getclass ());
6. }

Dynamic Find principle: Log is an interface declaration. The inside of the logfactory will load the specific log system and obtain the implementation class that implements the log interface. The process of logfactory internal loading log system is as follows:

1. First, look for the Org.apache.commons.logging.LogFactory property configuration.
2. Otherwise, using the service discovery mechanism provided by JDK1.3, the Meta-inf/services/org.apache.commons.logging.logfactory file under Classpah is scanned, and if found, the configuration inside is loaded, using the configuration inside.
3. Otherwise, look for commons-logging.properties from Classpath and find it to load according to the configuration inside.
4. Otherwise, use the default configuration: If you can find log4j, the default is to use the log4j implementation, and if not, use the Jdk14logger implementation, and then use the Simplelog implementation provided internally by Commons-logging.

From the above loading process, as long as the introduction of log4j and Classpath configuration log4j.xml, then commons-logging will make log4j use Normal, and the code does not need to rely on any log4j code.

Slf4j

slf4j is all called simple Logging facade for Java,java simply log façade. Similar to Apache Common-logging, is a façade package for different log frameworks that can be accessed with a log implementation without modifying any configuration at deployment time. However, he statically binds the real log library at compile time. When using SLF4J, if you need to use one of the log implementations, then you must select the correct set of SLF4J jar packages (various bridging packages).

Common code for using SLF4J:

[Java]View Plaincopy

1. Import Org.slf4j.Logger;
2. Import Org.slf4j.LoggerFactory;
4. public class A {
5. private static Log logger = Logfactory.getlog (This.getclass ());
6. }

slf4j Static binding principle : SLF4J will bind the import org.slf4j.impl.StaticLoggerBinder at compile time; This class implements the binding access to the specific log scheme. Any kind of implementation based on SLF4J should have this class. such as: org.slf4j.slf4j-log4j12-1.5.6: Provides an adaptation to the log4j implementation. Note: If there are any two packages that implement SLF4J at the same time, the problem may occur.

Comparison between SLF4J and common-logging common-loggingThe dynamic lookup mechanism automatically finds the log library that is actually used when the program runs. Because it uses ClassLoader to find and load the underlying log library, a framework like OSGi does not work properly because OSGi's different plugins use their own classloader. This mechanism of OSGI ensures that plug-ins are independent of each other, but it makes Apache common-logging unable to work.
slf4jThe real log library is statically bound at compile time, so it can be used in OSGi. In addition, SLF4J supports parameterized log strings, avoiding the need to write the IF (logger.isdebugenable ()) that was previously written to reduce the performance loss of string concatenation, and now you can write directly: Logger.debug ("Current user is: {} ", user). The assembly message was postponed until it was able to determine whether to display the message, but the cost of acquiring the parameter was not spared.
Log4japache an open source project, through the use of log4j, we can control the destination of log information delivery is the console, files, GUI components, even the socket server, NT Event recorder, UNIX syslog daemon, etc. The user can also control the output format of each log, and by defining the level of each log information, the user can control the log generation process more carefully. These can be configured flexibly with a single configuration file without the need to modify the program code.

Logbacklogback is another open source journaling component designed by the founder of Log4j. The Logback is currently divided into three modules: Logback-core,logback-classic and logback-access. The Logback-core is the base module for the other two modules. Logback-classic is an improved version of log4j. In addition logback-classic full implementation of the SLF4J API allows you to easily change to other journaling systems such as log4j or JDK14 Logging. The Logback-access Access module integrates with the servlet container to provide the ability to access journaling over HTTP.

Log4j and Logback compare Logback as a general reliable, fast and flexible log framework that will act as an alternative to log4j and slf4j a complete implementation of the new log system. Logback claims to have excellent performance, "some key operations, such as determining whether to record a log statement operation, its performance has been significantly improved." This operation requires 3 nanoseconds in Logback and 30 nanoseconds in log4j. The logback creates a logger (logger) faster: 13 microseconds, while in log4j it takes 23 microseconds. What's more, it takes only 94 nanoseconds to get the existing logger, and the log4j takes 2234 nanoseconds and the time is reduced to 1/23. Performance improvements compared to Jul are also significant. "  In addition, all logback documents are provided free of charge, unlike log4j, which only provides some free documentation and requires users to purchase paid documents. SLF4J bridging with various other log components application code using the SLF4J interface, access to the specific implementation of the method

use other log interfaces in your application code to turn into SLF4J methods

Log component related history there are many tools to implement logging in the Java World, the first widely used is log4j, and the log parts of many applications are given to log4j, but as component developers, they want their components to not rely on a single tool, After all, there are a lot of other log tools at the same time, and if an application uses two components and exactly two components use different logging tools, then the application will have two log output.

In order to solve this problem, Apache Commons Logging (previously called Jakarta Commons LOGGING,JCL), the JCL only provides log interface, the implementation is dynamically looking at runtime. As a result, the component developer only needs to develop for the JCL interface, while the calling component's application can be run with its own favorite log practice tool.

So even now you will still see a lot of program application JCL + log4j this collocation, but when the size of the program is becoming larger and bigger, the JCL dynamic binding is not always successful, specific reasons we can Google a bit, here will not repeat. One of the workarounds is to statically bind the specified log tool when the program is deployed, which is why slf4j occurs.

Like JCL, SLF4J is only provided with the log interface, the implementation of the application is packaged in the binder (named Slf4j-xxx-version.jar) to decide, XXX can be log4j12, jdk14, JCL, NOP, etc., they realized the The binding and proxy work of the Body log tool (such as log4j). For example: If a program wants to use the LOG4J log tool, then the program only needs to be programmed for the Slf4j-api interface and then put in Slf4j-log4j12-version.jar and Log4j.jar when it is packaged.

Now there is a problem, if you are using the JCL in the component that you are developing the application, and some of the builds may call java.util.logging directly, then you need a bridge (named Xxx-over-slf4j.jar) redirect their log output to slf4j, the so-called bridge is a fake log implementation tool, such as when you put Jcl-over-slf4j.jar to Class_path, even if a component was originally through the JCL Output log, but now will be jcl-over-slf4j "cheat" slf4j, and then SLF4J will be based on the binding to the log to the specific log implementation tool. The process is as follows

Component
|
| Log to Apache Commons Logging
V
Jcl-over-slf4j.jar---(redirect)---> slf4j---> Slf4j-log4j12-version.jar---> Log4j.jar---> Output log

Seeing the flowchart above may find an interesting question, what happens if you place Log4j-over-slf4j.jar and Slf4j-log4j12-version.jar in Class_path? Yes, the logs will be kicked and kicked, eventually going into the dead loop.

So the typical collocation of using slf4j is to place the 5 jars of the Slf4j-api, JCL Bridge, Java.util.logging (JUL) bridge, log4j Binder, and log4j in Class_path.

However, not all app containers are used log4j, such as Google AppEngine it uses java.util.logging (JUL), then the application slf4j with the Slf4j-api, JCL Bridge, Logj4 Bridge Connector, The 4 jars of the Jul binder are placed in the web-inf/lib.

Go: Introduction to Java Log components (Common-logging,log4j,slf4j,logback)