Spring Official document--Log

2.3.2 Log

The log Spring is very important (nonsense, which system is not important to the log?). Because a) it is the only mandatory external dependency, B) Everyone wants to see some friendly output when using a tool, C) Spring integrates many other tools, and they all have their own log dependencies. One goal of the application developer is usually to create a unified log configuration for the entire application, including all external components. With so many log frames now, this option seems to be getting harder.

Logging is a very important dependency for Spring because a) it's the only mandatory external dependency, B) Everyone lik Es to see some output from the tools they is using, and C) Spring integrates with lots of other tools all of which has a LSO made a choice of logging dependency. One of the goals of an application developer are often to has unified logging configured in a central place for the whole application, including all external components. This was more difficult than it might has been since there is so many choices of the logging framework.

The log dependency hosted in

Spring is Jakarta Commons Logging API (JCL) . We decompile the JCL and make the JCL log Object visible to all classes that inherit the Spring framework. Because all versions of Spring use the same log library, migration is simple. This is true for backwards compatibility, even for applications that inherit Spring . Our approach is to make one of the modules of Spring explicitly dependent on commons-logging (the standard implementation of JCL ). Then let the other modules depend on the module at compile time. If you use Maven and want to know where to introduce the dependency of commons-logging , you will find it is the core module from Spring Spring-core is introduced in the .

The mandatory logging dependency in Spring is the Jakarta Commons logging API (JCL). We compile against JCL and we also make JCL Log objects visible for classes that extend the Spring Framework. It's important to users, all versions of Spring use the same logging library:migration are easy because backwards comp Atibility is preserved even with applications that extend Spring. The "the" and "the" to "modules" in Spring depend explicitly on commons-logging (the canonical implementat Ion of JCL), and then make all the other modules depend on that at compile time. If you were using Maven for example, and wondering where you picked up the dependency on commons-logging, then it's from S Pring and specifically from the central module called Spring-core.

commons-loggingThe advantage is that you don't need anything else to make your app work. It has a runtime discovery algorithm that will classpath look under another log frame and use one of the ones it deems reasonable (or you can tell it which one you need). If classpath there is no log frame available, then you will use your JDK own log ( java.util.logging abbreviation JUI ). You'll find that in most cases your Spring app works and it's easy to print logs to the console, which is important.

The nice thing on commons-logging is so you don ' t need anything else to make your application work. It has a runtime discovery algorithm, looks for other logging frameworks in well known places on the classpath and use s one, it thinks is appropriate (or you can tell it which one if you need to). If Nothing else was available you get pretty nice looking logs just from the JDK (java.util.logging or JUL to short). You should find this your Spring application works and logs happily to the console out of the box in most situations, and That ' s important.

Do not use commons logging

Unfortunately, commons-logging the runtime discovery mechanism is problematic, although it is very convenient for the end user. If we can get the time backwards to start the spring project again, we might use a different log dependency. The first choice is probably Simple Logging Facade for Java ( SLF4J ), which is used in many tools SLF4J , and is often used and integrated in the application Spring .

Unfortunately, the runtime discovery algorithm in commons-logging and while convenient for the end-user, is problematic. If we could turn back the clock and start Spring now as a new project it would use a different logging dependency. The first choice would probably be the simple Logging facade for Java (SLF4J), which are also used by a lot of other tools That people use with Spring inside their applications.

There are basically two commons-logging ways to close it:

There is basically the ways to switch off commons-logging:

