轉 spring官方文檔中文版


 

spring官方文檔:http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/

一、Spring框架概述

Spring框架是一個輕量級的解決方案,可以一站式地構建企業級應用。Spring是模塊化的,所以可以只使用其中需要的部分。可以在任何web框架上使用控制反轉(IoC),也可以只使用Hibernate集成代碼JDBC抽象層。它支持聲明式事務管理、通過RMI或web服務實現遠程訪問,並可以使用多種方式持久化數據。它提供了功能全面的MVC框架,可以透明地集成AOP到軟件中。

Spring被設計為非侵入式的,這意味着你的域邏輯代碼通常不會依賴於框架本身。在集成層(比如數據訪問層),會存在一些依賴同時依賴於數據訪問技術和Spring,但是這些依賴可以很容易地從代碼庫中分離出來。

本文檔是Spring框架的參考指南,如果你有任何請求、評論或問題,請給我們發郵件,關於框架本身的問題將在StackOverflow上討論(見https://spring.io.questions)。

1. Spring入門

這篇參考指南提供了Spring框架的詳細信息,包括了對所有功能的全面理解,同時也包括一些重要概念的背景(比如,依賴注入)。

如果你才開始使用Spring,可以通過創建一個基於Spring Boot的應用開始使用Spring框架。Spring Boot提供了一種快速創建Spring應用的方式,它基於Spring框架,支持約定優於配置,使你可以盡快啟動並運行。

可以使用start.spring.io或遵循入門指南(比如,構建RESTful web應用入門)生成一個基本的項目。除了易於理解,這些指南聚集於一個個任務,它們大部分都是基於Spring Boot的,同時也包含了Spring包下的其它項目,以便你可以考慮何時使用它們解決特定的問題。

2. Spring框架簡介

Spring框架是基於Java平台的,它為開發Java應用提供了全方位的基礎設施支持,並且它很好地處理了這些基礎設施,所以你只需要關注你的應用本身即可。

Spring可以使用POJO(普通的Java對象,plain old Java objects)創建應用,並且可以將企業服務非侵入式地應用到POJO。這項功能適用於Java SE編程模型以及全部或部分的Java EE

那么,做為開發者可以從Spring獲得哪些好處呢?

  • 不用關心事務API就可以執行數據庫事務;
  • 不用關心遠程API就可以使用遠程操作;
  • 不用關心JMX API就可以進行管理操作;
  • 不用關心JMS API就可以進行消息處理。

譯者注:①JMX,Java Management eXtension,Java管理擴展,是一個為應用程序、設備、系統等植入管理功能的框架。JMX可以跨越一系列異構操作系統平台、系統體系結構和網絡傳輸協議,靈活的開發無縫集成的系統、網絡和服務管理應用。②JMS,Java Message Service,Java消息服務,是Java平台上有關面向消息中間件(MOM)的技術規范,它便於消息系統中的Java應用程序進行消息交換,並且通過提供標准的產生、發送、接收消息的接口簡化企業應用的開發。

2.1 依賴注入(DI)和控制反轉(IoC)

一個Java應用程序,從受限制的嵌入式應用到n層的服務端應用,典型地是由相互合作的對象組成的,因此,一個應用程序中的對象是相互依賴的。

Java平台雖然提供了豐富的應用開發功能,但是它並沒有把這些基礎構建模塊組織成連續的整體,而是把這項任務留給了架構師和開發者。你可以使用設計模式,比如工廠模式、抽象工廠模式、創建者模式、裝飾者模式以及服務定位器模式等,來構建各種各樣的類和對象實例,從而組成整個應用程序。這些設計模式是很簡單的,關鍵在於它們根據最佳實踐起了很好的名字,它們的名字可以很好地描述它們是干什么的、用於什么地方、解決什么問題,等等。這些設計模式都是最佳實踐的結晶,所以你應該在你的應用程序中使用它們。

Spring的控制反轉解決了上述問題,它提供了一種正式的解決方案,你可以把不相干組件組合在一起,從而組成一個完整的可以使用的應用。Spring根據設計模式編碼出了非常優秀的代碼,所以可以直接集成到自己的應用中。因此,大量的組織機構都使用Spring來保證應用程序的健壯性和可維護性。

背景

2004年Martin Fowler在他的網站上提出了關於控制反轉(IoC,Inversion of Control)的問題,“The question is, what aspect of control are [they] inverting?”,后來,他又建議重新命名這項原則,使其可以自我解釋,從而提出了依賴注入(DI,Dependency Injection)的概念。

2.2 模塊

Spring大約包含了20個模塊,這些模塊組成了核心容器(Core Container)、數據訪問/集成(Data Access/Integration)、Web、AOP(面向切面編程,Aspect Oriented Programming)、Instrumentation、消息處理(Messaging)和測試(Test),如下圖:

圖 2.1. Spring框架概述 
spring框架概述

下面列出了每項功能對應的模塊及其主題,它們都有人性的名字(artifact name),這些名字與依賴管理工具中的 artifact id 是相互對應的。

2.2.1 核心容器(Core Container)

核心容器包括spring-corespring-beansspring-contextspring-context-supportspring-expression(SpEL,Spring表達式語言,Spring Expression Language)等模塊。

spring-corespring-beans模塊是Spring框架的基礎,包括控制反轉和依賴注入等功能。BeanFactory是工廠模式的微妙實現,它移除了編碼式單例的需要,並且可以把配置和依賴從實際編碼邏輯中解耦。

Contextspring-context)模塊是在Core和Bean模塊的基礎上建立起來的,它以一種類似於JNDI注冊的方式訪問對象。Context模塊繼承自Bean模塊,並且添加了國際化(比如,使用資源束)、事件傳播、資源加載和透明地創建上下文(比如,通過Servelet容器)等功能。Context模塊也支持Java EE的功能,比如EJB、JMX和遠程調用等。ApplicationContext接口是Context模塊的焦點。spring-context-support提供了對第三方庫集成到Spring上下文的支持,比如緩存(EhCache, Guava, JCache)、郵件(JavaMail)、調度(CommonJ, Quartz)、模板引擎(FreeMarker, JasperReports, Velocity)等。

