About java logging framework

  

Laog4j

  Apache Log4j is an open source project, Spring Boot1.4 and later versions no longer support log4j, log4j have not been updated for a long time, now there are many other Log4j logging framework has been improved, for example SLF4J, Logback etc. .

Log4j2

  And Log4j 2 and Logback are very similar in every respect, so why do we need Log4j 2

       1. Plug-type structure. Log4j 2 supports plug-in structure. We can expand on their own Log4j 2. We can implement your own appender, logger, filter according to their needs. 
  2. profile optimization. Properties can be referenced in the configuration file, or alternatively may also be directly passed to the component. And support profile json format. Unlike other logging framework, it is time to re-configure the log files are not lost before. 
  3. Java 5 concurrency of. Log4j 2 using the concurrency features in Java 5 support, the implementation of the minimum level locking as possible. To solve the remaining issues deadlock in log4j 1.x. 
  4. Asynchronous logger. Log4j 2 is based on the LMAX Disruptor library. In multithreaded scenarios, and compared to the existing logging framework, asynchronous logger has about 10 times the efficiency gains.

  The official suggested the average programmer to view log into asynchronous mode, some operators log into sync. The benefits of asynchronous log output is to use a separate process to perform the functions of the printing log, the log can improve efficiency, reduce the impact of logging on normal business.

       Asynchronous log in classpath program needs to load disruptor-3.0.0.jar or higher version.

    <dependency>

 <groupId>com.lmax</groupId> <artifactId>disruptor</artifactId> <version>3.3.6</version> </dependency>

Asynchronous log is divided into two types: 

. a full asynchronous mode 
  This asynchronous log mode, without modifying the principle of modifying the configuration file, Logger still use <root> and  <logger> 
  only need the code at the beginning of the main program, add a system property code:

  System.setProperty("Log4jContextSelector", "org.apache.logging.log4j.core.async.AsyncLoggerContextSelector")

b. Non-asynchronous and asynchronous mode mixing output 

   In the configuration file Logger use <asyncRoot> or <asyncLogger>

<loggers> <AsyncLogger name="AsyncLogger" level="trace" includeLocation="true"> <appender-ref ref="Console" /> <appender-ref ref="debugLog" /> <appender-ref ref="errorLog" /> </AsyncLogger> <asyncRoot level="trace" includeLocation="true"> <appender-ref ref="Console" /> </asyncRoot> </loggers> 

Introduced log4j2 rely 
  when creating a Spring Boot project, we introduced the spring-boot-starter, which contains a spring-boot-starter-logging, the content is dependent on Spring Boot default logging framework Logback,

So before we introduced log4j2, we need to exclude depend on this package, and then rely on the introduction of log4j2.

  log4j2.xml configuration 
One thing to note is that if you want to specify a log file stored in application.properties path or log file name, use log4j2.xml in ${LOG_PATH}or ${LOG_FILE}referenced, can not be acquired (can indulge in the logback use).

 log4j2 support xml, json, yaml and other configuration file formats.

 

slf4j

SLF4J,即简单日志门面(Simple Logging Facade for Java),不是具体的日志解决方案,而是通过Facade Pattern提供一些Java logging API,它只服务于各种各样的日志系统。
按照官方的说法,SLF4J是一个用于日志系统的简单Facade,允许最终用户在部署其应用时使用其所希望的日志系统。作者创建SLF4J的目的是为了替代Jakarta Commons-Logging。 
实际上,SLF4J所提供的核心API是一些接口以及一个LoggerFactory的工厂类。在使用SLF4J的时候,不需要在代码中或配置文件中指定你打算使用那个具体的日志系统。
类似于Apache Common-Logging,SLF4J是对不同日志框架提供的一个门面封装,可以在部署的时候不修改任何配置即可接入一种日志实现方案。
但是,他在编译时静态绑定真正的Log库。使用SLF4J时,如果你需要使用某一种日志实现,那么你必须选择正确的SLF4J的jar包的集合(各种桥接包)。
SLF4J提供了统一的记录日志的接口,只要按照其提供的方法记录即可,最终日志的格式、记录级别、输出方式等通过具体日志系统的配置来实现,因此可以在应用中灵活切换日志系统。

So when using SLF4J better? 
If you develop a library or embedded component, then you should consider using SLF4J, it is impossible to influence the end-user to select which system log. On the other hand, if it is a simple or a separate application,

Determine only one log system, then there is no need to use SLF4J. Suppose you intend to use log4j when you sell the product requires JDK 1.8 Logging users to modify the face of thousands of log4j calls,

I believe this is not an easy thing. But if they start using SLF4J, then this conversion will be a very easy thing.

Logback

Logback, a "reliable, versatile, fast and flexible Java logging framework."

logback currently divided into three modules:

            logback-core,

            logback- classic

            logback-access。

logback-core is the basis for the other two modules of the module.

logback-classic is a modified version of log4j.

  Further logback-classic complete implementation SLF4J API so you can easily be changed into other systems such as log log4j or JDK Logging.

  logback-access access module integrated with Servlet containers supplied by Http access log function. 

 The reasons for choosing logback: 
1. logback approximately 10 times faster than log4j, and consumes less memory. 
2. logback-classic module interfaces directly implements SLF4J, so we move to logback almost zero overhead. 
3. logback not only supports the configuration file xml format, also supports the configuration file groovy format. In contrast, Groovy style configuration files more intuitive and simple. 
4. logback-classic profile update can be detected and automatically reload the configuration file. 
5. logback gracefully recover from I / O exception, so that we do not have to restart the application to resume logger. 
6. logback according to the upper limit of the profile can be set to automatically delete old log files. 
7. logback can automatically compress log files. 
8. logback condition determination can be added (if-then-else) in the configuration file. Avoid duplication of different development environments (dev, test, uat ...) profile. 
9. logback bring more filter. 
Stack trace 10. logback the package contains more information. 
11. logback-access and Jetty, Tomcat integration provides powerful HTTP-access journal. 
Profile: the need to establish a logback.xml in the src directory of the project. 
Notes: (1) logback will first try to find logback.groovy file; 
(2) when not found, continue to try to find logback-test.xml file; 
(3) When not found, continue to try to find logback.xml file; 
(4) If still not found, the default configuration (printed to the console).

 

 

Apache Commons Logging

Apache Commons Logging, previously known as Jakarta Commons Logging (JCL) is provided in a log (Log) Interface (interface), taking into account the lightweight and does not depend on the specific log implementation tool. It is provided to the middleware / logging tool developers a simple log operation abstraction allows developers to use different tools to achieve specific log. The user is assumed to have been familiar with some of the details of the log to achieve a higher level tool. JCL provides interfaces for other logging tools, including Log4J, Avalon LogKit, and JDK 1.4+ the like, for a simple package, this interface closer to achieving the Log4J and LogKit. 
apache common-logging is to provide a common interface to the log. Users are free to choose a third-party logging component as a concrete realization, like log4j, jdk own or logging, common-logging will be through the mechanism of dynamic lookup, automatic log database to find out the real use of the program is running. Of course, there is a simple internal common-logging achieve a Simple logger, but very poorly. So use common-logging, often combined with log4j to use. Benefits of using it is that the code rather than rely on a common-logging log4j, and avoid specific logging program directly coupled, when necessary, you can change the log to achieve third-party libraries. 
Use common codes of common-logging:

Guess you like

Origin www.cnblogs.com/liuwd/p/10942718.html