Several practical application modes of SLF4J three: slf4j+jcl-over-slf4j

Reprint: http://zyjustin9.iteye.com/blog/2028941

We've already talked about the two usages of slf4j: slf4j+log4j and Slf4j+logback, which is the ideal time for the components used to use only the SLF4J Unified log Framework. But JCL has been far-reaching, slf4j is getting better, the components that are likely to be used in your project, they use JCL and slf4j two kinds of components respectively. For example, in the project with Hibernate 3.5 and Struts, or some other Apache open source components, you do not want to use the SLF4J component log information output to a, with the JCL component log output to B, then you write your own code in the log information where to write? ？

Chinese people have always been willing to pursue unification, do not like the city-state system of easy to divide and conquer. But when it comes to the log output is unified into a single channel, on the one hand, multiple channels waste resources, but also easy to configure and manage. Then since SLF4J is a trend, when slf4j and JCL is thrown into a jar, first will let SLF4J-based, JCL supplemented, that is, to the JCL Bridge to slf4j up, through the SLF4J unified output log information. So that is the SLF4J usage pattern to be introduced in this article: JCL-OVER-SLF4J+SLF4J.

The former face slf4j know, even if the JCL passed to slf4j, or can not output the log, but also need a log implementation, the lower layer with log4j also have to use log4j, want to use Logback or Logback. So after the slf4j still have to go down, that is, the two roads in front slf4j+log4j and slf4j+logback, this article uses the SLF4J model specifically will be divided into:

jcl-over-slf4j+slf4j+log4j and jcl-over-slf4j+slf4j+logback, these two implementations are similar. Just separate jar package and configuration file, slf4j+log4j and Slf4j+logback originally want to which files now still need those files, just add Jcl-over-slf4j-1.5.11.jar package. Here is a description of the way jcl-over-slf4j+slf4j+logback .

Required configuration files and component packages, the following four jar files and an XML file are to be placed on the project's ClassPath.

1. Slf4j-api-1.5.11.jar
2. Logback-core-0.9.20.jar
3. Logback-classic-0.9.20.jar
4. Logback.xml or Logback-test.xml
5. Jcl-over-slf4j-1.5.11.jar

The 1th and 5th packages are downloaded at http://www.slf4j.org/download.html, the second third package is downloaded in http://logback.qos.ch/download.html, and there may be some differences in the version number in the package file name.

The following is the simplest Logback.xml file content

XML Code

2. <? XML version= "1.0" encoding="UTF-8"?>
4. <configuration>
6. <appender name="stdout" class="Ch.qos.logback.core.ConsoleAppender">
8. <encoder charset="GBK">
10. <pattern>[consociate]%d{hh:mm:ss. SSS} [%thread]%-5level%logger{36}-%msg%n</pattern>
12. </encoder>
14. </appender>
18. <root level="DEBUG">
20. <appender-ref ref="stdout" />
22. </root>
24. </configuration>

To see the effect, we added [consociate] to the input pattern to verify that it was unified into a single log channel.

Code that uses JCL and SLF4J

Java Code

2. Package Com.unmi;
6. Import Org.apache.commons.logging.Log;
8. Import Org.apache.commons.logging.LogFactory;
10. Import Org.slf4j.Logger;
12. Import Org.slf4j.LoggerFactory;
16. Public class Testjcloverslf4j {
18. //slf4j's Logger
20. private static final Logger Logger = Loggerfactory.getlogger ("from slf4j");
24. //JCL's Log
26. private static final log log = Logfactory.getlog ("from JCL");
30. //using the above logger and log output logs, from the output you can see that they are unified into one channel.
32. public static void Main (string[] args) {
34. Logger.info ("Hello {}","from slf4j");
36. Log.info ("Hello from JCL");
38. }
40. }

In the above code, we used both the JCL Unified logging framework and the SLF4J Unified logging framework. Note that the log from the JCL bridge cannot output a parameterized message. The code above uses Org.apache.commons.logging.log,import org.apache.commons.logging.LogFactory, but you don't have to introduce a Commons-logging.jar package.

Execute the above code and see the output:

This article original link http://unmi.cc/jcl-over-slf4j-slf4j/, from Yehuang Unmi Blog

[Consociate] 23:19:39.890 [main] INFO from Slf4j-hello to slf4j
[Consociate] 23:19:39.921 [main] INFO from Jcl-hello to JCL

It is clear that the log output of the JCL framework and the SLF4J framework is unified into one channel, why? slf4j use of Logback output information, this is not a problem, and JCL is not aware of logback, so the output of the JCL framework must be a detour to slf4j, and finally by the logback output.

Implementation analysis:

We opened the Jcl-over-slf4j-1.5.11.jar and saw that there were two bags of org.apache.commons.logging and Org.apache.commons.logging.impl, and there are corresponding classes, which is why, although in code there are:

Import Org.apache.commons.logging.Log;
Import Org.apache.commons.logging.LogFactory;

There is no reason to introduce the Commons-logging.jar package to the classpath.

Further down the Jcl-over-slf4j-1.5.11.jar, see there is a file/meta-inf/services/org.apache.commons.logging.logfactory, the content is:

Org.apache.commons.logging.impl.SLF4JLogFactory

# Axis gets at JCL through it own mechanism as defined by Commons Discovery, which
# in turn follows the instructions found at:
# Http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service Provider

The JCL runtime uses slf4jlogfactory, thus completing the JCL log implementation entrusted to the SLF4J, and then by slf4j further completion of the specific log output.

The use of jcl-over-slf4j+slf4j+log4j is similar and is not detailed here. The conclusion is that JCL treats slf4j as its log implementation.

Imagine a question: what if we put both of these packages Jcl-over-slf4j-1.5.11.jar and Slf4j-jcl-1.5.11.jar in ClassPath? JCL Proxy to slf4j,slf4j and bound to JCL, yes, dead loop, StackOverflow error:

slf4j:detected both Jcl-over-slf4j.jar and Slf4j-jcl.jar on the class path, preempting stackoverflowerror.
Slf4j:see also http://www.slf4j.org/codes.html#jclDelegationLoop for more details.
Java.lang.ExceptionInInitializerError
At org.slf4j.impl.staticloggerbinder.<init> (staticloggerbinder.java:82)
At org.slf4j.impl.staticloggerbinder.<clinit> (staticloggerbinder.java:51)
At Org.slf4j.LoggerFactory.getSingleton (loggerfactory.java:230)
At Org.slf4j.LoggerFactory.bind (loggerfactory.java:121)
At org.slf4j.LoggerFactory.performInitialization (loggerfactory.java:112)
At org.slf4j.LoggerFactory.getILoggerFactory (loggerfactory.java:275)
At Org.slf4j.LoggerFactory.getLogger (loggerfactory.java:248)
At com.unmi.testjcloverslf4j.<clinit> (testjcloverslf4j.java:10)
caused by:java.lang.IllegalStateException:Detected both Jcl-over-slf4j.jar and Slf4j-jcl.jar on the class path, Pree Mpting Stackoverflowerror. See also Http://www.slf4j.org/codes.html#jclDelegationLoop for more details.
At org.slf4j.impl.jclloggerfactory.<clinit> (jclloggerfactory.java:64)
... 8 More
Exception in thread "main"

Several practical application modes of SLF4J three: slf4j+jcl-over-slf4j