spring-expression模塊提供了強大的表達式語言用於在運行時查詢和操作對象圖。它是JSP2.1規范中定義的統一表達式語言的擴展,支持set和get屬性值、屬性賦值、方法調用、訪問數組集合及索引的內容、邏輯算術運算、命名變量、通過名字從Spring IoC容器檢索對象,還支持列表的投影、選擇以及聚合等。

2.2.2 AOP和檢測(Instrumentation)

spring-aop模塊提供了面向切面編程(AOP)的實現,可以定義諸如方法攔截器和切入點等,從而使實現功能的代碼徹底的解耦出來。使用源碼級的元數據,可以用類似於.Net屬性的方式合並行為信息到代碼中。

spring-aspects模塊提供了對AspectJ的集成。

spring-instrument模塊提供了對檢測類的支持和用於特定的應用服務器的類加載器的實現。spring-instrument-tomcat模塊包含了用於tomcat的Spring檢測代理。

2.2.3 消息處理(messaging)

Spring 4 包含的spring-messaging模塊是從Spring集成項目的關鍵抽象中提取出來的,這些項目包括MessageMessageChannelMessageHandler和其它服務於消息處理的項目。這個模塊也包含一系列的注解用於映射消息到方法,這類似於Spring MVC基於編碼模型的注解。

2.2.4 數據訪問與集成

數據訪問與集成層包含JDBC、ORM、OXM、JMS和事務模塊。 
(譯者注:JDBC=Java Data Base Connectivity,ORM=Object Relational Mapping,OXM=Object XML Mapping,JMS=Java Message Service)

