JCL and slf4j

Common log implementation ：JUL、log4j、logback、log4j2
Common log facade ：JCL、slf4j
The order of appearance ：log4j -->JUL-->JCL--> slf4j --> logback --> log4j2

JCL

JCL brief introduction
Its full name is Jakarta Commons Logging, yes Apache A general log provided API.
Users can freely choose the third-party log component as the specific implementation , image log4j, perhaps jdk Self contained jul, common-logging Through the mechanism of dynamic search , Automatically find out the real log library when the program is running .
Of course ,common-logging There's a Simple logger Simple implementation of , But the function is very weak . So use common-logging, Usually with log4j And other logging frameworks .
The advantage of using it is , Code dependency is common-logging Instead of log4j Of API, Avoid and specific logs API Direct coupling , When necessary , Third party libraries that can change the log implementation .
JCL There are two basic abstract classes ：
Log： Loggers
LogFactory： Log factory （ Responsible for creating Log example ）

Import dependencies first

<groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.2</version>
</dependency>
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
</dependency>

public class JCLTest01 {

    @Test
    public void test01(){

        /*

             We haven't imported the third-party logging framework yet , for example log4j

             By default , Will use JUL The logging framework records logs 

            JCL Usage principle ：
                 If there is log4j, priority of use log4j
                 If there is no third-party logging framework , What we use is JUL

         */
        Log log = LogFactory.getLog(JCLTest01.class);

        log.info("info Information ");

    }
}

summary ：
    The default is JUL, But it's integrating log4j After environment , Using log4j
    Observe by testing , Although the logging framework has changed , But the code hasn't changed at all

Benefits of log facade Technology ：
    Facade technology is interface oriented development , No longer rely on specific implementation classes , Reduce code coupling
    According to the actual needs , Flexible switching log framework
    A unified API, Convenient for developers to learn and use
    Unified configuration management facilitates the maintenance of project logs

 

SLF4J

Simple log face (Simple Logging Facade For Java) SLF4J Mainly for the sake of Java Log access provides a set of standards 、 canonical API frame , Its main significance is to provide interface , The specific implementation can be left to other log frameworks , for example log4j and logback etc. . Of course slf4j It also provides a simple implementation of the function , But it's rarely used . For general Java In terms of projects , The logging framework will choose slf4j-api As a facade , With specific implementation framework （log4j、logback etc. ）, Bridge is used in the middle . So we can figure out SLF4J The two most important functions are the binding of log framework and the bridging of log framework .
Official website ： https://www.slf4j.org/

Import dependence

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.25</version>
</dependency>
<!--slf4j  The self-contained simple log implementation  -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-simple</artifactId>
    <version>1.7.25</version>
</dependency>

SLF4J Level division of logs
trace、debug、info、warn、error The five level
trace： Log tracking information
debug： Log details
info： Key information of the log Default print level
warn： Log warning message
error： Log error messages

Without any other logging implementation framework Integration
slf4j It uses its own framework slf4j-simple
slf4j-simple It must also be imported as a separate dependency

<!--<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-simple</artifactId>
    <version>1.7.25</version>
</dependency>-->

    @Test
    public void test03(){
        Logger logger = LoggerFactory.getLogger(SLF4JTest01.class);
        String name = "zs";
        int age = 23;
        //logger.info(" Student information - full name ："+name+"; Age ："+age);
        //logger.info(" Student information - full name ：{}, Age ：{}",new Object[]{name,age});
        logger.info(" Student information - full name ：{}, Age ：{}",name,age);

        try {
            int n = 1/0;
        } catch (ClassNotFoundException e) {
            // Print stack tracking information 
            //e.printStackTrace();
            //e Is a reference type object , Can't root in front of {} Do effective string splicing 
            //logger.info(" The specific mistake is ：{}",e);// Wrong writing 
            // We don't have to add {}, Directly followed by the exception object e that will do 
            logger.info(" The specific mistake is ：",e);
        }
    }

SLF4J Log facade , share 3 There are three cases to bind the log implementation
1. Without binding any log implementation , Logs cannot be bound to achieve any function
    It's worth noting that , Through our demonstration just now ,slf4j-simple yes slf4j Official
    When you use it , You also need to import dependencies , Automatically bind to slf4j On the facade
    If you don't import ,slf4j Core dependencies do not provide any implementation
2.logback and simple（ Include nop）
    All are slf4j The log implementation provided behind the facade timeline , therefore API Follow exactly slf4j Design in progress
    Then we only need to import the log implementation dependencies we want to use , Can be with slf4j Seamless connection
    It is worth mentioning that nop Although it is also divided into implementation , But he means that logging is not implemented （ Follow up courses ）
3.log4j and JUL（ These two need to import adapters ）
    All are slf4j The log implementation in front of the facade timeline , therefore API Non compliance slf4j Design
    Through adaptive bridging technology , Complete the connection with the log facade

        <!-- Import log4j The adapter depends on -->
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
            <version>1.7.25</version>
        </dependency>

        <!-- Import jul The adapter depends on -->
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-jdk14</artifactId>
            <version>1.7.25</version>
        </dependency>

In a real production environment ,slf4j Just bind a log implementation framework
The binding of multiple , By default, the first import dependency is used , And unnecessary warning messages may be generated

            demand ：
                Suppose our project has been using log4j Log framework
                But with the upgrading of technology and requirements
                log4j It can no longer meet the needs of our system
                Now we need to reconstruct the log implementation in the system into slf4j+logback The combination of
                Without touching java In the case of source code , Solve this problem

                At this time, you need to replace the log with slf4j+logback
                Since we don't have to log4j 了 , will log4j Remove
                take slf4j Log facade and logback The log implementation of depends on adding
                To do so , period log4j Environmental support , Compiler error

                At this time, you need to use a bridge to do this
                The bridge solves the problem of log reconstruction in the project , There are previous logs in the current system API,
                You can bridge to slf4j The implementation of the

                Use steps of bridge ：
                1. Remove the old logging framework dependency
                    <dependency>
                        <groupId>log4j</groupId>
                        <artifactId>log4j</artifactId>
                        <version>1.2.17</version>
                    </dependency>
                2. add to slf4j Bridging components provided
                    log4j Related bridge
                    <dependency>
                        <groupId>org.slf4j</groupId>
                        <artifactId>log4j-over-slf4j</artifactId>
                        <version>1.7.25</version>
                    </dependency>
                  After the bridge is added , Code compilation will not report errors

 

 

 Be careful ：
     After the bridge is added , There is no need to add adapters 
     Bridges and adapters cannot import dependencies at the same time 
     If the bridge is configured above the adapter , An error is reported during operation , Different things happen at the same time 
     If the bridge is configured under the adapter , The bridge... Is not executed , It doesn't make any sense