日志对于Spring
来说非常重要(废话,日志对哪个系统不重要?),因为 a)它是唯一强制的外部依赖,b)每个人都希望在使用某个工具时可以看到一些友好地输出,c)Spring
集成了很多其他的工具,它们也都有自己的日志依赖。应用开发者的一个目标通常是:对于整个应用来说(包括所有的外部组件),集中创建一个统一的日志配置。由于现在有如此多的日志框架,这个选择看起来会变得更难。
Logging is a very important dependency for Spring because a) it is the only mandatory external dependency, b) everyone likes to see some output from the tools they are using, and c) Spring integrates with lots of other tools all of which have also made a choice of logging dependency. One of the goals of an application developer is often to have unified logging configured in a central place for the whole application, including all external components. This is more difficult than it might have been since there are so many choices of logging framework.
Spring
中托管的日志依赖是Jakarta Commons Logging API (JCL)
。我们反编译JCL
并且让JCL
日志对象对于所有继承Spring
框架的类可见。由于Spring
的所有版本都使用相同的日志库,所以迁移变的很简单。因为保证了向后兼容,甚至对于继承了Spring
的应用来说也一样。我们处理的方法是让Spring
的其中一个模块明确地依赖于commons-logging
(JCL
的标准实现),然后在编译时让其他的模块都依赖于这个模块。如果你使用Maven
,并且想知道在哪里引入了commons-logging
的依赖,你会发现它是从Spring
的核心模块spring-core
中引入的。
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 that all versions of Spring use the same logging library: migration is easy because backwards compatibility is preserved even with applications that extend Spring. The way we do this is to make one of the modules in Spring depend explicitly on commons-logging (the canonical implementation of JCL), and then make all the other modules depend on that at compile time. If you are using Maven for example, and wondering where you picked up the dependency on commons-logging, then it is from Spring and specifically from the central module called spring-core.
commons-logging
的好处是让你不需要任何别的东西就可以让你的应用工作。它有一个运行时的发现算法,会在classpath
下寻找另外的日志框架,并且使用其中一个它认为合理的(或者你可以告诉它你需要哪一个)。如果在classpath
下没有可用的日志框架,那么你将会使用JDK
自带的日志(java.util.logging
缩写JUI
)。你会发现在大多数情况下你的Spring
应用可以正常工作并且可以很轻松地将日志打印到控制台,这很重要。
The nice thing about commons-logging is that you don’t need anything else to make your application work. It has a runtime discovery algorithm that looks for other logging frameworks in well known places on the classpath and uses one that it thinks is appropriate (or you can tell it which one if you need to). If nothing else is available you get pretty nice looking logs just from the JDK (java.util.logging or JUL for short). You should find that your Spring application works and logs happily to the console out of the box in most situations, and that’s important.
commons logging
不幸地是,commons-logging
的运行时发现机制虽然对于终端用户很方便,却是有问题的。如果我们可以让时间倒退重新开始Spring项目,我们可能会使用一个不同的日志依赖。第一选择很可能就是Simple Logging Facade for Java
( SLF4J
),很多工具中都使用到了SLF4J
,并且这些工具在应用中通常是和Spring
集成使用。
Unfortunately, the runtime discovery algorithm in commons-logging, 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 is also used by a lot of other tools that people use with Spring inside their applications.
基本上现在有两种关闭commons-logging
的方法:
There are basically two ways to switch off commons-logging:
从spring-core
模块中排除commons-logging
依赖(因为它是唯一明确地依赖于commons-logging
的模块)
Exclude the dependency from the spring-core module (as it is the only module that explicitly depends on commons-logging)
依赖于一个特殊的commons-logging
依赖,它将会用一个空的jar来替换原有jar(更详细的信息可以查看SLF4J
的FAQ)
Depend on a special commons-logging dependency that replaces the library with an empty jar (more details can be found in the SLF4J FAQ)
为了排除commons-logging
,需要在dependencyManagement
部分添加下列代码:
<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>
现在这个应用已经无法正常运行了,因为在classpath
下没有JCL API
的实现,为了解决这个问题,我们还是需要提供一个实现。在下面一节中我们将举例告诉你如何使用SLF4J
来提供一个可替代的JCL
实现。
Now this application is probably broken because there is no implementation of the JCL API on the classpath, so to fix it a new one has to be provided. In the next section we show you how to provide an alternative implementation of JCL using SLF4J as an example.
SLF4J
是一个更纯粹的依赖并且在运行时比commons-logging
更有效率,因为它使用编译时绑定来代替了运行时发现机制来寻找其他集成的日志框架。这也意味着你需要更清楚在运行时你希望发生什么,然后通过相应的声明或配置来实现。SLF4J
提供对很多常见的日志框架的绑定,所以你可以绑定一个你已经在用的日志框架来配置和管理。
SLF4J is a cleaner dependency and more efficient at runtime than commons-logging because it uses compile-time bindings instead of runtime discovery of the other logging frameworks it integrates. This also means that you have to be more explicit about what you 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 that you already use, and bind to that for configuration and management.
SLF4J
提供对很多常见的日志框架的绑定,包括JCL
,倒过来也成立:因为这是一条其他日志框架和SLF4J
的桥梁。所以想要在Spring
中使用SLF4J
,你需要用SLF4J-JCL
桥梁来替代commons-logging
依赖。一旦你替换了,那么Spring
中的日志的调用将都会被转换成对SLF4J API
的调用,如果在你的应用中的其他lib也使用了这个API
,那么你可以有一个集中的地方来配置和管理日志。
SLF4J provides bindings to many common logging frameworks, including JCL, and it also does the reverse: bridges between other logging frameworks and itself. So to use SLF4J with Spring you need to replace the commons-logging dependency with the SLF4J-JCL bridge. Once you have done that then logging calls from within Spring will be translated into logging calls to the SLF4J API, so if other libraries in your application use that API, then you have a single place to configure and manage logging.
一个常见的选择可能会是建立Spring
和SLF4J
的桥梁,然后提供明确的从SLF4J
到Log4J
的绑定。你需要提供4个依赖(排除已经存在的commons-logging
):桥梁,SLF4J API
,对Log4J
的绑定,Log4J
的实现。在Maven
中你可以做如下配置:
A common choice might be to bridge Spring to SLF4J, and then provide explicit 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 Log4J, and the Log4J implementation itself. In Maven you would do that like 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>
为了得到一些日志,这看起来可能会引入很多依赖。,
That might seem like a lot of dependencies just to get some logging. Well it is, but it is optional, and it should behave better than the vanilla commons-logging with respect to classloader issues, notably if you are in a strict container like an OSGi platform. Allegedly there is also a performance benefit because the bindings are at compile-time not runtime.
在SLF4J
用户中,一个更常见的选择是直接绑定到Logback
上,因为这样步骤更少且产生的依赖也更少。其中省去了额外的绑定这一步因为Logback
直接实现了SLF4J API
,你只需要依赖两个lib而不是四个(jcl-over-slf4j
和logback
)。如果你这么做,还需要从其他外部依赖(不是Spring
)中排除slf4j-api
,因为你只需要一个版本的SLF4J API
在你的classpath
下。
A more common choice amongst SLF4J users, which uses fewer steps and generates fewer dependencies, is to bind directly to Logback. This removes the extra binding step because Logback implements SLF4J directly, so you only need to depend on two libraries not four ( jcl-over-slf4j and logback). If you do that you might also need to exclude the slf4j-api dependency from other external dependencies (not Spring), because you only want one version of that API on the classpath.
很多人因为配置和管理的原因,选择Log4J
作为日志框架。它是高效且完善的,并且在实际中当我们构建和测试Spring时,运行时使用的就是Log4J
。Spring
也提供一些工具类来配置和初始化Log4j
,所以在一些模块中有些可选择的编译时依赖Log4j
。
Many people use Log4j as a logging 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 has an optional compile-time dependency on Log4j in some modules.
为了让Log4j
可以和默认的JCL
依赖(commons-logging
)一起工作,你需要做的是将Log4j
放到classpath
下,并且提供一个配置文件(在classpath
提供一个log4j.properties
或log4j.xml
)。对于Maven
用户来说,下面给出依赖的声明:
To make Log4j work with the default JCL dependency ( commons-logging) all you need to do is put Log4j on the classpath, and 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>
下面是一个log4j.properties
的示例配置告诉你如何将日志输出到控制台:
log4j.rootCategory=INFO, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %t %c{2}:%L - %m%n
log4j.category.org.springframework.beans.factory=DEBUG
原文地址:http://blog.csdn.net/u012345283/article/details/45293813