spring-jdbc模塊提供了JDBC抽象層,它消除了冗長的JDBC編碼和對數據庫供應商特定錯誤代碼的解析。

spring-tx模塊支持編程式事務和聲明式事務,可用於實現了特定接口的類和所有的POJO對象。 
(譯者注:編程式事務需要自己寫beginTransaction()、commit()、rollback()等事務管理方法,聲明式事務是通過注解或配置由spring自動處理,編程式事務粒度更細)

spring-orm模塊提供了對流行的對象關系映射API的集成,包括JPAJDOHibernate等。通過此模塊可以讓這些ORM框架和spring的其它功能整合,比如前面提及的事務管理。

spring-oxm模塊提供了對OXM實現的支持,比如JAXB、Castor、XML Beans、JiBX、XStream等。

spring-jms模塊包含生產(produce)和消費(consume)消息的功能。從Spring 4.1開始,集成了spring-messaging模塊。

2.2.5 Web

Web層包括spring-webspring-webmvcspring-websocketspring-webmvc-portlet等模塊。

spring-web模塊提供面向web的基本功能和面向web的應用上下文,比如多部分(multipart)文件上傳功能、使用Servlet監聽器初始化IoC容器等。它還包括HTTP客戶端以及Spring遠程調用中與web相關的部分。

spring-webmvc模塊(即Web-Servlet模塊)為web應用提供了模型視圖控制(MVC)和REST Web服務的實現。Spring的MVC框架可以使領域模型代碼和web表單完全地分離,且可以與Spring框架的其它所有功能進行集成。

spring-webmvc-portlet模塊(即Web-Portlet模塊)提供了用於Portlet環境的MVC實現,並反映了spring-webmvc模塊的功能。

2.2.6 Test

spring-test模塊通過JUnit和TestNG組件支持單元測試集成測試。它提供了一致性地加載緩存Spring上下文,也提供了用於單獨測試代碼的模擬對象(mock object)。

2.3 使用場景

前面提及的構建模塊使得Spring在很多場景成為一種合理的選擇,不管是資源受限的嵌入式應用還是使用了事務管理和web集成框架的成熟的企業級應用。

圖2.2. 典型的成熟的Spring web應用程序 
典型的成熟的Spring web應用程序

Spring的聲明式事務管理可以使web應用完成事務化,就像使用EJB容器管理的事務。所有客制的業務邏輯都可以使用簡單的POJO實現,並用Spring的IoC容器進行管理。另外,還包括發郵件和驗證功能,其中驗證功能是從web層分離的,由你決定何處執行驗證。Spring的ORM可以集成JPA、hibernate和JDO等,比如,使用Hibernate時,可以繼續使用已存在的映射文件和標准的Hibernate的SessionFactory配置。表單控制器無縫地把web層和領域模型集成在一起,移除了ActionForms和其它把HTTP參數轉換成領域模型的類。

圖2.3. 使用第三方web框架的Spring中間件 
使用第三方web框架的Spring中間件

一些場景可能不允許你完全切換到另一個框架。然而,Spring框架不強制你使用它所有的東西,它不是非此即彼(all-or-nothing)的解決方案。前端使用Struts、Tapestry、JSF或別的UI框架可以和Spring中間件集成,從而使用Spring的事務管理功能。僅僅只需要使用ApplicationContext連接業務邏輯,並使用WebApplicationContext集成web層即可。

圖2.4. 遠程調用使用場景 
遠程調用使用場景

當需要通過web服務訪問現有代碼時,可以使用Spring的Hessian-Burlap-Rmi-或者JaxRpcProxyFactory類,遠程訪問現有的應用並非難事。

圖2.5. EJB-包裝現有的POJO 
EJB-包裝現有的POJO

Spring框架也為EJB提供了訪問抽象層,可以重新使用現有的POJO並把它們包裝到無狀態的會話bean中,以使其用於可擴展的安全的web應用中。

