2.1 Spring的日志依赖

Spring Dependencies and Depending on Spring
Although Spring provides integration and support for a huge range of enterprise and other external tools, it intentionally keeps its mandatory dependencies to an absolute minimum: you shouldn’t have to locate and download (even automatically) a large number of jar libraries in order to use Spring for simple use cases. For basic dependency injection there is only one mandatory external dependency, and that is for logging (see below for a more detailed description of logging options).
Next we outline the basic steps needed to configure an application that depends on Spring, first with Maven and then with Gradle and finally using Ivy. In all cases, if anything is unclear, refer to the documentation of your dependency management system, or look at some sample code - Spring itself uses Gradle to manage dependencies when it is building, and our samples mostly use Gradle or Maven.
尽管spring提供企业级和其他工具的打范围集成和支持，它有意将强制依赖性保持为绝对最小值，你不应该找到并下载（甚至自动）大量JAR库，以便使用Spring进行简单使用。例如对于基本的依赖注入，只有一个强制外部依赖项，即用于日志记录（请参阅下面的日志选项的详细描述）。
下面我们列出了配置spring应用程序基本的步骤。分别介绍maven,Gradle,ILY.在任何情况下，如果有什么不清楚的话，请参考对你的依赖管理systemlogging选项文件）。或者看一些简单的样例代码，spirng自身构建时候使用Gradle管理依赖，并且我们的样例大多使用Gradle和maven.

---

Logging
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.
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.The nice thing about commons-logging is that you don’t need anything else to make your applicationwork. 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.
日志
日志是Spring唯一强制的外部依赖项。每个人都喜欢工具会打印出一些东西，Spring集成了一些其它的工具，所有这些工具都有日志依赖。应用开发人员的目标之一是通常需要在应用中心位置配置统一日志记录。包括所有的外部组件。自从有了很多日志选择框架以来，这个问题就变得困难了。
在Spring中唯一的强制日志依赖是JCL,我们编译在JCL也使JCL日志对象类扩展Spring框架可见.所有版本的Spring使用统一的日志类库对于使用者是很重要的；程序迁徙很容易，因为
即使是扩展Spring的应用程序，也可以保留向后兼容性，我们这样做的方式是让Spring中的一个模块显式地依赖于commons-logging（规范继承JCL），并且让那个其他的模块在编译期间依赖它。如果你是用maven,并且会好奇怎样获得commons-logging依赖，然后是Spring特别是核心模块Spring-core
使用commons-logging的好处是你不需要其他额外的东西来让你的应用程序工作。它在运行期间有一个查找算法用来在类路径的合适位置下寻找其他日志框架并且在恰当的地方使用（或者你可以告诉它你想要哪个），如果没有吧找到其他的日志框架你将会发现它使用的JDK自带的JUL API,Spring还是会正常的工作和打印日志到控制台，这是很重要的。


Not Using Commons Logging
Unfortunately, the runtime discovery algorithm in commons-logging, while convenient for the enduser, 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.
There are basically two ways to switch off commons-logging:
1. Exclude the dependency from the spring-core module (as it is the only module that explicitly
depends on commons-logging)
2. Depend on a special commons-logging dependency that replaces the library with an empty jar
(more details can be found in the SLF4J FAQ)
To exclude commons-logging, add the following to your dependencyManagement section:

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.
不使用Commons Logging
不幸的是，commons-logging的运行期间发现算法，在方便后台程序员的同时也是有很多问题的。如果我们撤销并且现在新建一个Spring项目，它将会使用一个不同的日志依赖。第一个不同的选择将是SLF4J，也深受Spring的大多使用者的欢迎。
这里有两种基础方式去切换commons-logging
1.在spring-core模块中去除这个依赖（因为它是唯一显式的模块。依赖于commons-logging）
2.选择一个特定commons-logging依赖用空jar包去替换掉这个类库
如果想去掉commons-logging,将下面的依赖管理部分加入到maven中
现在这个应用程序可能运行不了因为在类路径下没有JCL API的实现，所以下面提供了一个修复它的例子。在下面的部分，我们将用SLF4J提供一个可选的JCL实现作为例子。

Using 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 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.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
SLF4J是一个比commons-logging在运行期间更加高效简洁的依赖因为它使用了编译期间绑定而不是在运行期间发现其它自身集成的日志框架的算法。这也意味着你必须更明确地知道你想要在运行时发生什么。并且有根据的声明和配置它。SLFJ提供很多常用日志框架的绑定，所以你可以选择一个你准备要使用的，并且绑定配置并且管理。
SLF4J提供许多常用日志框架的绑定，包括JCL,并且它也在相反的方向上做了一些改进：连接自身和其他的日志框架，所以对于在Spring中使用SLF4J的时候你需要用SLF4J-JCL连接桥替换调commons-logging依赖。一旦你做了上述步骤，Spring日志调用将会使用SLF4J API.所以如果其他的类库在你的应用程序中使用了这个API,你将会用一些简单的方式去配置和管理日志。
一个常见的选择肯呢个是Spring和SLF4J桥，然后提供显式绑定到从slf4j到log4j，在maven下这样绑定SLF4J和Log4J

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. 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.
看起来这么多的依赖仅仅只是获得日志依赖。但是这是可选的，和commons-loggging相比它应该有更好的表现，值得注意的是如果您处于像OSGi平台这样的严格容器中。据称这样会有一些平台好处因为它实在编译期间绑定而不是运行期间的。
更常见的是slf4j用户之间的选择，它使用较少的步骤，生成更少依赖，是直接绑定到logback。这去除了额外的绑定步骤因为Logback直接实现了SLF4J。所以你可以依赖两个类库（jcl-over-slf4j and logback）而不是4个。如果你这样做，你可能也需要排除的是slf4j API依赖从其他外部依赖关系（不是Spring），因为你只想要一个版本的API的类路径。

---

Using 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. 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:

在运行期间容器和原生的JCL
许多人在提供JCL实现的容器里运行Spring应用程序。IBM的Webspsphere(WAS)是一个典型。这将会导致一些问题。不幸的是没有特别出色的解决方案：在大多情况下在你的应用程序下去除commons-logging依赖已经不能满足。
更清楚的讲：报告的问题通常不是JCL本身或者是commons-logging本身：而他们结合commons-logging到另一个框架（通常是log4j）这可能会失败，因为公共日志记录改变了它们之间运行时发现的方式。旧版本（1）在一些容器和大多数人使用的现代版本中找到。Spring不使用任何的JCL不寻常的部分API,所以那里没有任何问题，但只要你用Spring绑定Log4j试图做任何记录,可以发现Log4j不工作.
在这种情况下，最容易做的事情是颠倒类装入器层次结构（IBM称之为“父级”）。最后”），应用程序控制JCL的依赖，不是容器.这种选择并不总是公开，但在公共领域有许多其他建议可供选择，您的里程可能因容器的精确版本和特性集而异。