1. spring-coreexclude dependencies from the module commons-logging (because it is the only module that is explicitly dependent commons-logging )

   Exclude the dependency from the Spring-core module (as it's the only module, then explicitly depends on commons-logging)

2. Depending on a particular commons-logging dependency, it will replace the original jar with an empty jar (more detailed information can be viewed SLF4J in the FAQ)

   Depend on a special commons-logging dependency this replaces the library with an empty jar (more details can is found in T He slf4j FAQ)

In order to exclude commons-logging , you need to dependencyManagement add the following code in the section:

<dependencies>    <dependency>        <groupId>Org.springframework</groupId>        <artifactid>Spring-core</artifactid>        <version>4.0.9.RELEASE</version>        <exclusions>            <exclusion>                <groupId>Commons-logging</groupId>                <artifactid>Commons-logging</artifactid>            </exclusion>        </exclusions>    </Dependency></dependencies>

Now that the application is not working properly, because classpath there is no JCL API implementation, in order to solve this problem, we still need to provide an implementation. In the following section we will give an example of how you can use it SLF4J to provide an alternative JCL implementation.

Now this application is probably broken because there are no implementation of the JCL API on the classpath, so to fix it a The new one has been provided. The next section of the We show provide a alternative implementation of the JCL using SLF4J as an example.

Using SLF4J

SLF4Jis a more purely dependent and more efficient at run time commons-logging , because it uses compile-time binding instead of the runtime discovery mechanism to look for other integrated log frameworks. This also means that you need to be more aware of what you want to happen at run time and then implement it with the appropriate declaration or configuration. SLF4Jprovides bindings for many common log frameworks, so you can bind a log framework that you already use to configure and manage.

SLF4J is a cleaner dependency and more efficient at runtime than commons-logging because it uses compile-time bindings ins Tead of runtime discovery of the other logging frameworks it integrates. This also means so you've had to being more explicit on what's want to happen at runtime, and declare it or configure it accordingly. SLF4J provides bindings to many common logging frameworks, so you can usually choose one the already use, and bind to The For configuration and management.

SLF4JProvides bindings for many common log frameworks, including JCL , upside down: Because this is a bridge of other log frames SLF4J . So to Spring use in SLF4J , you need to use SLF4J-JCL bridges instead of commons-logging dependencies. Once you have replaced, then the Spring log call in will be converted to a pair SLF4J API of calls, if the other Lib in your application also uses this API , then you can have a centralized place to configure and manage the log.

SLF4J provides bindings to many common logging frameworks, including JCL, and it also does the reverse:bridges between OT Her logging frameworks and itself. The slf4j with Spring need to replace the commons-logging dependency with the SLF4J-JCL Bridge. Once you has done this then logging calls from within Spring would be translated into logging calls to the slf4j API, so I F Other libraries in your application the use the that API, then you had a single place to configure and manage logging.

A common choice might be Spring to build bridges and SLF4J then provide explicit SLF4J bindings from to Log4J . You need to provide 4 dependencies (excluding already existing commons-logging ): Bridges, SLF4J API , bindings to, Log4J Log4J implementations. In the Maven you can do the following configuration:

A common choice might is to bridge Spring to SLF4J, and then provide explicit the binding from SLF4J to log4j. You need to supply 4 dependencies (and exclude the existing commons-logging): The bridge, the slf4j API, the binding to Lo G4j, and the log4j implementation itself. In the Maven you would do the this:

<dependencies>    <dependency>        <groupId>Org.springframework</groupId>        <artifactid>Spring-core</artifactid>        <version>4.0.9.RELEASE</version>        <exclusions>            <exclusion>                <groupId>Commons-logging</groupId>                <artifactid>Commons-logging</artifactid>            </exclusion>        </exclusions>    </Dependency>    <dependency>        <groupId>Org.slf4j</groupId>        <artifactid>Jcl-over-slf4j</artifactid>        <version>1.5.8</version>    </Dependency>    <dependency>        <groupId>Org.slf4j</groupId>        <artifactid>Slf4j-api</artifactid>        <version>1.5.8</version>    </Dependency>    <dependency>        <groupId>Org.slf4j</groupId>        <artifactid>Slf4j-log4j12</artifactid>        <version>1.5.8</version>    </Dependency>    <dependency>        <groupId>Log4j</groupId>        <artifactid>Log4j</artifactid>        <version>1.2.14</version>    </Dependency></dependencies>

In order to get some logs, this may seem to introduce a lot of dependencies. ，

That's might seem like a lot of the dependencies just to get some logging. Well it's, but it's optional, and it should behave better than the vanilla commons-logging with respect to ClassLoader I Ssues, notably if you is in a strict container like an OSGi platform. Allegedly there is also a performance benefit because the bindings was at Compile-time not runtime.

In SLF4J a user, a more common choice is to bind directly to the Logback top, because such steps are less and have fewer dependencies. This eliminates the need for additional bindings this step because it is Logback implemented directly SLF4J API , you only have to rely on two Lib instead of four ( jcl-over-slf4j and logback ). If you do this, you also need to exclude from other external dependencies (not Spring ) slf4j-api , because you only need one version SLF4J API classpath under your.

A more common choice amongst slf4j users, which uses fewer steps and generates fewer dependencies, was to bind directly to Logback. This removes the extra binding step because Logback implements SLF4J directly, so you only need to depend on both libraries Not four (JCL-OVER-SLF4J and Logback). If you do so might also need to exclude the SLF4J-API dependency from other external dependencies (not Spring), Beca Use the want one version of this API on the classpath.

Using log4j

Many people choose as a log framework because of configuration and management reasons Log4J . It is efficient and perfect, and in practice when we build and test spring, the runtime uses it Log4J . Some Spring tool classes are also available to configure and initialize Log4j , so there are some optional compile-time dependencies in some modules Log4j .

Many people use log4j as a logging the framework for configuration and management purposes. It ' s efficient and well-established, and in fact it's what we use at runtime when we build and test Spring. Spring also provides some utilities for configuring and initializing log4j, so it had an optional compile-time dependency On log4j in some modules.

In order for you to work with the Log4j default JCL dependency ( commons-logging ), what you need to do is to Log4j put it down and classpath provide a configuration file (in the classpath provided one log4j.properties or log4j.xml ). For Maven the user, the following is a declaration of dependency:

To make log4j work with the default JCL dependency (commons-logging) all your need to do are put log4j on the Classpath, an D provide it with a configuration file (Log4j.properties or log4j.xml in the root of the classpath). So for Maven users this is your dependency declaration:

<dependencies>    <dependency>        <groupId>Org.springframework</groupId>        <artifactid>Spring-core</artifactid>        <version>4.0.9.RELEASE</version>    </Dependency>    <dependency>        <groupId>Log4j</groupId>        <artifactid>Log4j</artifactid>        <version>1.2.14</version>    </Dependency></dependencies>

The following is an log4j.properties example configuration that tells you how to output a log to the console:

Log4j. Rootcategory=info, stdoutlog4j. Appender. StdOut=org. Apache. Log4j. ConsoleappenderLog4j. Appender. StdOut. Layout=org. Apache. Log4j. PatternlayoutLog4j. Appender. StdOut. Layout. Conversionpattern=%d{absolute}%5P%t%c{2}:%l-%m%nlog4j. Category. org. Springframework. Beans. Factory=debug

Spring Official document--Log