2.3.1 依賴管理和命名約定

依賴管理和依賴注入是兩碼事。為了讓應用程序擁有這些Spring的非常棒的功能(如依賴注入),需要導入所需的全部jar包,並在運行時放在classpath下,有可能的話編譯期也應該放在classpath下。這些依賴並不是被注入的虛擬組件,而是文件系統上典型的物理資源。依賴管理的處理過程涉及到定位這些資源、存儲並添加它們到classpath下。依賴可能是直接的(比如運行時依賴於Spring),也可能是間接的(比如依賴於commons-dbcpcommons-dbcp又依賴於commons-pool)。間接的依賴又被稱作“傳遞”,它們是最難識別和管理的。

如果准備使用Spring,則需要拷貝一份所需模塊的Spring的jar包。為了便於使用,Spring被打包成一系列的模塊以盡可能地減少依賴,比如,如果不是在寫一個web應用,那就沒必要引入spring-web模塊。這篇文檔中涉及到的Spring模塊,我們使用spring-*spring-*.jar的命名約定,其中,*代表模塊的短名字(比如,spring-corespring-webmvcspring-jms等等)。實際使用的jar包正常情況下都是帶有版本號的(比如,spring-core-4.3.0.RELEASE.jar)。

每個版本的Spring都會在以下地方發布artifact:

  • Maven中央倉庫,默認的Maven查詢倉庫,並且不需要特殊的配置就可以使用。許多Spring依賴的公共庫也可以從Maven中央倉庫獲得,並且大部分的Spring社區也使用Maven作為依賴管理工具,所以很方便。Maven中的jar包命名格式為spring-*-<version>.jar,其groupId是org.springframework。
  • 特別為托管Spring的公共的Maven倉庫。除了最終的GA版本,這個倉庫也托管了開發的快照版本和里程碑版本。jar包和Maven中央倉庫中的命名一致,所以這也是一個獲取Spring的開發版本的有用地方,可以和Maven中央倉庫中部署的其它庫一起使用。這個倉庫也包含了捆綁了所有Spring jar包的發行版的zip文件,以便於下載。

因此,首先要做的事就是決定如何管理依賴關系,我們一般推薦使用自動管理的系統,比如Maven、Gradle或Ivy,當然你也可以手動下載所有的jar包。

下面列出了Spring的artifact,每個模塊更完整的描述,參考 2.2 模塊 章節。

表2.1. Spring框架的artifact

groupId artifactId 描述
org.springframework spring-aop 基於代理的AOP
org.springframework spring-aspects 基於切面的AspectJ
org.springframework spring-beans bean支持,包括Groovy
org.springframework spring-context 運行時上下文,包括調度和遠程調用抽象
org.springframework spring-context-support 包含用於集成第三方庫到Spring上下文的類
org.springframework spring-core 核心庫,被許多其它模塊使用
org.springframework spring-expression Spring表達式語言
org.springframework spring-instrument JVM引導的檢測代理
org.springframework spring-instrument-tomcat tomcat的檢測代理
org.springframework spring-jdbc JDBC支持包,包括對數據源設置和JDBC訪問支持
org.springframework spring-jms JMS支持包,包括發送和接收JMS消息的幫助類
org.springframework spring-messaging 消息處理的架構和協議
org.springframework spring-orm 對象關系映射,包括對JPA和Hibernate支持
org.springframework spring-oxm 對象XML映射
org.springframework spring-test 單元測試和集成測試組件
org.springframework spring-tx 事務基礎,包括對DAO的支持及JCA的集成
org.springframework spring-web web支持包,包括客戶端及web遠程調用
org.springframework spring-webmvc REST web服務及web應用的MVC實現
org.springframework spring-webmvc-portlet 用於Portlet環境的MVC實現
org.springframework spring-websocket WebSocket和SockJS實現,包括對STOMP的支持
Spring的依賴和被依賴

