2.3 Usage scenarios 使用场景
The building blocks described previously make Spring a logical choice in many scenarios, from embedded applications that run on resource-constrained devices to full-fledged enterprise applications that use Spring’s transaction management functionality and web framework integration.
之前描述的构建块使Spring
成为许多场景中的逻辑(也就是下意识合理的)选择,从资源受限的嵌入式程序到成熟的企业应用程序都可以使用 Spring
事务管理功能和 web
框架集成。
图2.2。 典型的完整Spring Web应用程序
Spring’s declarative transaction management features make the web application fully transactional, just as it would be if you used EJB container-managed transactions. All your custom business logic can be implemented with simple POJOs and managed by Spring’s IoC container. Additional services include support for sending email and validation that is independent of the web layer, which lets you choose where to execute validation rules. Spring’s ORM support is integrated with JPA and Hibernate; for example, when using Hibernate, you can continue to use your existing mapping files and standard Hibernate SessionFactory
configuration. Form controllers seamlessly integrate the web-layer with the domain model, removing the need for ActionForms
or other classes that transform HTTP parameters to values for your domain model.
Spring
的声明式事务管理特性使Web
应用程序具有完全事务性,就像使用EJB容器管理的事务一样。 所有的定制业务逻辑都可以通过简单的POJO
实现,并由Spring
的IoC容器
管理。 其他服务包括独立于Web
层的发送电子邮件和验证的支持,允许你选择执行验证规则的位置。 Spring
的ORM
支持集成了JPA
和Hibernate
;(注:和4的文档比少了JDO
) 例如,当使用Hibernate
时,可以继续使用现有的映射文件和标准的Hibernate SessionFactory
配置。 表单控制器将Web
层与域模型无缝集成,从而无需使用ActionForms
或其他将HTTP
参数转换为域模型值的类。(注:也就是这些参数无须单独创建POJO来表达
)
图2.3。 Spring中间层使用第三方Web框架
Sometimes circumstances do not allow you to completely switch to a different framework. The Spring Framework does not force you to use everything within it; it is not anall-or-nothing solution. Existing front-ends built with Struts, Tapestry, JSF or other UI frameworks can be integrated with a Spring-based middle-tier, which allows you to use Spring transaction features. You simply need to wire up your business logic using an ApplicationContext
and use a WebApplicationContext
to integrate your web layer.
有时情况不允许你完全切换到一个不同的框架。 Spring
框架不强迫你使用它里面的一切; 它不是一个全有或全无的解决方案。 使用Struts
,Tapestry
,JSF
或其他UI
框架构建的现有前端可以与基于Spring
的中间层集成,它允许你使用Spring
事务功能。 你只需要使用ApplicationContext
连接你的业务逻辑,并使用WebApplicationContext
来集成你的web
层。
图2.4。 远程使用场景
When you need to access existing code through web services, you can use Spring’s Hessian-
, Rmi-
or HttpInvokerProxyFactoryBean
classes. Enabling remote access to existing applications is not difficult.
当你需要通过Web
服务访问现有代码时,可以使用Spring
的Hessian-,Rmi-
或HttpInvokerProxyFactoryBean
类(注:此处和4的文档对比,4使用的是JaxRpcProxyFactory 类
)
。 启用对现有应用程序的远程访问并不困难。
图2.5。 EJB - 包装现有POJO
The Spring Framework also provides an access and abstraction layer for Enterprise JavaBeans, enabling you to reuse your existing POJOs and wrap them in stateless session beans for use in scalable, fail-safe web applications that might need declarative security.
Spring Framework
还为Enterprise JavaBeans
提供了一个 访问和抽象层,使你可以重用现有的POJOs
,并将其封装在无状态会话bean
中,以用于可能需要声明性安全性的扩展即有安全故障的Web
应用程序中。
2.3.1 Dependency Management and Naming Conventions 依赖关系管理和命名约定
Dependency management and dependency injection are different things. To get those nice features of Spring into your application (like dependency injection) you need to assemble all the libraries needed (jar files) and get them onto your classpath at runtime, and possibly at compile time. These dependencies are not virtual components that are injected, but physical resources in a file system (typically). The process of dependency management involves locating those resources, storing them and adding them to classpaths. Dependencies can be direct (e.g. my application depends on Spring at runtime), or indirect (e.g. my application depends on commons-dbcp
which depends on commons-pool
). The indirect dependencies are also known as "transitive" and it is those dependencies that are hardest to identify and manage.
If you are going to use Spring you need to get a copy of the jar libraries that comprise the pieces of Spring that you need. To make this easier Spring is packaged as a set of modules that separate the dependencies as much as possible, so for example if you don’t want to write a web application you don’t need the spring-web modules. To refer to Spring library modules in this guide we use a shorthand naming convention spring-*
or spring-*.jar,
where *
represents the short name for the module (e.g. spring-core
, spring-webmvc
, spring-jms
, etc.). The actual jar file name that you use is normally the module name concatenated with the version number (e.g. spring-core-5.0.0.M3.jar).
Each release of the Spring Framework will publish artifacts to the following places:
- Maven Central, which is the default repository that Maven queries, and does not require any special configuration to use. Many of the common libraries that Spring depends on also are available from Maven Central and a large section of the Spring community uses Maven for dependency management, so this is convenient for them. The names of the jars here are in the form
spring-*-.jar
and the Maven groupId isorg.springframework
. - In a public Maven repository hosted specifically for Spring. In addition to the final GA releases, this repository also hosts development snapshots and milestones. The jar file names are in the same form as Maven Central, so this is a useful place to get development versions of Spring to use with other libraries deployed in Maven Central. This repository also contains a bundle distribution zip file that contains all Spring jars bundled together for easy download.
So the first thing you need to decide is how to manage your dependencies: we generally recommend the use of an automated system like Maven, Gradle or Ivy, but you can also do it manually by downloading all the jars yourself.
You will find bellow the list of Spring artifacts. For a more complete description of each modules, see Section 2.2, “Modules”.
依赖管理和依赖注入是不同的。为了让 Spring
的这些不错的功能运用到运用程序中(比如依赖注入),你需要导入所有需要的库(jar文件),并且在编译、运行的时候将它们放到你的类路径中。这些依赖关系不是注入的虚拟组件,而是文件系统中的物理资源(通常)。依赖关系管理的过程包括定位这些资源,存储它们并将它们添加到类路径。依赖可以是直接的(例如我的应用程序依赖于Spring
在运行时)或间接(例如我的应用程序依赖于commons-dbcp
,这取决于commons-pool
)。间接依赖性也称为“传递性”,它是那些最难识别和管理的依赖性。
如果你要使用Spring
,你需要得到一个包含你需要的Spring
的jar
库的jar
文件。为了使这过程更简单,Spring
被打包为一组模块,尽可能地分离依赖,所以假如你不想编写一个web
应用程序,你不需要spring-web
模块。为了在本指南中引用Spring
库模块,我们使用一个简写命名约定spring- *
或spring - *.jar
,其中*表示模块的短名称(例如spring-core,spring-webmvc,spring-jms等)。 )。你使用的实际jar文件名通常是与版本号连接的模块名(例如spring-core-5.0.0.M3.jar
)。
Spring Framework
的每个版本都会将工件发布到以下位置:
Maven Central
,它是Maven
查询的默认存储库,不需要使用任何特殊配置。Spring
依赖的许多通用库也可以从Maven Central
获得,Spring
社区的一大部分使用Maven
进行依赖关系管理,所以这对他们很方便。这里的jars的名字是在spring - * - .jar
和Maven groupId
是org.springframework
。- 在一个专门为
Spring
托管的公共Maven
仓库中。除了最终GA
版本,此存储库还托管开发快照和里程碑。jar
文件名的格式与Maven Central
相同,因此这是一个有用的地方,可以让Spring
的开发版本与Maven Central
中部署的其他库一起使用。此存储库还包含捆绑包分发zip
文件,其中包含捆绑在一起的所有Spring jar
以便于下载。
所以你需要决定的第一件事是如何管理你的依赖:我们一般建议使用一个自动化系统,如Maven,Gradle
或Ivy
,但你也可以手动下载所有的jar
本身。
你会发现下面的Spring
工件列表。有关每个模块的更完整的描述,请参见第2.2节“模块”。
表2.1。 Spring框架组件
GroupId | ArtifactId | Description |
---|---|---|
org.springframework | spring-aop | Proxy-based AOP support 基于代理的AOP支持 |
org.springframework | spring-aspects | AspectJ based aspects 基于AspectJ的切面 |
org.springframework | spring-beans | Beans support, including Groovy Bean支持,包括Groovy |
org.springframework | spring-context | Application context runtime, including scheduling and remoting abstractions 应用程序上下文运行时,包括调度和远程抽象 |
org.springframework | spring-context-support | Support classes for integrating common third-party libraries into a Spring application context 支持将常见的第三方库集成到Spring应用程序上下文中的类 |
org.springframework | spring-core | Core utilities, used by many other Spring modules 核心应用程序,由许多其他Spring模块使用 |
org.springframework | spring-expression | Spring Expression Language (SpEL) |
org.springframework | spring-instrument | Instrumentation agent for JVM bootstrapping JVM引导的工具代理 |
org.springframework | spring-instrument-tomcat | Instrumentation agent for Tomcat Tomcat的工具代理 |
org.springframework | spring-jdbc | JDBC support package, including DataSource setup and JDBC access support JDBC支持包,包括DataSource设置和JDBC访问支持 |
org.springframework | spring-jms | JMS support package, including helper classes to send and receive JMS messages JMS支持包,包括用于发送和接收JMS消息的助手类 |
org.springframework | spring-messaging | Support for messaging architectures and protocols 支持消息架构和协议 |
org.springframework | spring-orm | Object/Relational Mapping, including JPA and Hibernate support 对象/关系映射,包括JPA和Hibernate支持 |
org.springframework | spring-oxm | Object/XML Mapping 对象/ XML映射 |
org.springframework | spring-test | Support for unit testing and integration testing Spring components 支持单元测试和集成测试的Spring组件 |
org.springframework | spring-tx | Transaction infrastructure, including DAO support and JCA integration 事务基础设施,包括DAO支持和集成制定 |
org.springframework | spring-web | Web support packages, including client and web remoting Web支持包,包括客户端和Web远程处理 |
org.springframework | spring-webmvc | REST Web Services and model-view-controller implementation for web applications Web应用程序的REST Web服务和模型 - 视图 - 控制器实现 |
org.springframework | spring-websocket | WebSocket and SockJS implementations, including STOMP support WebSocket和SockJS实现,包括STOMP支持 |
Spring Dependencies and Depending on Spring 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
,最后使用Ivy
。 在所有情况下,如果有什么不清楚,请参考依赖管理系统的文档,或者查看一些示例代码 - Spring
本身使用Gradle
在构建时管理依赖关系,我们的示例主要使用Gradle
或Maven
。
Maven Dependency Management Maven 依赖管理
If you are using Maven for dependency management you don’t even need to supply the logging dependency explicitly. For example, to create an application context and use dependency injection to configure an application, your Maven dependencies will look like this:
如果你使用Maven
进行依赖关系管理,你甚至不需要显式提供日志记录依赖关系。 例如,要创建应用程序上下文并使用依赖注入来配置应用程序,你的Maven
依赖关系将如下所示:
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.0.0.M3</version>
<scope>runtime</scope>
</dependency>
</dependencies>
That’s it. Note the scope can be declared as runtime if you don’t need to compile against Spring APIs, which is typically the case for basic dependency injection use cases.
The example above works with the Maven Central repository. To use the Spring Maven repository (e.g. for milestones or developer snapshots), you need to specify the repository location in your Maven configuration. For full releases:
就是这样。 注意,如果不需要针对Spring API
进行编译,范围(scope
)可以声明为运行时(runtime
),这通常是基本依赖注入使用用例。
上面的示例使用Maven Central
存储库。 要使用Spring Maven
存储库(例如,用于里程碑或开发人员快照),你需要在Maven
配置中指定存储库位置。 完整版本:
<repositories>
<repository>
<id>io.spring.repo.maven.release</id>
<url>http://repo.spring.io/release/</url>
<snapshots><enabled>false</enabled></snapshots>
</repository>
</repositories>
里程碑:
<repositories>
<repository>
<id>io.spring.repo.maven.milestone</id>
<url>http://repo.spring.io/milestone/</url>
<snapshots><enabled>false</enabled></snapshots>
</repository>
</repositories>
And for snapshots: 以及快照:
<repositories>
<repository>
<id>io.spring.repo.maven.snapshot</id>
<url>http://repo.spring.io/snapshot/</url>
<snapshots><enabled>true</enabled></snapshots>
</repository>
</repositories>
Maven "Bill Of Materials" Dependency
It is possible to accidentally mix different versions of Spring JARs when using Maven. For example, you may find that a third-party library, or another Spring project, pulls in a transitive dependency to an older release. If you forget to explicitly declare a direct dependency yourself, all sorts of unexpected issues can arise.
To overcome such problems Maven supports the concept of a "bill of materials" (BOM) dependency. You can import the spring-framework-bom
in your dependencyManagement
section to ensure that all spring dependencies (both direct and transitive) are at the same version.
在使用Maven
时,可能会意外混合不同版本的Spring JAR
。 例如,你可能会发现第三方库或另一个Spring
项目将传递依赖项拉入旧版本。 如果你忘记自己显式声明一个直接依赖,可能会出现各种意想不到的问题。
为了克服这种问题,Maven
支持“物料清单”(BOM
)依赖的概念。 你可以在dependencyManagement
部分中导入spring-framework-bom
,以确保所有spring
依赖项(直接和可传递)具有相同的版本。
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>5.0.0.M3</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
An added benefit of using the BOM is that you no longer need to specify the <version>
attribute when depending on Spring Framework artifacts:
使用 BOM
后,当依赖 Spring Framework
组件后,无需再指定<version>
属性
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
</dependency>
<dependencies>
Gradle Dependency Management 通过Gradle 做依赖管理
To use the Spring repository with the Gradle build system, include the appropriate URL in the repositories
section:
要将Spring
存储库与Gradle
构建系统一起使用,请在repositories
部分中包含相应的URL
:
repositories {
mavenCentral()
// and optionally...
maven { url "http://repo.spring.io/release" }
}
You can change the repositories
URL from /release
to /milestone
or /snapshot
as appropriate. Once a repository has been configured, you can declare dependencies in the usual Gradle way:
你可以根据需要将 repositories
中URL从/ release
更改为/ milestone
或/ snapshot
。 一旦配置了 repositories
,就可以按照通常的Gradle
方式声明依赖关系:
dependencies {
compile("org.springframework:spring-context:5.0.0.M3")
testCompile("org.springframework:spring-test:5.0.0.M3")
}
Ivy Dependency Management Ivy 依赖管理
If you prefer to use Ivy to manage dependencies then there are similar configuration options.
To configure Ivy to point to the Spring repository add the following resolver to your ivysettings.xml
:
如果你喜欢使用Ivy来管理依赖,那么有类似的配置选项。
要配置Ivy
指向Spring
存储库,请将以下解析器添加到你的ivysettings.xml
:
<resolvers>
<ibiblio name="io.spring.repo.maven.release"
m2compatible="true"
root="http://repo.spring.io/release/"/>
</resolvers>
You can change the root
URL from /release/
to /milestone/
or /snapshot/
as appropriate.
Once configured, you can add dependencies in the usual way. For example (in ivy.xml
):
你可以根据需要将root
URL从/ release /
更改为/ milestone /
或/ snapshot /
。
配置后,你可以按照通常的方式添加依赖关系。 例如(在ivy.xml
中):
<dependency org="org.springframework"
name="spring-core" rev="5.0.0.M3" conf="compile->runtime"/>
Distribution Zip Files
Although using a build system that supports dependency management is the recommended way to obtain the Spring Framework, it is still possible to download a distribution zip file.
Distribution zips are published to the Spring Maven Repository (this is just for our convenience, you don’t need Maven or any other build system in order to download them).
To download a distribution zip open a web browser to http://repo.spring.io/release/org/springframework/spring and select the appropriate subfolder for the version that you want. Distribution files end -dist.zip
, for example spring-framework-{spring-version}-RELEASE-dist.zip. Distributions are also published for milestones and snapshots.
尽管使用支持依赖性管理的构建系统是获取Spring Framework
的推荐方式,但仍然可以下载分发zip
文件。
分发zip
是发布到Spring Maven
仓库(这只是为了我们的方便,你不需要Maven
或任何其他构建系统为了下载它们)。
要下载分发zip
,请打开Web浏览器到http://repo.spring.io/release/org/springframework/spring,然后为所需的版本选择适当的子文件夹。 分发文件结尾是 -dist.zip
,例如spring-framework- {spring-version} -RELEASE-dist.zip
。 还分发了里程碑和快照的分发。
2.3.2 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 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.
日志记录是Spring
的一个非常重要的依赖,因为a)
它是唯一的强制性的外部依赖,b)
每个人都喜欢从他们使用的工具看到一些输出,和c)
Spring集成了许多其他工具,日志依赖性的选择。应用程序开发人员的目标之一通常是在整个应用程序的中心位置配置统一日志记录,包括所有外部组件。这就更加困难,因为它可能已经有太多选择的日志框架。
Spring
中的强制性日志依赖性是Jakarta Commons Logging API(JCL)
。我们编译JCL
,我们也使JCL Log
对象对于扩展Spring
框架的类可见。对于用户来说,所有版本的Spring都使用相同的日志库很重要:迁移很容易,因为即使使用扩展Spring
的应用程序也保持向后兼容性。我们这样做的方式是使Spring中的一个模块显式地依赖commons-logging(JCL的规范实现),然后使所有其他模块在编译时依赖它。如果你使用Maven为例,并想知道你在哪里选择对commons-logging
的依赖,那么它是从Spring
,特别是从中央模块称为spring-core
(关于此处,理解就好,翻译的不到位
)。
关于commons-logging
的好处是,你不需要任何其他东西来就能让你的应用程序工作。它有一个运行时发现算法,该算法在众所周知的classpath
路径下寻找其他日志框架,并使用它认为是合适的(或者你可以告诉它,如果你需要)。如果没有其他可用的,你可以从JDK
(java.util.logging
或简称JUL
)获得漂亮的查看日志。你应该会发现,你的Spring
应用程序在大多数情况下可以很好地工作和记录到控制台,这很重要。
Not Using Commons Logging 不使用 Commons Logging
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.
There are basically two ways to switch off commons-logging
:
- Exclude the dependency from the
spring-core
module (as it is the only module that explicitly depends oncommons-logging
) - 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:
不幸的是,公共日志中的运行时发现算法虽然对于终端用户方便,但是是有问题的。 如果我们可以时光倒流并启动Spring
作为一个新项目,它将使用不同的日志依赖关系。 第一个选择可能是用于Java
的简单日志外观(SLF4J),它也被许多其他工具用于Spring
在其应用程序中使用。
基本上有两种方法关闭commons-logging
:
1.从spring-core
模块中排除依赖性(因为它是唯一显式依赖commons-logging
的模块)
2.依赖于一个特殊的commons-logging
依赖,用一个空jar替换库(更多细节可以在 SLF4J FAQ中找到)
要排除commons-logging
,请将以下内容添加到你的dependencyManagement
部分:
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>5.0.0.M3</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
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.
现在这个应用程序运行不了,因为没有在类路径上实现JCL API
,所以要解决它需要提供一个新的。 在下一节中,我们将向你展示如何使用SLF4J
提供JCL
的替代实现。
Using SLF4J 使用 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
更高效,因为它使用编译时绑定,而不是其集成的其他日志框架的运行时发现。这也意味着你必须更明确地了解你想在运行时发生什么,并声明它或相应地配置它。 SLF4J
提供了对许多常见日志框架的绑定,因此你通常可以选择一个已经使用的绑定,并绑定到配置和管理。
SLF4J
提供对许多常见日志框架(包括JCL
)的绑定,并且它也做了反向工作:充当其他日志框架与其自身之间的桥梁。因此,要在Spring中使用SLF4J
,需要使用SLF4J-JCL
桥替换commons-logging
依赖关系。一旦你这样做,那么来自Spring
内部的日志调用将被转换为对SLF4J API
的日志调用,因此如果应用程序中的其他库使用该API,那么你有一个地方可以配置和管理日志记录。
常见的选择可能是将Spring
桥接到SLF4J
,然后提供从SLF4J
到Log4J
的显式绑定。你需要提供4个依赖(并排除现有的commons-logging
):桥梁,SLF4J API
,绑定到Log4J
和Log4J
实现本身。在Maven
,你会这样做
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>5.0.0.M3</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.
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-logging
表现的更加的好,特别是当它运行在在一个严格的容器中像OSGi
平台。 据称,还有一个性能优势,因为绑定是在编译时,而不是运行时。
SLF4J
用户中更常见的选择是使用较少的步骤和生成较少的依赖关系,它是直接绑定到Logback
。 这消除了额外的绑定步骤,因为Logback
直接实现SLF4J
,所以你只需要依赖于两个不是四个库(jcl-over-slf4j
和logback
)。 如果你这样做,你可能还需要从其他外部依赖(不是Spring
)中排除slf4j-api
依赖,因为你只需要在类路径上有一个版本的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:
许多人使用Log4j作为日志框架用于配置和管理目的。 它是高效的和成熟的,事实上,这是我们在运行时使用时,我们构建和测试Spring
。 Spring
还提供了一些用于配置和初始化Log4j
的实用程序,所以它在一些模块中对Log4j
有一个可选的编译时依赖。
要使Log4j
使用默认的JCL
依赖(commons-logging
),所有你需要做的是将Log4j
放在类路径上,并为它提供一个配置文件(在类路径的根目录下的log4j.properties
或log4j.xml
)。 所以对于Maven
用户,这是你的依赖性声明:
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>5.0.0.M3</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.14</version>
</dependency>
</dependencies>
And here’s a sample log4j.properties for logging to the console:
下面是一个简单的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
Runtime Containers with Native JCL
Many people run their Spring applications in a container that itself provides an implementation of JCL. IBM Websphere Application Server (WAS) is the archetype. This often causes problems, and unfortunately there is no silver bullet solution; simply excluding commons-logging
from your application is not enough in most situations.
To be clear about this: the problems reported are usually not with JCL per se, or even with commons-logging
: rather they are to do with binding commons-logging
to another framework (often Log4J). This can fail because commons-logging
changed the way they do the runtime discovery in between the older versions (1.0) found in some containers and the modern versions that most people use now (1.1). Spring does not use any unusual parts of the JCL API, so nothing breaks there, but as soon as Spring or your application tries to do any logging you can find that the bindings to Log4J are not working.
In such cases with WAS the easiest thing to do is to invert the class loader hierarchy (IBM calls it "parent last") so that the application controls the JCL dependency, not the container. That option isn’t always open, but there are plenty of other suggestions in the public domain for alternative approaches, and your mileage may vary depending on the exact version and feature set of the container.
许多人在一个容器中运行他们的Spring
应用程序,该容器本身提供了JCL
的实现。 IBM Websphere
应用服务器(WAS
)就是一个例子。这常常导致问题,不幸的是没有一个一劳永逸解决方案;在大多数情况下,只是从你的应用程序中排除commons-logging
是不够的。
要明确这一点:报告的问题通常不是JCL
本身,或者甚至与commons-logging
:而是他们要绑定到另一个框架(通常Log4J)的公共日志。这可能会失败,因为commons-logging
改变了在一些容器中发现的旧版本(1.0)和大多数人现在使用的现代版本(1.1)之间执行运行时发现的方式。 Spring
不使用JCL API
的任何不常见的模块,所以没有什么问题出现,但一旦Spring
或你的应用程序试图做任何日志记录,你可以发现绑定的Log4J
不工作了。
在这种情况下,使用WAS
,最容易做的事情是反转类加载器层次结构(IBM称之为“父最后一个”),以便应用程序控制JCL
依赖关系,而不是容器。该选项并不总是开放的,但在公共领域有许多其他建议替代方法,你的里程可能会根据容器的确切版本和功能集而有所不同。
觉得看着别扭的可以查看本人Gitbook :https://muyinchen.gitbooks.io/spring-framework-5-0-0-m3/content/