JCL-OVER-SLF4J Log Bridging Tool Introduction

Original: http://www.cnblogs.com/zcy_soft/p/3566208.html

There are many tools for 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 be tightly dependent on one tool, but there are many other log tools at the same time. If an application uses two components and exactly two components use different logging tools, then the application will have two log outputs.

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.

JCL-OVER-SLF4J Log Bridging Tool Introduction