Spring對大部分企業和其它外部工具提供了集成和支持,把強制性的外部依賴降到了最低,這樣就不需要為了簡單地使用Spring而去尋找和下載大量的jar包了。基本的依賴注入只有一個強制性的外部依賴,那就是日志管理(參考下面關於日志管理選項的詳細描述)。

下面列出依賴於Spring的應用的基本配置步驟,首先使用Maven,然后Gradle,最后Ivy。在所有案例中,如果有什么不清楚的地方,參考所用的依賴管理系統的文檔或查看一些范例代碼——Spring構建時本身使用Gradle管理依賴,所以我們的范例大部分使用Gradle或Maven。

Maven依賴關系管理

如果使用Maven作為依賴管理工具,甚至不需要明確地提供日志管理的依賴。例如,創建應用上下文並使用依賴注入配置應用程序,Maven的依賴關系看起來像下面一樣:

<dependencies>     <dependency>         <groupId>org.springframework</groupId>         <artifactId>spring-context</artifactId>         <version>4.3.0.RELEASE</version>         <scope>runtime</scope>     </dependency> </dependencies>
  
  
 
 
         
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

就這樣,注意如果不需要編譯Spring API,可以把scope聲明為runtime,這是依賴注入使用的典型案例。

上面的示例使用Maven中央倉庫,如果使用Spring的Maven倉庫(例如,里程碑或開發快照),需要在Maven配置中指定倉庫位置。

release版本:

<repositories>     <repository>         <id>io.spring.repo.maven.release</id>         <url>http://repo.spring.io/release/</url>         <snapshots><enabled>false</enabled></snapshots>     </repository> </repositories>
  
  
 
 
         
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

里程碑版本:

<repositories>     <repository>         <id>io.spring.repo.maven.milestone</id>         <url>http://repo.spring.io/milestone/</url>         <snapshots><enabled>false</enabled></snapshots>     </repository> </repositories>
  
  
 
 
         
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

快照版本:

<repositories>     <repository>         <id>io.spring.repo.maven.snapshot</id>         <url>http://repo.spring.io/snapshot/</url>         <snapshots><enabled>true</enabled></snapshots>     </repository> </repositories>
  
  
 
 
         
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
Maven的“物料清單式”依賴

使用Maven時可能會不小心混合了Spring不同版本的jar包。例如,你可能會發現第三方庫或其它的Spring項目存在舊版本的傳遞依賴。如果沒有明確地聲明直接依賴,各種各樣不可預料的情況將會出現。

為了解決這個問題,Maven提出了“物料清單式”(BOM)依賴的概念。可以在dependencyManagement部分導入spring-framework-bom以保證所有的Spring依賴(不管直接還是傳遞依賴)使用相同的版本。

<dependencyManagement>     <dependencies>         <dependency>             <groupId>org.springframework</groupId>             <artifactId>spring-framework-bom</artifactId>             <version>4.3.0.RELEASE</version>             <type>pom</type>             <scope>import</scope>         </dependency>     </dependencies> </dependencyManagement>
  
  
 
 
         
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

使用BOM的另外一個好處是不再需要指定<version>屬性了:

<dependencies>     <dependency>         <groupId>org.springframework</groupId>         <artifactId>spring-context</artifactId>     </dependency>     <dependency>         <groupId>org.springframework</groupId>         <artifactId>spring-web</artifactId>     </dependency> <dependencies>
  
  
 
 
         
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
Gradle依賴關系管理

為了在Gradle構建系統中使用Spring倉庫,需要在repositories部分包含合適的URL:

