Several practical application modes of SLF4J -- three: JCL-Over-SLF4J + SLF4J, slf4jlog4j

Several practical application modes of SLF4J -- three: JCL-Over-SLF4J + SLF4J, slf4jlog4j

We have already discussed two SLF4J usage methods: SLF4J + Log4J and SLF4J + Logback. That is ideal, when only SLF4J is used as a unified log framework. However, JCL has always had a profound impact. When SLF4J is getting better, it is very likely that the components used in your project use JCL and SLF4J respectively. For example, if Hibernate 3.5 and Struts are used in the project, or some other open source components of Apache, you may not want to use the SLF4J component log information to output to, when JCL component logs are used to output to B, where should the log information in your own code be written?

The Chinese have always been pursuing unification, and they do not like the city-state system to facilitate the separation. However, when it comes to log output, it must be unified to a single channel. On the one hand, multiple channels waste resources and facilitate configuration and management. So since SLF4J is a trend, when SLF4J and JCL are thrown into a jar, SLF4J will be the main one first, supplemented by JCL, that is, the JCL bridge should be connected to SLF4J, output log information in a unified manner through SLF4J. So that is the SLF4J usage mode to introduce: JCL-Over-SLF4J + SLF4J.

The previous understanding of SLF4J shows that even if JCL is passed to SLF4J, logs still cannot be output, and a log implementation is required. Log4J must be used at the lower layer, and Logback should be used if you want to use Logback. So we have to go down after SLF4J, that is, the first two SLF4J + Log4J and SLF4J + Logback. In this article, the SLF4J mode is divided:

JCL-Over-SLF4J +SLF4J + Log4JAnd JCL-Over-SLF4J +SLF4J + LogbackThe two implementation methods are similar. Only use jar package and configuration files are different, SLF4J + Log4J and SLF4J + Logback what files are the original or need those files now, but must add jcl-over-slf4j-1.5.11.jar package. JCL-Over-SLF4J +SLF4J + Logback.

The following four jar files and an xml file must be placed on the ClassPath of the project.

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

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

The following is the simplest logback. xml file.

<? Xml version = "1.0" encoding = "UTF-8"?>

<Configuration>

<Appender name = "stdout" class = "ch. qos. logback. core. leleappender">

<Encoder charset = "GBK">

<Pattern> [Consociate] % d {HH: mm: ss. SSS} [% thread] %-5 level % logger {36}-% msg % n </pattern>

</Encoder>

</Appender>

<Root level = "DEBUG">

<Appender-ref = "stdout"/>

</Root>

</Configuration>

To see the effect, we added [Consociate] to the input pattern to check whether it is unified into a single log channel.

Use JCL and SLF4J code

 

 

Package com. unmi;

 

Import org. apache. commons. logging. Log;

Import org. apache. commons. logging. LogFactory;

Import org. slf4j. Logger;

Import org. slf4j. LoggerFactory;

 

Public class TestJCLOverSlf4j {

// SLF4J Logger

Private static final Logger logger = LoggerFactory. getLogger ("From SLF4J ");

 

// JCL Log

Private static final Log log = LogFactory. getLog ("From JCL ");

 

// Use the preceding logger and log to output logs respectively. From the output, you can see that they are unified into one channel.

Public static void main (String [] args ){

Logger.info ("Hello {}", "From SLF4J ");

Log.info ("Hello From JCL ");

}

}

 

In the above Code, we used both the JCL unified log framework and the SLF4J unified log framework. Note that logs bridge from JCL cannot output parameterized messages. The above Code uses org. apache. commons. logging. Log, import org. apache. commons. logging. LogFactory, but you don't need to introduce the commons-logging.jar package.

Run the above Code and see the output:

[Consociate] 23:19:39. 890 [main] INFO From SLF4J-Hello From SLF4J
[Consociate] 23:19:39. 921 [main] INFO From JCL-Hello From JCL

It is clear that the log output of the JCL framework and SLF4J framework is unified into one channel. Why? SLF4J uses the Logback output information, which is correct. JCL does not know Logback. Therefore, the output of the JCL framework must be redirected to SLF4J and finally output by Logback.

Implementation Analysis: 

We opened the jcl-over-slf4j-1.5.11.jar and saw two packages in org. apache. commons. logging and org. apache. commons. logging. impl, and there are corresponding classes, which is why, although there are:

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

But there is no need to introduce the commons-logging.jar package to the class path.

Go deep into the jcl-over-slf4j-1.5.11.jar and see a file/META-INF/services/org. apache. commons. logging. LogFactory with the following content:

Org. apache. commons. logging. impl. SLF4JLogFactory

 

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

When JCL is running, SLF4JLogFactory is used to delegate the JCL log implementation to SLF4J, and then SLF4J further completes the specific log output.

Using JCL-Over-SLF4J +SLF4J + Log4JThe usage mode is similar, so we will not detail it here. In summary, JCL regards SLF4J as its log implementation.

Imagine another question: what would happen if we put both the jcl-over-slf4j-1.5.11.jar and the slf4j-jcl-1.5.11.jar in ClassPath? JCL proxy to SLF4J, SLF4J is bound to JCL again, by the way, the endless loop, StackOverFlow error:

SLF4J: the 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. Server Load balancer. LoggerFactory. getSingleton (LoggerFactory. java: 230)
At org. Server Load balancer. LoggerFactory. bind (LoggerFactory. java: 121)
At org. slf4j. LoggerFactory. performInitialization (LoggerFactory. java: 112)
At org. slf4j. LoggerFactory. getILoggerFactory (LoggerFactory. java: 275)
At org. Server Load balancer. 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, preempting 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"

 

 

The reason is that two jar files about log4j are referenced, resulting in an endless loop.

 

Log4j-over-slf4j-1.7.7.jar

 

Slf4j-log4j12-1.7.7.jar

 

But only referencing the slf4j-log4j12-1.7.7.jar will prompt org. apache. log4j. Level this class cannot be found

 

To use log4j to record logs, you only need to reference the log4j-over-slf4j-1.7.7.jar.