Problem description: Too many logs, catalog becomes too large
Environment: gradle configuration
compile "org.slf4j:slf4j-api:${slf4jVersion}" compile "org.slf4j:slf4j-log4j12:${slf4jVersion}" compile "org.slf4j:jcl-over-slf4j:${slf4jVersion}" compile "org.slf4j:jul-to-slf4j:${slf4jVersion}" Among them, log4j:1.2.17, jcl-over-slf4j:1.7.7, slf4j-api:1.7.12, slf4j-log4j12:1.7.7, jcl-over-slf4j:1.7.7 are all configured correctly, but the log is still is too much, and the settings in log4j do not take effect
Cause analysis: It is found that the imported jar package contains the LogBack jar package, and the specific discovery is StaticLoggerBinder; there are multiple
Problem solving: delete the logback jar package
Knowledge Supplement: For example, when using SLF4j, in order to avoid conflicts, it is necessary to ensure that only one implementation class jar is packaged in it.
--------------------------------------------------
If you are very clear about commons-loging, log4j, slf4j, LogBack, etc., you can ignore this article. A brief summary of these concepts when solving the log conflict problem several times. I hope that students who do not understand the basics can be helpful. Of course, if you have a deeper understanding of this area, you can also contribute your own knowledge and knowledge. opinion.
1. Concept
Commons-logging : Facade interface of the earliest log provided by apache. Avoid direct coupling with specific logging schemes. Similar to JDBC's api interface, the specific JDBC driver is implemented by each database provider. Decoupled through a unified interface, but it also implements some simple log schemes internally.
Log4j : A classic logging solution. Internally, the abstraction of the logging system is encapsulated into Logger, appender, pattern and other implementations. We can easily manage and diversify the log system through configuration files.
Slf4j : The full name is Simple Logging Facade for JAVA: java simple log facade. It is a facade encapsulation provided by different log frameworks. You can access a log implementation solution without modifying any configuration during deployment. It should have the same original intention as commons-loging. Personally, I feel that the design is better, and there are not as many unspoken rules as commons. Also has two additional features:
1. Can support multiple parameters and replace them with {} placeholders to avoid the helpless judgment of old writing logger.isXXXEnabled, and bring performance improvement. See: http://www.slf4j.org/faq.html# logging_performance .
2. OSGI mechanism is better compatible and supported
A picture is worth a thousand words, a picture on the official website:
As you can see from the picture above, there are still many choices.
Logback : LOGBack, as a general, reliable, fast and flexible logging framework, will serve as a replacement for Log4j and SLF4J to form a complete implementation of the new logging system. The official website says it has excellent performance, executing 10 times faster than log4j on the critical path, and consumes less memory. For specific advantages, see:
http://logback.qos.ch/reasonsToSwitch.html
2. Common log schemes and precautions
1.Commons-logging+log4j : A classic log implementation scheme. appear in various frameworks. Such as spring , webx, ibatis and so on. Using log4j directly can satisfy our logging scheme. However, in order to avoid directly relying on the specific log implementation, it is generally implemented in combination with commons-logging. Common codes are as follows:
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
private static Log logger = LogFactory.getLog(CommonsLoggingTest.class);
The code does not depend on any log4j internal classes. So how is log4j loaded?
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. There is a Log4JLogger implementation class inside the Log interface and an agent for the log4j logger is provided internally. LogFactory internal loading log system process:
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 will be scanned, and if found, the configuration inside will be loaded and used.
3. Otherwise, look for commons-logging.properties from the Classpath, and load it according to the configuration inside.
4. Otherwise, use the default configuration: if Log4j can be found, the log4j implementation will be used by default, if not, the JDK14Logger implementation will be used, and if not, the SimpleLog implementation provided by commons-logging will be used.
From the above loading process, if no configuration is done, as long as log4j is introduced and log4j.xml is configured on the classpath, commons-logging will make log4j work normally, and the code does not need to depend on any log4j code.
2.Commons-logging+log4j+slf4j
If in the original commons-logging system, if you want to migrate to slf4j, it is also possible to replace commons-logging with slf4j. The principle uses the second point of commons-logging loading above. Need to import Org.slf4j.jcl-over-slf4j-1.5.6.jar. This jar package provides a bridge so that the underlying implementation is based on slf4j. The principle is that the configuration META-INF/services/org.apache.commons.logging.LogFactory =org.apache.commons.logging.impl.SLF4JLogFactory is stored in the jar package, and commons-logging will find this serviceId during initialization , and call it LogFactory.
After the bridge is completed, how does the simple log facade SLF4J load the appropriate log?
原理是SLF4J 会在编译时会绑定import org.slf4j.impl.StaticLoggerBinder; 该类里面实现对具体日志方案的绑定接入。任何一种基于slf4j 的实现都要有一个这个类。如：
org.slf4j.slf4j-log4j12-1.5.6: 提供对 log4j 的一种适配实现。
Org.slf4j.slf4j-simple-1.5.6: 是一种 simple 实现，会将 log 直接打到控制台。
……
那么这个地方就要注意了：如果有任意两个实现slf4j 的包同时出现，那就有可能酿就悲剧，你可能会发现日志不见了、或都打到控制台了。原因是这两个jar 包里都有各自的org.slf4j.impl.StaticLoggerBinder ，编译时候绑定的是哪个是不确定的。这个地方要特别注意！！出现过几次因为这个导致日志错乱的问题。
3.Slf4j+logback
Slf4j 和log4j 作者都是同一个人。
Logback 号称在性能各方面有很多优势，也很诱人。
直接使用SLf4j 也很简单：
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class HelloWorld {
public static void main(String[] args) {
Logger logger = LoggerFactory.getLogger(HelloWorld.class);
logger.info("Hello World");
}
}
代码里也看不到任何具体日志实现方案的痕迹。
I haven't used Logback, and I've seen some tempting introductions. You can study for details. logback.
Precautions
When using log configuration, be sure to understand the requirements and avoid conflicts.
For example, in order to avoid conflicts when using SLF4j, it is necessary to ensure that only one implementation class jar is packaged in it.
When encountering problems such as log confusion, you can troubleshoot from these aspects