repositories {     mavenCentral()     // and optionally...     maven { url "http://repo.spring.io/release" } }
  
  
 
 
         
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5

可以酌情把repositories URL中的/release修改為/milestone/snapshot。一旦倉庫配置好了,就可以按Gradle的方式聲明依賴關系了。

dependencies {     compile("org.springframework:spring-context:4.3.0.RELEASE")     testCompile("org.springframework:spring-test:4.3.0.RELEASE") }
  
  
 
 
         
  • 1
  • 2
  • 3
  • 4
  • 1
  • 2
  • 3
  • 4
Ivy依賴關系管理

使用Ivy管理依賴關系有相似的配置選項。

ivysettings.xml中添加resolver配置使Ivy指向Spring倉庫:

<resolvers>     <ibiblio name="io.spring.repo.maven.release" m2compatible="true" root="http://repo.spring.io/release/"/> </resolvers>
  
  
 
 
         
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5

可以酌情把root URL中的/release修改為/milestone/snapshot。一旦配置好了,就可以按照慣例添加依賴了(在ivy.xml中):

<dependency org="org.springframework" name="spring-core" rev="4.3.0.RELEASE" conf="compile->runtime"/>
  
  
 
 
         
  • 1
  • 2
  • 1
  • 2
發行版的Zip文件

雖然使用支持依賴管理的構建系統是獲取Spring框架的推薦方法,但是也支持通過下載Spring的發行版zip文件獲取。

發行版zip文件發布在了Sprng的Maven倉庫上(這只是為了方便,不需要額外的Maven或其它構建系統去下載它們)。

瀏覽器中打開http://repo.spring.io/release/org/springframework/spring,並選擇合適版本的子目錄,就可以下載發行版的zip文件了。發行文件以-dist.zip結尾,例如,spring-framework-{spring-version}-RELEASE-dist.zip。發行文件也包含里程碑版本和快照版本。

2.3.2 日志管理

對於Spring來說日志管理是非常重要的依賴關系,因為a)它是唯一的強制性外部依賴,b)每個人都喜歡從他們使用的工具看到一些輸出,c)Spring集成了許多其它工具,它們都選擇了日志管理的依賴。應用程序開發者的目標之一通常是在整個應用程序(包括所有的外部組件)的中心位置統一配置日志管理,這是非常困難的因為現在有很多日志管理的框架可供選擇。

Spring中強制的日志管理依賴是Jakarta Commons Logging API(JCL)。我們編譯了JCL,並使JCL的Log對象對繼承了Spring框架的類可見。對用戶來說所有版本的Spring使用相同的日志管理庫很重要:遷移很簡單因為Spring保存了向后兼容,即使對於擴展了Spring的應用也能向后兼容。我們是怎么做到的呢?我們讓Spring的一個模塊明確地依賴於commons-logging(JCL的典型實現),然后讓所有其它模塊都在編譯期依賴於這個模塊。例如,使用Maven,你想知道哪里依賴了commons-logging,其實是Spring確切地說是其核心模塊spring-core依賴了。

commons-logging的優點是不需要其它任何東西就可以使應用程序運轉起來。它擁有一個運行時發現算法用於在classpath中尋找其它日志管理框架並且適當地選擇一個使用(或者告訴它使用哪個)。如果不需要其它的功能了,你就可以從JDK(java.util.logging或JUL)得到一份看起來很漂亮的日志了。你會發現大多數情況下你的Spring應用程序工作得很好且日志很好地輸出到了控制台,這很重要。

不使用Commons Logging

不幸的是,commons-logging的運行時發現算法雖然對於終端用戶很方便,但存在一定的問題。如果我們能讓時光倒流,重新開始Spring項目,我們會使用不同的日志管理依賴。首要選擇可能是Simple Logging Facade for Java(SLF4J),它也被用於了其它一些使用Spring的工具中。

有兩種方式關掉commons-logging

  1. spring-core模塊中去除對commons-logging的依賴(因為這是唯一明確依賴於commons-logging的地方)
  2. 依賴於一個特定的commons-logging且把其jar包換成一個空jar包(具體做法參考SLF4J FAQ

如下,在dependencyManagement中添加部分代碼就可以排除掉commons-logging了:

<dependencies>     <dependency>         <groupId>org.springframework</groupId>         <artifactId>spring-core</artifactId>         <version>4.3.0.RELEASE</version>         <exclusions>             <exclusion>                 <groupId>commons-logging</groupId>                 <artifactId>commons-logging</artifactId>             </exclusion>         </exclusions>     </dependency> </dependencies>
  
  
 
 
         
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13

現在這個應用可能是殘缺的,因為在classpath上沒有JCL API的實現,所以需要提供一個新的去修復它。下個章節我們將以SLF4J為例子為JCL提供一個替代實現。

使用SLF4J

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>4.3.0.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>
  
  
 
 
         
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33

似乎這么多依賴僅僅用於獲取日志。在類加載器問題上,它應該表現得比commons-logging更好,尤其是在像OSGi這樣嚴格的容器中。而且,它也有性能優勢因為綁定發生在編譯期而非運行時。

對於SLF4J用戶更普遍的選擇是直接綁定Logback,這需要更少的步驟,生成更少的依賴。這樣移除了額外的綁定因為Logback直接實現了SLF4J,所以僅僅需要兩個庫即可而不用四個庫(jcl-over-slf4jlogback)。這樣做的話還需要把slf4j-api依賴從其它外部依賴(不是Spring)中排除掉,因為在classpath下僅僅需要一個版本的API。

使用Log4J

許多人使用Log4J作為日志管理框架。它是高效和完善的,實際上在構建和測試Spring的時候我們運行時就是使用它。Spring也提供了一些工具用於配置和初始化Log4J,所以某些模塊在編譯期可以選擇依賴於Log4J。

為了使Log4J代替默認的JCL依賴(commons-logging),僅僅提供一個配置文件(log4j.propertieslog4j.xml)放在classpath根目錄下即可。Maven中的配置如下:

<dependencies>     <dependency>         <groupId>org.springframework</groupId>         <artifactId>spring-core</artifactId>         <version>4.3.0.RELEASE</version>     </dependency>     <dependency>         <groupId>log4j</groupId>         <artifactId>log4j</artifactId>         <version>1.2.14</version>     </dependency> </dependencies>
  
  
 
 
         
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12

下面是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
  
  
 
 
         
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
帶有本地JCL的運行時容器

許多人在一個容器中運行Spring應用程序,而這個容器本身又提供了JCL的實現。IBM的Websphere Application Server(WAS)是一個原型。這經常引起一些問題,而且不幸的是沒有很好的解決方案,簡單地從應用中排除掉commons-logging在大部分情況下還不夠。

更清楚地描述:這個問題通常並不與JCL本身有關,甚至是commons-logging,而是他們綁定了commons-logging到另一個框架(通常是Log4J)。這會失敗是因為commons-logging改變了在舊版本(1.0)和新版本(1.1)中執行運行時發現算法的方式,其中,舊版本在一些容器中還在使用,新版本是現在大部分人使用的。Spring沒有使用JCL API的其它部分,所以不會有什么問題,但是一旦Spring或你的應用試圖記錄日志就會發現Log4J不能工作了。(譯者注:此處的意思是即使發生了上面的沖突,Spring也不會去檢查,直接運行的時候需要打印日志的時候才會出錯)

在WAS這個案例中,最簡單的方法就是倒置類加載器的繼承(IBM稱作“parent last”,即把父類放后面),以便應用程序而不是容器控制JCL依賴。這種選擇並不總是管用的,在公共領域有很多其它建議的替代方案,且你的里程可能會隨着確切的版本和容器的特性而改變。(譯者注:此處的意思是上面介紹的方法並不是唯一的,需要根據不同的版本和容器作出相應的方案)


后面太多了 這里記錄下 自己去看原文吧....

傳送門: http://blog.csdn.net/tangtong1/article/details/51326887

             http://blog.csdn.net/tangtong1/article/details/51960382




免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM