當前位置：首頁 > 编程语言 > java >内容正文

java

Spring - Java/J2EE Application Framework 应用框架第 3 章 Beans, BeanFactory和ApplicationContext

發布時間：2025/3/21 java 36 豆豆

生活随笔收集整理的這篇文章主要介紹了 Spring - Java/J2EE Application Framework 应用框架第 3 章 Beans, BeanFactory和ApplicationContext 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

第?3?章?Beans, BeanFactory和ApplicationContext

3.1.?簡介

在Spring中，兩個最基本最重要的包是?org.springframework.beans?和?org.springframework.context. 這兩個包中的代碼為Spring的反向控制?特性（也叫作依賴注射）提供了基礎。?BeanFactory提供了一種先進的配置機制來管理任何種類bean(對象)，這種配置機制考慮到任何一種可能的存儲方式。?ApplicationContext建立在BeanFactory之上，并增加了其他的功能,比如更容易同Spring AOP特性整合，消息資源處理（用于國際化），事件傳遞，以聲明的方式創建ApplicationContext，可選的父上下文和與應用層相關的上下文（比如WebApplicationContext），以及其他方面的增強。

簡而言之，BeanFactory提供了配置框架和基本的功能，而?ApplicationContext為它增加了更強的功能，這些功能中的一些或許更加接近J2EE并且圍繞企業級應用。一般來說，ApplicationContext是BeanFactory的完全超集，任何BeanFactory功能和行為的描述也同樣被認為適用于ApplicationContext

用戶有時不能確定BeanFactory和ApplicationContext中哪一個在特定場合下更適合。通常大部分在J2EE環境的應用中，最好選擇使用ApplicationContext，因為它不僅提供了BeanFactory所有的特性以及它自己附加的特性，而且還提供以聲明的方式使用一些功能，這通常是令人滿意的。BeanFactory主要是在非常關注內存使用的情況下（比如在一個每kb都要計算的applet中）使用，而且你也不需要用到ApplicationContext的所有特性。

這一章粗略地分為兩部分，第一部分包括對BeanFactory和ApplicationContext都適用的一些基本原則。第二部分包括僅僅適用于ApplicationContext的一些特性

3.2.?BeanFactory 和 BeanDefinitions - 基礎

3.2.1.?BeanFactory

BeanFactory實際上是實例化，配置和管理眾多bean的容器。這些bean通常會彼此合作，因而它們之間會產生依賴。 BeanFactory使用的配置數據可以反映這些依賴關系中（一些依賴可能不像配置數據一樣可見，而是在運行期作為bean之間程序交互的函數）。

一個BeanFactory可以用接口org.springframework.beans.factory.BeanFactory表示，這個接口有多個實現。最常使用的的簡單的eanFactory實現是org.springframework.beans.factory.xml.XmlBeanFactory。（這里提醒一下：ApplicationContext是BeanFactory的子類，所以大多數的用戶更喜歡使用ApplicationContext的XML形式）。

雖然大多數情況下，幾乎所有被BeanFactory管理的用戶代碼都不需要知道BeanFactory，但是BeanFactory還是以某種方式實例化。可以使用下面的代碼實例化BeanFactory：

InputStream is = new FileInputStream("beans.xml"); XmlBeanFactory factory = new XmlBeanFactory(is);

或者

ClassPathResource res = new ClassPathResource("beans.xml"); XmlBeanFactory factory = new XmlBeanFactory(res);

或者

ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext(new String[] {"applicationContext.xml", "applicationContext-part2.xml"}); // of course, an ApplicationContext is just a BeanFactory BeanFactory factory = (BeanFactory) appContext;

很多情況下，用戶代碼不需要實例化BeanFactory，因為Spring框架代碼會做這件事。例如，web層提供支持代碼，在J2EE web應用啟動過程中自動載入一個Spring ApplicationContext。這個聲明過程在這里描述：

編程操作BeanFactory將會在后面提到，下面部分將集中描述BeanFactory的配置.

一個最基本的BeanFactory配置由一個或多個它所管理的Bean定義組成。在一個XmlBeanFactory中，根節點beans中包含一個或多個bean元素。

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"><beans><bean id="..." class="...">...</bean><bean id="..." class="...">...</bean>...</beans>

3.2.2.?BeanDefinition

一個XmlBeanFactory中的Bean定義包括的內容有：

classname：這通常是bean的真正的實現類。但是如果一個bean使用一個靜態工廠方法所創建而不是被普通的構造函數創建，那么這實際上就是工廠類的classname
bean行為配置元素：它聲明這個bean在容器的行為方式（比如prototype或singleton，自動裝配模式，依賴檢查模式，初始化和析構方法）
構造函數的參數和新創建bean需要的屬性：舉一個例子，一個管理連接池的bean使用的連接數目（即可以指定為一個屬性，也可以作為一個構造函數參數），或者池的大小限制
和這個bean工作相關的其他bean：比如它的合作者（同樣可以作為屬性或者構造函數的參數）。這個也被叫做依賴。

上面列出的概念直接轉化為組成bean定義的一組元素。這些元素在下面的表格中列出，它們每一個都有更詳細的說明的鏈接。

表?3.1.?Bean定義的解釋

特性詳細說明

class	第?3.2.3?節 “bean的類”
id和name	第?3.2.4?節 “Bean的標志符 (id與name)”
singleton或prototype	第?3.2.5?節 “Singleton的使用與否”
構造函數參數	第?3.3.1?節 “設置bean的屬性和合作者”
bean的屬性	第?3.3.1?節 “設置bean的屬性和合作者”
自動裝配模式	第?3.3.5?節 “自動裝配協作對象”
依賴檢查模式	第?3.3.6?節 “依賴檢查”
初始化模式	第?3.4.1?節 “生命周期接口”
析構方法	第?3.4.1?節 “生命周期接口”

注意bean定義可以表示為真正的接口org.springframework.beans.factory.config.BeanDefinition以及它的各種子接口和實現。然而，絕大多數的用戶代碼不需要與BeanDefination直接接觸。

3.2.3.?bean的類

class屬性通常是強制性的（參考第?3.2.3.3?節 “通過實例工廠方法創建bean”和第?3.5?節 “子bean定義”），有兩種用法。在絕大多數情況下，BeanFactory直接調用bean的構造函數來"new"一個bean（相當于調用new的Java代碼），class屬性指定了需要創建的bean的類。在比較少的情況下，BeanFactory調用某個類的靜態的工廠方法來創建bean， class屬性指定了實際包含靜態工廠方法的那個類。（至于靜態工廠方法返回的bean的類型是同一個類還是完全不同的另一個類，這并不重要）。

3.2.3.1.?通過構造函數創建bean

當使用構造函數創建bean時，所有普通的類都可以被Spring使用并且和Spring兼容。這就是說，被創建的類不需要實現任何特定的接口或者按照特定的樣式進行編寫。僅僅指定bean的類就足夠了。然而，根據bean使用的IoC類型，你可能需要一個默認的（空的）構造函數。

另外，BeanFactory并不局限于管理真正的JavaBean，它也能管理任何你想讓它管理的類。雖然很多使用Spring的人喜歡在BeanFactory中用真正的JavaBean （僅包含一個默認的（無參數的）構造函數，在屬性后面定義相對應的setter和getter方法），但是在你的BeanFactory中也可以使用特殊的非bean樣式的類。舉例來說，如果你需要使用一個遺留下來的完全沒有遵守JavaBean規范的連接池，不要擔心，Spring同樣能夠管理它。

使用XmlBeanFactory你可以像下面這樣定義你的bean class:

至于為構造函數提供（可選的）參數，以及對象實例創建后設置實例屬性，將會在后面敘述

3.2.3.2.?通過靜態工廠方法創建Bean

當你定義一個使用靜態工廠方法創建的bean，同時使用class屬性指定包含靜態工廠方法的類，這個時候需要factory-method屬性來指定工廠方法名。Spring調用這個方法（包含一組可選的參數）并返回一個有效的對象，之后這個對象就完全和構造方法創建的對象一樣。用戶可以使用這樣的bean定義在遺留代碼中調用靜態工廠。

下面是一個bean定義的例子，聲明這個bean要通過factory-method指定的方法創建。注意這個bean定義并沒有指定返回對象的類型，只指定包含工廠方法的類。在這個例子中，createInstance?必須是static方法 .

至于為工廠方法提供（可選的）參數，以及對象實例被工廠方法創建后設置實例屬性，將會在后面敘述.

3.2.3.3.?通過實例工廠方法創建bean

使用一個實例工廠方法（非靜態的）創建bean和使用靜態工廠方法非常類似，調用一個已存在的bean（這個bean應該是工廠類型）的工廠方法來創建新的bean。

使用這種機制，class屬性必須為空，而且factory-bean屬性必須指定一個bean的名字，這個bean一定要在當前的bean工廠或者父bean工廠中，并包含工廠方法。而工廠方法本身仍然要通過factory-method屬性設置。

下面是一個例子：

<bean id="myFactoryBean"class="...">... </bean>  <bean id="exampleBean"factory-bean="myFactoryBean"factory-method="createInstance"/>

雖然我們要在后面討論設置bean的屬性，但是這個方法意味著工廠bean本身能夠被容器通過依賴注射來管理和配置

3.2.4.?Bean的標志符 (id與name)

每一個bean都有一個或多個id（也叫作標志符，或名字；這些名詞說的是一回事）。這些id在管理bean的BeanFactory或ApplicationContext中必須是唯一的。一個bean差不多總是只有一個id，但是如果一個bean有超過一個的id，那么另外的那些本質上可以認為是別名。

在一個XmlBeanFactory中（包括ApplicationContext的形式），你可以用id或者name屬性來指定bean的id(s)，并且在這兩個或其中一個屬性中至少指定一個id。 id屬性允許你指定一個id，并且它在XML DTD（定義文檔）中作為一個真正的XML元素的ID屬性被標記，所以XML解析器能夠在其他元素指回向它的時候做一些額外的校驗。正因如此，用id屬性指定bean的id是一個比較好的方式。然而，XML規范嚴格限定了在XML ID中合法的字符。通常這并不是真正限制你，但是如果你有必要使用這些字符（在ID中的非法字符），或者你想給bean增加其他的別名，那么你可以通過name屬性指定一個或多個id（用逗號,或者分號;分隔）。

3.2.5.?Singleton的使用與否

Beans被定義為兩種部署模式中的一種：singleton或non-singleton。（后一種也別叫作prototype，盡管這個名詞用的不精確因為它并不是非常適合）。如果一個bean是singleton形態的，那么就只有一個共享的實例存在，所有和這個bean定義的id符合的bean請求都會返回這個唯一的、特定的實例。

如果bean以non-singleton，prototype模式部署的話，對這個bean的每次請求都會創建一個新的bean實例。這對于例如每個user需要一個獨立的user對象這樣的情況是非常理想的。

Beans默認被部署為singleton模式，除非你指定。要記住把部署模式變為non-singletion（prototype）后，每一次對這個bean的請求都會導致一個新創建的bean，而這可能并不是你真正想要的。所以僅僅在絕對需要的時候才把模式改成prototype。

在下面這個例子中，兩個bean一個被定義為singleton，而另一個被定義為non-singleton（prototype）。客戶端每次向BeanFactory請求都會創建新的exampleBean，而AnotherExample僅僅被創建一次；在每次對它請求都會返回這個實例的引用。

注意：當部署一個bean為prototype模式，這個bean的生命周期就會有稍許改變。通過定義，Spring無法管理一個non-singleton/prototype bean的整個生命周期，因為當它創建之后，它被交給客戶端而且容器根本不再跟蹤它了。當說起non-singleton/prototype bean的時候，你可以把Spring的角色想象成“new”操作符的替代品。從那之后的任何生命周期方面的事情都由客戶端來處理。BeanFactory中bean的生命周期將會在?第?3.4.1?節 “生命周期接口”一節中有更詳細的敘述。

3.3.?屬性，合作者，自動裝配和依賴檢查

3.3.1.?設置bean的屬性和合作者

反向控制通常與依賴注入同時提及。基本的規則是bean通過以下方式來定義它們的依賴（比如它們與之合作的其他對象）：構造函數的參數，工廠方法的參數；當對象實例被構造出來或從一個工廠方法返回后設置在這個實例上的屬性。容器的工作就是創建完bean之后，真正地注入這些依賴。這完全是和一般控制方式相反的（因此稱為反向控制），比如bean實例化，或者直接使用構造函數定位依賴關系，或者類似Service Locator模式的東西。我們不會詳細闡述依賴注射的優點，很顯然通過使用它：代碼變得非常清晰；當bean不再自己查找他們依賴的類而是由容器提供，甚至不需要知道這些類在哪里以及它們實際上是什么類型，這時高層次的解耦也變得很容易了。

正如上面提到的那樣，反向控制/依賴注射存在兩種主要的形式:

基于setter的依賴注射，是在調用無參的構造函數或無參的靜態工廠方法實例化你的bean之后，通過調用你的bean上的setter方法實現的。在BeanFactory中定義的使用基于setter方法的注射依賴的bean是真正的JavaBean。 Spring一般提倡使用基于setter方法的依賴注射，因為很多的構造函數參數將會是笨重的，尤其在有些屬性是可選的情況下。
基于構造函數的依賴注射，它是通過調用帶有許多參數的構造方法實現的，每個參數表示一個合作者或者屬性。另外，調用帶有特定參數的靜態工廠方法來構造bean可以被認為差不多等同的，接下來的文字會把構造函數的參數看成和靜態工廠方法的參數類似。雖然Spring一般提倡在大多數情況下使用基于setter的依賴注射，但是Spring還是完全支持基于構造函數的依賴注射，因為你可能想要在那些只提供多參數構造函數并且沒有setter方法的遺留的bean上使用Spring。另外對于一些比較簡單的bean，一些人更喜歡使用構造函數方法以確保bean不會處于錯誤的狀態。

BeanFactory同時支持這兩種方式將依賴注射到被管理bean中。（實際上它還支持在一些依賴已經通過構造函數方法注射后再使用setter方法注射依賴）。依賴的配置是以BeanDefinition的形式出現，它和JavaBeans的PropertyEditors一起使用從而知道如何把屬性從一個格式轉變為另一個。真正傳送的值被封裝為PropertyValue對象。然而，大多數Spring的使用者并不要直接（比如編程的方式）處理這些類，而更多地使用一個XML定義文件，這個文件會在內部被轉變為這些類的實例，用來讀取整個BeanFactory或ApplicationContext。

Bean依賴的決定通常取決于下面這些內容:

BeanFactory通過使用一個描述所有bean的配置被創建和實例化。大多數的Spring用戶使用一個支持XML格式配置文件的BeanFactory或ApplicationContext實現。

每一個bean的依賴表現為屬性，構造函數參數，或者當用靜態工廠方法代替普通構造函數時工廠方法的參數。這些依賴將會在bean真正被創建出來后提供給bean。

每一個屬性或者構造函數參數要么是一個要被設置的值的定義，要么是一個指向BeanFactory中其他bean的引用。在ApplicationContext的情況下，這個引用可以指向一個父親ApplicationContext中bean。

每一個屬性或構造函數參數的值，必須能夠從（配置文件中）被指定的格式轉變為真實類型。缺省情況下，Spring能夠把一個字符串格式的值轉變為所有內建的類型，比如int,?long，String,?boolean等等。另外當說到基于XML的BeanFactory實現的時候（包括ApplicationContext實現），它們已經為定義Lists, Maps, Sets和Properties集合類型提供了內在的支持。另外，Spring通過使用JavaBeans的?PropertyEditor定義，能夠將字符串值轉變為其他任意的類型。（你可以為PropertyEditor提供你自己的PropertyEditor定義從而能夠轉變你自定義的類型；更多關于PropertyEditors的信息以及如何手工增加自定義的PropertyEditors請參看第?3.9?節 “注冊附加的定制PropertyEditor”）。當一個bean屬性是一個Java Class類型，Spring允許你用這個類的名字的字符串作為這個屬性的值，ClassEditor?這個內建的PropertyEditor會幫你把類的名字轉變成真實的Class實例。

很重要的一點就是：Spring在BeanFactory創建的時候要校驗BeanFactory中每一個Bean的配置。這些校驗包括作為Bean引用的屬性必須實際引用一個合法的bean（比如被引用的bean也定義在BeanFactory中，或者當ApplicationContext時，在父親ApplicationContext中）。但是，bean屬性本身直到bean被真實建立的的時候才被設置。對于那些是singleton并且被設置為pre-instantiated的bean來說（比如一個ApplicationContext中的singletonbean），bean在創建BeanFactory的時候創建，但是對于其他情況，發生在bean被請求的時候。當一個bean必須被創建時，它會潛在地導致一系列的其他bean被創建，像它的依賴以及它的依賴的依賴（如此下去）被創建和賦值。

通常你可以信任Spring做了正確的事情。它會在BeanFactory裝載的時候檢查出錯誤，包括對不存在bean的引用和循環引用。它會盡可能晚地設置屬性和解決依賴（比如創建那些需要的依賴），也就是在bean真正被創建的時候。這就意味著：就算一個BeanFactory被正確地裝載，稍后當你請求一個bean的時候，如果創建那個bean或者它的依賴的時候出現了錯誤，這個BeanFactory也會拋出一個異常。比如，如果一個bean拋出一個異常作為缺少或非法屬性的結果，這樣的情況就會發生。這種潛在地推遲一些配置錯誤可見性的行為正是ApplicationContext默認預實例化singleton bean的原因。以前期的時間和內存為代價在beans真正需要之前創建它們，你就可以在ApplicationContext創建的時候找出配置錯誤，而不是在后來。如果你愿意，你也可以覆蓋這種默認的行為，設置這些singleton bean為lazy-load（不是預實例化的）。

幾個例子:

首先，一個使用BeanFactory以及基于setter方法的依賴注射。下面是一個定義了一些bean的XmlBeanFactory?配置文件的一小部分。接下去是正式的bean的代碼，演示了正確的setter方法聲明。

public class ExampleBean {private AnotherBean beanOne;private YetAnotherBean beanTwo;private int i;public void setBeanOne(AnotherBean beanOne) {this.beanOne = beanOne;}public void setBeanTwo(YetAnotherBean beanTwo) {this.beanTwo = beanTwo;}public void setIntegerProperty(int i) {this.i = i;} }

正如你所看到的一樣，setter方法被聲明以符合XML文件中指定的屬性。（XML文件中的屬性，直接對應著RootBeanDefinition中的PropertyValues對象）

接著是一個使用IoC type3（基于構造函數的依賴注射）的BeanFactory。下面是XML配置中的一段，指定了構造函數參數以及展示構造函數的代碼：

public class ExampleBean {private AnotherBean beanOne;private YetAnotherBean beanTwo;private int i;public ExampleBean(AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {this.beanOne = anotherBean;this.beanTwo = yetAnotherBean;this.i = i;} }

正如你所看到的，bean定義中指定的構造函數參數將會作為ExampleBean的構造函數參數被傳入。

現在考慮一下不用構造函數，而是調用一個靜態工廠方法來返回一個對象的實例:

public class ExampleBean {...// a private constructorprivate ExampleBean(...) {...}// a static factory method// the arguments to this method can be considered the dependencies of the bean that// is returned, regardless of how those arguments are actually used.public static ExampleBean ExampleBean(AnotherBean anotherBean,YetAnotherBean yetAnotherBean, int i) {ExampleBean eb = new ExampleBean(...);// some other operations...return eb;} }

需要注意的是：靜態工廠方法的參數由?constructor-arg元素提供，這和構造函數的用法是一樣的。這些參數是可選的。重要的一點是工廠方法所返回的對象類型不一定和包含這個靜態工廠方法的類一致，雖然上面這個例子中是一樣的。前面所提到的實例工廠方法（non-static）用法基本上是一樣的（除了使用factory-bean屬性代替class屬性），在這里就不再詳細敘述了。 .

3.3.2.?深入Bean屬性和構造函數參數

正如前面提到的那樣，bean的屬性和構造函數參數可以被定義為其他bean的引用（合作者），或者內聯定義的值。為了達到這個目的，XmlBeanFactory在property和constructor-arg元素中支持許多子元素類型。

value元素用適合人讀的字符串形式指定屬性或構造函數參數。正如前面提到的那樣，JavaBeans的PropertyEditors被用來將這些字符串從java.lang.String類型轉變為真實的屬性類型或參數類型。

<beans><bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"><property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property><property name="url"><value>jdbc:mysql://localhost:3306/mydb</value></property><property name="username"><value>root</value></property></bean> </beans>

null元素被用來處理null值。Spring將porperties等的空參數視為空的字符串。下面這個XmlBeanFactory配置:

導致email屬性被設置為””，同java代碼：exampleBean.setEmail("")等價。而專門的<null>元素則可以用來指定一個null值，所以

同代碼：exampleBean.setEmail(null)是等價的.

list,?set,?map, 以及?props?元素可以用來定義和設置類型為Java的List,Set,?Map, 和?Properties?.

<beans>...<bean id="moreComplexObject" class="example.ComplexObject"><property name="people"><props><prop key="HarryPotter">The magic property</prop><prop key="JerrySeinfeld">The funny property</prop></props></property><property name="someList"><list><value>a list element followed by a reference</value><ref bean="myDataSource"/></list></property><property name="someMap"><map><entry key="yup an entry"><value>just some string</value></entry><entry key="yup a ref"><ref bean="myDataSource"/></entry></map></property><property name="someSet"><set><value>just some string</value><ref bean="myDataSource"/></set></property></bean> </beans>

注意：Map的entry或set的value，它們的值又可以是下面元素中的任何一個：

在property?元素中定義的bean元素用來定義一個內聯的bean，而不是引用BeanFactory其他地方定義的bean。內聯bean定義不需要任何id定義

idref元素完全是一種簡寫和防止錯誤的方式，用來設置屬性值為容器中其他bean的id?或name。

這個在運行時同下面的片段等價:

<bean id="theTargetBean" class="..."> </bean> <bean id="theClientBean" class="..."><property name="targetName"><value>theTargetBean</value></property> </bean>

第一種形式比第二種形式更好的原因是：使用idref標記將會使Spring在部署的時候就驗證其他的bean是否真正存在；在第二種形式中，targetName屬性的類僅僅在Spring實例化這個類的時候做它自己的驗證，這很可能在容器真正部署完很久之后。

另外，如果被引用的bean在同一個xml文件中而且bean的名稱是bean的?id，那么就可以使用local屬性。它會讓XML解析器更早，在XML文檔解析的時候，驗證bean的名稱。

ref元素是最后一個能在property元素中使用的元素。它是用來設置屬性值引用容器管理的其他bean（可以叫做合作者）。正如前一節提到的，擁有這些屬性的bean依賴被引用的bean，被引用的bean將會在屬性設置前，必要的時候需要時初始化（如果是一個singleton bean可能已經被容器初始化）。所有的引用根本上是一個指向其他對象的引用，不過有3種形式指定被引用對象的id/name，這3種不同形式決定作用域和如何處理驗證。

用ref元素的bean屬性指定目標bean是最常見的形式，它允許指向的bean可以在同一個BeanFactory/ApplicationContext（無論是否在同一個XML文件中）中，也可以在父BeanFactory/ApplicationContext中。bean屬性的值可以同目標bean的id屬性相同，也可以同目標bean的name屬性中任何一個值相同。

用local屬性指定目標bean可以利用XML解析器的能力在同一個文件中驗證XML id引用。local屬性的值必須與目標bean的id屬性一致。如果在同一個文件中沒有匹配的元素，XML解析器將會產生一個錯誤。因此，如果目標bean在同一個XML文件中，那么使用local形式將是最好的選擇（為了能夠盡可能早的發現錯誤）。

用parent屬性指定目標bean允許引用當前BeanFactory（ApplicationContext）的父BeanFactory(ApplicationContext)中的bean。parent屬性的值可以同目標bean的id屬性相同，也可以同目標bean的name屬性中的一個值相同，而且目標bean必須在當前BeanFactory（ApplicationContext）的父BeanFactory（ApplicationContext）中。當需要用某種proxy包裝一個父上下文中存在的bean（可能和父上下文中的有同樣的name），所以需要原始的對象用來包裝它。

3.3.3.?方法注入

對于大部分的用戶來說，容器中多數的bean是singleton的。當一個singleton的bean需要同另一個singleton的 bean合作（使用）時，或者一個非singleton的bean需要同另一個非singleton的bean合作的時候，通過定義一個bean為另一個bean的屬性來處理這種依賴的關系就足夠了。然而當bean的生命周期不同的時候就有一個問題。想想一下一個singleton bean A，或許在每次方法調用的時候都需要使用一個non-singleton bean B。容器僅僅會創建這個singleton bean A一次，因此僅僅有一次的機會去設置它的屬性。因此容器沒有機會每次去為bean A提供新的bean B的實例。

一個解決這個問題的方法是放棄一些反向控制。Bean A可以通過實現?BeanFactoryAware知道容器的存在（參見這里)），使用編程的手段（參見這里）在需要的時候通過調用getBean("B")來向容器請求新的bean B實例。因為bean的代碼知道Spring并且耦合于Spring，所以這通常不是一個好的方案。

方法注入，BeanFactory的高級特性之一，可以以清潔的方式處理這種情況以及其他一些情況。

3.3.3.1.?Lookup方法注入

Lookup方法注射指容器能夠重寫容器中bean的抽象或具體方法，返回查找容器中其他bean的結果。被查找的bean在上面描述的場景中通常是一個non-singleton bean （盡管也可以是一個singleton的）。Spring通過使用CGLIB庫在客戶端的類之上修改二進制碼，從而實現上述的場景要求。

包含方法注入的客戶端類，必須按下面的形式的抽象（具體）定義方法:

protected abstract SingleShotHelper createSingleShotHelper();

如果方法不是抽象的，Spring就會直接重寫已有的實現。在XmlBeanFactory的情況下，你可以使用bean定義中的lookup-method?屬性來指示Spring去注入/重寫這個方法，以便從容器返回一個特定的bean。舉個例子說明：

<bean id="singleShotHelper class="..." singleton="false"> </bean> <bean id="myBean" class="..."><lookup-method name="createSingleShotHelper"bean="singleShotHelper"/><property>...</property> </bean>

當myBean需要一個新的singleShotHelper的實例的時候，它就會調用它自己的createSingleShotHelper?方法。值得注意的是：部署beans的人員必須小心地將singleShotHelper作為一個non-singleton部署（如果確實需要這么做）。如果它作為一個singleton（除非明確說明，否則缺省就是singletion）而部署，同一個singleShotHelper實例將會每次被返回。

注意Lookup方法注射能夠同構造函數注射結合（對創建的bean提供可選的構造函數參數），也可以同setter方法注射結合（在創建的bean之上設置屬性）。

3.3.3.2.?任意方法的替換

另一種方法注射沒有lookup方法注入用的多，它用另一個方法實現替換被管理bean的任意一個方法。用戶可以放心跳過這一節（這是個有點高級的特性），除非這個功能確實需要。

在一個XmlBeanFactory中，對于一個被部署的bean，?replaced-method元素可以用來把已存在的方法實現替換為其他的實現。考慮如下的類，有一個我們想要重寫的computeValue方法：

... public class MyValueCalculator {public String computeValue(String input) {... some real code}... some other methods }

需要為新方法定義提供實現?org.springframework.beans.factory.support.MethodReplacer接口的類。

/** meant to be used to override the existing computeValueimplementation in MyValueCalculator */ public class ReplacementComputeValue implements MethodReplacer {public Object reimplement(Object o, Method m, Object[] args) throws Throwable {// get the input value, work with it, and return a computed resultString input = (String) args[0];... return ...; }

部署原始的類和指定方法重寫的BeanFactory部署定義象下面所示的 :

<bean id="myValueCalculator class="x.y.z.MyValueCalculator"><replaced-method name="computeValue" replacer="replacementComputeValue"><arg-type>String</arg-type></replaced-method> </bean><bean id="replacementComputeValue" class="a.b.c.ReplaceMentComputeValue"> </bean>

replaced-method元素中的一個或多個arg-type?元素用來表示，這個被重載方法的方法簽名。注意，參數的簽名只有在方法被重載并且該方法有多個不同的形式的時候才真正需要。為了方便，參數的類型字符串可以使全限定名的子字符串。比如，以下的都匹配java.lang.String。

java.lang.StringStringStr

因為參數的個數通常就足夠區別不同的可能，所以僅僅使用匹配參數的最短的字符串能夠節省很多鍵入工作。

3.3.4.?使用?depends-on

對于大多數的情況，一個bean被另一個bean依賴，是由這個bean是否被當作其他bean的屬性來表達的。在XmlBeanFactory中，它是通過ref元素來完成的。與這種方式不同的是，有時一個知道容器的bean僅僅會被給與它所的依賴的id （使用一個字符串值或等價的idref元素）。接著第一個bean就以編程的方式地向容器請求它的依賴。在兩種情況下，被依賴的bean都會在依賴它的bean之前被恰當地初始化。

對于相對罕見的情況，beans之間的依賴不夠直接（舉例，當一個類中的靜態初始塊需要被觸發，比如數據庫驅動的注冊），depends-on?元素可以用來在初始化使用這個元素的bean之前，強制一個或多個beans初始化。

下面是一個配置的例子:

3.3.5.?自動裝配協作對象

BeanFactory能夠自動裝配合作bean之間的關系。這就意味著，讓Spring通過檢查BeanFactory的內容來自動裝配你的bean的合作者（也就是其他的bean）。自動裝配功能有5種模式。自動裝配可以指定給每一個bean，因此可以給一些bean使用而其他的bean不自動裝配。通過使用自動裝配，可以減少（或消除）指定屬性（或構造函數參數）的需要，顯著節省鍵入工作。?^[1]?在XmlBeanFactory中，使用bean元素的autowire屬性來指定bean定義的自動裝配模式。以下是允許的值.

表?3.2.?自動裝配模式

模式解釋

no	不使用自動裝配。Bean的引用必須通過ref元素定義。這是默認的配置，在較大的部署環境中不鼓勵改變這個配置，因為明確的指定合作者能夠得到更多的控制和清晰性。從某種程度上說，這也是系統結構的文檔形式。
byName	通過屬性名字進行自動裝配。這個選項會會檢查BeanFactory，查找一個與將要裝配的屬性同樣名字的bean 。比如，你有一個bean的定義被設置為通過名字自動裝配，它包含一個master屬性（也就是說，它有一個setMaster(...)方法），Spring就會查找一個叫做master的bean定義，然后用它來設置master屬性。
byType	如果BeanFactory中正好有一個同屬性類型一樣的bean，就自動裝配這個屬性。如果有多于一個這樣的bean，就拋出一個致命異常，它指出你可能不能對那個bean使用byType的自動裝配。如果沒有匹配的bean，則什么都不會發生，屬性不會被設置。如果這是你不想要的情況（什么都不發生），通過設置dependency-check="objects"屬性值來指定在這種情況下應該拋出錯誤。
constructor	這個同byType類似，不過是應用于構造函數的參數。如果在BeanFactory中不是恰好有一個bean與構造函數參數相同類型，則一個致命的錯誤會產生。
autodetect	通過對bean 檢查類的內部來選擇constructor或byType。如果找到一個缺省的構造函數，那么就會應用byType。

注意：顯式的指定依賴，比如property和constructor-arg元素，總會覆蓋自動裝配。自動裝配的行為可以和依賴檢查結合使用，依賴檢查會在自動裝配完成后發生。

注意：正如我們已經提到過的，對于大型的應用，自動裝配不鼓勵使用，因為它去除了你的合作類的透明性和結構。

3.3.6.?依賴檢查

對于部署在BeanFactory的bean的未解決的依賴，Spring有能力去檢查它們的存在性。這些依賴要么是bean的JavaBean式的屬性，在bean的定義中并沒有為它們設置真實的值，要么是通過自動裝配特性被提供。

當你想確保所有的屬性（或者某一特定類型的所有屬性）都被設置到bean上面的時候，這項特性就很有用了。當然，在很多情況下一個bean類的很多屬性都會有缺省的值，或者一些屬性并不會應用到所有的應用場景，那么這個特性的作用就有限了。依賴檢查能夠分別對每一個bean應用或取消應用，就像自動裝配功能一樣。缺省的是不?檢查依賴關系。依賴檢查可以以幾種不同的模式處理。在XmlBeanFactory中，通過bean定義中的?dependency-check?屬性來指定依賴檢查，這個屬性有以下的值。

表?3.3.?依賴檢查模式

模式解釋

none	不進行依賴檢查。沒有指定值的bean屬性僅僅是沒有設值。
simple	對基本類型和集合（除了合作者外，比如其他的bean，所有東西）進行依賴檢查。
object	對合作者進行依賴檢查。
all	對合作者，基本類型和集合都進行依賴檢查。

3.4.?自定義bean的本質特征

3.4.1.?生命周期接口

Spring提供了一些標志接口，用來改變BeanFactory中的bean的行為。它們包括InitializingBean和DisposableBean。實現這些接口將會導致BeanFactory調用前一個接口的afterPropertiesSet()方法，調用后一個接口destroy()方法，從而使得bean可以在初始化和析構后做一些特定的動作。

在內部，Spring使用BeanPostProcessors?來處理它能找到的標志接口以及調用適當的方法。如果你需要自定義的特性或者其他的Spring沒有提供的生命周期行為，你可以實現自己的?BeanPostProcessor。關于這方面更多的內容可以看這里：?第?3.7?節 “使用BeanPostprocessors定制bean”。

所有的生命周期的標志接口都在下面敘述。在附錄的一節中，你可以找到相應的圖，展示了Spring如何管理bean；那些生命周期的特性如何改變你的bean的本質特征以及它們如何被管理。

3.4.1.1.?InitializingBean /?init-method

實現org.springframework.beans.factory.InitializingBean?接口允許一個bean在它的所有必須的屬性被BeanFactory設置后，來執行初始化的工作。InitializingBean接口僅僅制定了一個方法：

* Invoked by a BeanFactory after it has set all bean properties supplied* (and satisfied BeanFactoryAware and ApplicationContextAware).* <p>This method allows the bean instance to perform initialization only* possible when all bean properties have been set and to throw an* exception in the event of misconfiguration.* @throws Exception in the event of misconfiguration (such* as failure to set an essential property) or if initialization fails.*/void afterPropertiesSet() throws Exception;

注意：通常InitializingBean接口的使用是能夠避免的（而且不鼓勵，因為沒有必要把代碼同Spring耦合起來）。Bean的定義支持指定一個普通的初始化方法。在使用XmlBeanFactory的情況下，可以通過指定init-method屬性來完成。舉例來說，下面的定義：

<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>public class ExampleBean {public void init() {// do some initialization work} }

同下面的完全一樣：

<bean id="exampleInitBean" class="examples.AnotherExampleBean"/>public class AnotherExampleBean implements InitializingBean {public void afterPropertiesSet() {// do some initialization work} }

但卻不把代碼耦合于Spring。

3.4.1.2.?DisposableBean /?destroy-method

實現org.springframework.beans.factory.DisposableBean接口允許一個bean，可以在包含它的BeanFactory銷毀的時候得到一個回調。DisposableBean也只指定了一個方法：

/*** Invoked by a BeanFactory on destruction of a singleton.* @throws Exception in case of shutdown errors.* Exceptions will get logged but not rethrown to allow* other beans to release their resources too.*/void destroy() throws Exception;

注意：通常DisposableBean接口的使用能夠避免的（而且是不鼓勵的，因為它不必要地將代碼耦合于Spring）。 Bean的定義支持指定一個普通的析構方法。在使用XmlBeanFactory使用的情況下，它是通過?destroy-method屬性完成。舉例來說，下面的定義：

<bean id="exampleInitBean" class="examples.ExampleBean" destroy-method="destroy"/>public class ExampleBean {public void cleanup() {// do some destruction work (like closing connection)} }

同下面的完全一樣：

<bean id="exampleInitBean" class="examples.AnotherExampleBean"/>public class AnotherExampleBean implements DisposableBean {public void destroy() {// do some destruction work} }

但卻不把代碼耦合于Spring。

重要的提示：當以portotype模式部署一個bean的時候，bean的生命周期將會有少許的變化。通過定義，Spring無法管理一個non-singleton/prototype bean的整個生命周期，因為當它創建之后，它被交給客戶端而且容器根本不再留意它了。當說起non-singleton/prototype bean的時候，你可以把Spring的角色想象成“new”操作符的替代品。從那之后的任何生命周期方面的事情都由客戶端來處理。BeanFactory中bean的生命周期將會在第?3.4.1?節 “生命周期接口”?一節中有更詳細的敘述?.

3.4.2.?了解自己

3.4.2.1.?BeanFactoryAware

對于實現了org.springframework.beans.factory.BeanFactoryAware接口的類，當它被BeanFactory創建后，它會擁有一個指向創建它的BeanFactory的引用。

public interface BeanFactoryAware {/*** Callback that supplies the owning factory to a bean instance.* <p>Invoked after population of normal bean properties but before an init* callback like InitializingBean's afterPropertiesSet or a custom init-method.* @param beanFactory owning BeanFactory (may not be null).* The bean can immediately call methods on the factory.* @throws BeansException in case of initialization errors* @see BeanInitializationException*/void setBeanFactory(BeanFactory beanFactory) throws BeansException; }

這允許bean可以以編程的方式操控創建它們的BeanFactory，既可以直接使用?org.springframework.beans.factory.BeanFactory接口，也可以將引用強制將類型轉換為已知的子類型從而獲得更多的功能。這個特性主要用于編程式地取得其他bean。雖然在一些場景下這個功能是有用的，但是一般來說它應該避免使用，因為它使代碼與Spring耦合在一起，而且也不遵循反向控制的風格（合作者應當作屬性提供給bean）。

3.4.2.2.?BeanNameAware

如果一個bean實現了org.springframework.beans.factory.BeanNameAware接口，并且被部署到一個 BeanFactory中，那么BeanFactory就會通過這個接口來調用bean，以便通知這個bean它被部署的id?。這個回調發生在普通的bean屬性設置之后，在初始化回調之前，比如InitializingBean的afterPropertiesSet方法（或者自定義的init- method）。

3.4.3.?FactoryBean

接口org.springframework.beans.factory.FactoryBean?一般由本身是工廠類的對象實現。BeanFactory接口提供了三個方法：

Object getObject(): 必須返回一個這個工廠類創建的對象實例。這個實例可以是共享的（取決于這個工廠返回的是singleton還是prototype）。
boolean isSingleton(): 如果Factory返回的對象是singleton，返回true，否則返回false。
Class getObjectType(): 返回getObject()方法返回的對象的類型，如果類型不是預先知道的，則返回null。

3.5.?子bean定義

一個bean定義可能會包含大量的配置信息，包括容器相關的信息（比如初始化方法，靜態工廠方法名等等）以及構造函數參數和屬性的值。一個子bean定義是一個能夠從父bean定義繼承配置數據的bean定義。它可以覆蓋一些值，或者添加一些其他需要的值。使用父和子的bean定義可以節省很多的輸入工作。實際上，這就是一種模版形式。

當以編程的方式使用一個BeanFactory，子bean定義用ChildBeanDefinition類表示。大多數的用戶從來不需要以這個方式使用它們，而是在類似XmlBeanFactory的BeanFactory 中以聲明的方式配置bean定義。在一個XmlBeanFactory的bean定義中，使用parent屬性指出一個子bean定義，而父bean則作為這個屬性的值。

<bean id="inheritedTestBean" class="org.springframework.beans.TestBean"><property name="name"><value>parent</value></property><property name="age"><value>1</value></property> </bean><bean id="inheritsWithDifferentClass" class="org.springframework.beans.DerivedTestBean"parent="inheritedTestBean" init-method="initialize"><property name="name"><value>override</value></property></bean>

如果子bean定義沒有指定class屬性，將使用父定義的class屬性，當然也可以覆蓋它。在后面一種情況中，子bean的class屬性值必須同父bean的兼容，也就是它必須能夠接受父親的屬性值。

一個子bean定義可以從父親處繼承構造函數參數，屬性值以及方法，并且可以選擇增加新的值。如果init-method，destroy-method和/或靜態factory-method被指定了，它們就會覆蓋父親相應的設置。

剩余的設置將?總是?從子定義處得到:?依賴,?自動裝配模式,?依賴檢查，?singleton,?延遲初始化。

在下面的例子中父定義并沒有指定class屬性：

<bean id="inheritedTestBeanWithoutClass"><property name="name"><value>parent</value></property><property name="age"><value>1</value></property> </bean><bean id="inheritsWithClass" class="org.springframework.beans.DerivedTestBean"parent="inheritedTestBeanWithoutClass" init-method="initialize"><property name="name"><value>override</value></property> </bean>

這個父bean就無法自己實例化；它實際上僅僅是一個純模版或抽象bean，充當子定義的父定義。若要嘗試單獨使用這樣的父bean（比如將它作為其他bean的ref屬性而引用，或者直接使用這個父 bean的id調用getBean()方法），將會導致一個錯誤。同樣地，容器內部的preInstantiateSingletons方法會完全忽略這種既沒有parent屬性也沒有class屬性的bean定義，因為它們是不完整的。

特別注意：這里并沒有辦法顯式地聲明一個bean定義為抽象的。如果一個bean確實有一個class屬性定義，那么它就能夠被實例化。而且要注意 XmlBeanFactory默認地將會預實例化所有的singleton的bean。因此很重要的一點是：如果你有一個（父）bean定義指定了class屬性，而你又想僅僅把它當作模板使用，那么你必須保證將lazy-init屬性設置為true（或者將bean標記為non-singleton），否則 XmlBeanFactory（以及其他可能的容器）將會預實例化它。

3.6.?BeanFactory之間的交互

BeanFactory本質上不過是高級工廠的接口，它維護不同bean和它們所依賴的bean的注冊。 BeanFactory使得你可以利用 bean工廠讀取和訪問bean定義。當你使用BeanFactory的時候，你可以象下面一樣創建并且讀入一些XML格式的bean定義：

InputStream is = new FileInputStream("beans.xml"); XmlBeanFactory factory = new XmlBeanFactory(is);

基本上這就足夠了。使用getBean(String)你可以取得你的bean的實例。如果你將它定義為一個singleton（缺省的）你將會得到同一個bean的引用，如果你將singleton設置為false，那么你將會每次得到一個新的實例。在客戶端的眼里BeanFactory是驚人的簡單。BeanFactory接口僅僅為客戶端調用提供了5個方法：

boolean containsBean(String): 如果BeanFactory包含一個與所給名稱匹配的bean定義，則返回true
Object getBean(String): 返回一個以所給名字注冊的bean的實例。返回一個singleton的共享的實例還是一個新創建的實例，這取決于bean在BeanFactory配置中如何被配置的。一個BeansException將會在下面兩種情況中拋出：bean沒有被找到（在這種情況下，拋出的是NoSuchBeanDefinitionException），或者在實例化和準備bean的時候發生異常
Object getBean(String,Class): 返回一個以給定名字注冊的bean。返回的bean將會被強制類型轉換成給定的Class。如果bean不能被類型轉換，相應的異常將會被拋出（BeanNotOfRequiredTypeException）。此外getBean(String)的所有規則也同樣適用這個方法（同上）
boolean isSingleton(String): 判斷以給定名字注冊的bean定義是一個singleton還是一個prototype。如果與給定名字相應的bean定義沒有被找到，將會拋出一個異常（NoSuchBeanDefinitionException）
String[] getAliases(String):如果給定的bean名字在bean定義中有別名，則返回這些別名

3.6.1.?獲得一個FactoryBean而不是它生成的bean

有些時候我們需要向BeanFactory請求實際的FactoryBean實例本身，而不是它生產出來的bean。在調用BeanFactory （包括ApplicationContext）的getBean方法的時候，在傳入的參數bean id前面加一個“&”符號，就可以做到這一點。所以，對于一個id為getBean的FactoryBean，在BeanFactory上調用getBean("myBean")將會返回FactoryBean的產品，而調用getBean("&myBean")將會返回這個FactoryBean實例本身。

3.7.?使用BeanPostprocessors定制bean

一個bean post-processor是一個實現了org.springframework.beans.factory.config.BeanPostProcessor的類，它包含兩個回調方法。當這樣的一個類作為BeanFactory的post-processor注冊時，對于這個BeanFactory創建的每一個bean實例，在任何初始化方法（afterPropertiesSet和用init-method屬性聲明的方法）被調用之前和之后，post-processor將會從BeanFactory分別得到一個回調。post-processor可以對這個bean做任何操作事情，包括完全忽略這個回調。一個bean post-processor通常用來檢查標記接口，或者做一些諸如將一個bean包裝成一個proxy的事情。一些Spring的助手類就是作為bean post-processor而實現的。

有一點很重要，BeanFactory和ApplicationContext對待bean post-processor有少許不同。一個ApplicationContext會自動監測到任何部署在它之上的實現了?BeanPostProcessor接口的bean，并且把它們作為post-processor注冊，然后factory就會在bean創建的時候恰當地調用它們。部署一個post-processor同部屬一個其他的bean并沒有什么區別。而另一方面，當使用普通的BeanFactory的時候，作為post-processor的bean必須通過類似下面的代碼來手動地顯式地注冊：

ConfigurableBeanFactory bf = new .....; // create BeanFactory... // now register some beans // now register any needed BeanPostProcessors MyBeanPostProcessor pp = new MyBeanPostProcessor(); bf.addBeanPostProcessor(pp);// now start using the factory...

因為手工的注冊不是很方便，而且ApplicationContext是BeanFactory功能上擴展，所以通常建議當需要post-processor的時候最好使用ApplicationContext。

3.8.?使用BeanFactoryPostprocessors定制bean工廠

一個bean factory post-processor是一個實現了org.springframework.beans.factory.config.BeanFactoryPostProcessor接口的類。它將會被手動執行（BeanFactory的時候）或自動執行（ApplicationContext的時候），在BeanFactory構造出來后，對整個BeanFactory做某種修改。Spring包含很多已存在的bean factory post-processor，比如PropertyResourceConfigurer和PropertyPlaceHolderConfigurer（這兩個將在下面介紹），以及BeanNameAutoProxyCreator對其他bean進行事務包裝或者用其他的proxy進行包裝，將會在后面敘述。BeanFactoryPostProcessor也能用來添加自定義的editor（可參見第?4.3.2?節 “內建的(PropertyEditors)和類型轉換 ”）。

在BeanFactory中，使用BeanFactoryPostProcessor是手動的，將類似于下面:

XmlBeanFactory factory = new XmlBeanFactory(new FileSystemResource("beans.xml")); // create placeholderconfigurer to bring in some property // values from a Properties file PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer(); cfg.setLocation(new FileSystemResource("jdbc.properties")); // now actually do the replacement cfg.postProcessBeanFactory(factory);

ApplicationContext將會檢測它所部署的實現了BeanFactoryPostProcessor?接口的bean，然后在適當的時候將它們作為bean factory post-processor而使用。部署這些post-processor與部署其他的bean并沒有什么區別。

因為這個手動的步驟并不方便，而且ApplicationContext是BeanFactory的功能擴展，所以當需要使用bean factory post-processor的時候通常建議使用ApplicationContext

3.8.1.?PropertyPlaceholderConfigurer

PropertyPlaceholderConfigurer作為一個bean factory post-processor實現，可以用來將BeanFactory定義中的屬性值放置到另一個單獨的Java Properties格式的文件中。這使得用戶不用對BeanFactory的主XML定義文件進行復雜和危險的修改，就可以定制一些基本的屬性（比如說數據庫的urls,用戶名和密碼）。

考慮一個BeanFactory定義的片斷，里面用占位符定義了DataSource：

在下面這個例子中，定義了一個datasource，并且我們會在一個外部Porperties文件中配置一些相關屬性。在運行時，我們為BeanFactory提供一個PropertyPlaceholderConfigurer，它將用Properties文件中的值替換掉這個datasource的屬性值：

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"><property name="driverClassName"><value>${jdbc.driverClassName}</value></property><property name="url"><value>${jdbc.url}</value></property><property name="username"><value>${jdbc.username}</value></property><property name="password"><value>${jdbc.password}</value></property> </bean>

真正的值來自于另一個Properties格式的文件:

jdbc.driverClassName=org.hsqldb.jdbcDriver jdbc.url=jdbc:hsqldb:hsql://production:9002 jdbc.username=sa jdbc.password=root

如果要在BeanFactory中使用，bean factory post-processor必須手動運行:

XmlBeanFactory factory = new XmlBeanFactory(new FileSystemResource("beans.xml")); PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer(); cfg.setLocation(new FileSystemResource("jdbc.properties")); cfg.postProcessBeanFactory(factory);

注意，ApplicationContext能夠自動辨認和應用在其上部署的實現了BeanFactoryPostProcessor的bean。這就意味著，當使用ApplicationContext的時候應用PropertyPlaceholderConfigurer會非常的方便。由于這個原因，建議想要使用這個或者其他bean factory postprocessor的用戶使用ApplicationContext代替BeanFactroy。

PropertyPlaceHolderConfigurer不僅僅在你指定的Porperties文件中查找屬性，如果它在其中沒有找到你想使用的屬性，它還會在Java的系統properties中查找。這個行為能夠通過設置配置中的systemPropertiesMode?屬性來定制。這個屬性有三個值，一個讓配置總是覆蓋，一個讓它永不覆蓋，一個讓它僅在properties文件中找不到的時候覆蓋。請參考 PropertiesPlaceholderConfigurer的JavaDoc獲得更多信息。

3.8.2.??PropertyOverrideConfigurer

另一個bean factory post-processor，PropertyOverrideConfigurer，類似于PropertyPlaceholderConfigurer，但是與后者相比，前者對于bean屬性可以有缺省值或者根本沒有值。如果起覆蓋作用的 Properties文件沒有某個bean屬性的內容，那么缺省的上下文定義將被使用。

注意：bean 工廠的定義并?不會意識到被覆蓋，所以僅僅察看XML定義文件并不能立刻明顯地知道覆蓋配置是否被使用了。在有多個PorpertyOverrideConfigurer對用一個bean屬性定義了不同的值的時候，最后一個將取勝（取決于覆蓋的機制）。

Properties文件的一行配置應該是如下的格式:

beanName.property=value

一個properties文件的例子將會是下面這樣的:

dataSource.driverClassName=com.mysql.jdbc.Driver dataSource.url=jdbc:mysql:mydb

這個例子可以用在包含dataSource的bean的BeanFactory中，這個bean有driver和url屬性。

3.9.?注冊附加的定制PropertyEditor

當用字符串值設置bean的屬性時，BeanFactory實質上使用了標準的JavaBeans 的PropertyEditor將這些String轉換為屬性的復雜類型。Spring預先注冊了很多定制的PropertyEditor（比如，將一個字符串表示的classname轉換成真正的Class對象）。另外，一個類的PropertyEditor如果被恰當地命名并且放在與它提供支持的類同一個包內，那么Java標準的JavaBeans PropertyEditor查找機制就會自動找到這個PropertyEditor。

如果需要注冊其他定制的PropertyEditor，這里也有幾個可用的機制。

最手動的方法，也是通常不方便和不推薦的，就是簡單地使用ConfigurableBeanFactory接口的registerCustomEditor()方法，假定你已經有一個BeanFactory引用。

比較方便的機制是，使用一個特殊的叫CustomEditorConfigurer的bean factory post-precessor。盡管bean factory post-processor能夠和BeanFactory半手動地使用，但是它有一個嵌套的屬性設置。所以強烈建議，就象這里描述的，它能夠和ApplicationContxt一起使用，這樣它就可以以其它bean的方式被部署，并且被自動監測和應用。

3.10.?介紹ApplicationContext

beans包提供了以編程的方式管理和操控bean的基本功能，而context包增加了ApplicationContext，它以一種更加面向框架的方式增強了BeanFactory的功能。多數用戶可以以一種完全的聲明式方式來使用ApplicationContext，甚至不用去手動創建它，但是卻去依賴象ContextLoader的支持類，在J2EE的的web應用的啟動進程中用它啟動ApplicationContext。當然，這種情況下還是可以以編程的方式創建一個ApplicationContext。

Context包的基礎是位于org.springframework.context包中的ApplicationContext接口。它是由BeanFactory接口集成而來，提供BeanFactory所有的功能。為了以一種更向面向框架的方式工作，context包使用分層和有繼承關系的上下文類，包括：

MessageSource, 提供對i18n消息的訪問
資源訪問, 比如URL和文件
事件傳遞給實現了ApplicationListener接口的bean
載入多個（有繼承關系）上下文類，使得每一個上下文類都專注于一個特定的層次，比如應用的web層

因為ApplicationContext包括了BeanFactory所有的功能，所以通常建議先于BeanFactory使用，除了有限的一些場合比如在一個Applet中，內存的消耗是關鍵的，每kb字節都很重要。接下來的章節將敘述ApplicationContext在BeanFactory的基本能力上增建的功能。

3.11.?ApplicationContext中增加的功能

正如上面說明的那樣，ApplicationContext有幾個區別于BeanFactory的特性。讓我們一個一個地討論它們。

3.11.1.?使用MessageSource

ApplicationContext接口繼承MessageSource接口，所以提供了messaging功能（i18n或者國際化）。同NestingMessageSource一起使用，就能夠處理分級的信息，這些是Spring提供的處理信息的基本接口。讓我們很快瀏覽一下這里定義的方法：

String getMessage (String code, Object[] args, String default, Locale loc)：這個方法是從MessageSource取得信息的基本方法。如果對于指定的locale沒有找到信息，則使用默認的信息。傳入的參數args被用來代替信息中的占位符，這個是通過Java標準類庫的MessageFormat實現的。
String getMessage (String code, Object[] args, Locale loc)：本質上和上一個方法是一樣的，除了一點區別：沒有默認值可以指定；如果信息找不到，就會拋出一個NoSuchMessageException。
String getMessage(MessageSourceResolvable resolvable, Locale locale)：上面兩個方法使用的所有屬性都是封裝到一個叫做MessageSourceResolvable的類中，你可以通過這個方法直接使用它。

當ApplicationContext被加載的時候，它會自動查找在context中定義的MessageSource bean。這個bean必須叫做messageSource。如果找到了這樣的一個bean，所有對上述方法的調用將會被委托給找到的message source。如果沒有找到message source，ApplicationContext將會嘗試查它的父親是否包含這個名字的bean。如果有，它將會把找到的bean作為MessageSource。如果它最終沒有找到任何的信息源，一個空的StaticMessageSource將會被實例化，使它能夠接受上述方法的調用。

Spring目前提供了兩個MessageSource的實現。它們是ResourceBundleMessageSource和StaticMessageSource。兩個都實現了NestingMessageSource以便能夠嵌套地解析信息。StaticMessageSource很少被使用，但是它提供以編程的方式向source增加信息。ResourceBundleMessageSource用得更多一些，我們將提供它的一個例子：

<beans><bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource"><property name="basenames"><list><value>format</value><value>exceptions</value><value>windows</value></list></property></bean> </beans>

這段配置假定你在classpath有三個resource bundle，分別叫做fformat，exceptions和windows。使用JDK通過ResourceBundle解析信息的標準方式，任何解析信息的請求都會被處理。TODO：舉一個例子

3.11.2.?事件傳遞

ApplicationContext中的事件處理是通過ApplicationEvent類和ApplicationListener接口來提供的。如果上下文中部署了一個實現了ApplicationListener接口的bean，每次一個ApplicationEvent發布到ApplicationContext時，那個bean就會被通知。實質上，這是標準的Observer設計模式。Spring提供了三個標準事件：

表?3.4.?內置事件

事件解釋

ContextRefreshedEvent	當ApplicationContext已經初始化或刷新后發送的事件。這里初始化意味著：所有的bean被裝載，singleton被預實例化，以及ApplicationContext已準備好
ContextClosedEvent	當使用ApplicationContext的close()方法結束上下文的時候發送的事件。這里結束意味著：singleton被銷毀
RequestHandledEvent	一個與web相關的事件，告訴所有的bean一個HTTP請求已經被響應了（這個事件將會在一個請求結束后被發送）。注意，這個事件只能應用于使用了Spring的DispatcherServlet的web應用

同樣也可以實現自定義的事件。通過調用ApplicationContext的publishEvent()方法，并且指定一個參數，這個參數是你自定義的事件類的一個實例。我們來看一個例子。首先是ApplicationContext：

<bean id="emailer" class="example.EmailBean"><property name="blackList"><list><value>black@list.org</value><value>white@list.org</value><value>john@doe.org</value></list></property> </bean><bean id="blackListListener" class="example.BlackListNotifier"><property name="notificationAddress"><value>spam@list.org</value></property> </bean>

然后是實際的bean：

public class EmailBean implements ApplicationContextAware {/** the blacklist */private List blackList;public void setBlackList(List blackList) {this.blackList = blackList;}public void setApplicationContext(ApplicationContext ctx) {this.ctx = ctx;}public void sendEmail(String address, String text) {if (blackList.contains(address)) {BlackListEvent evt = new BlackListEvent(address, text);ctx.publishEvent(evt);return;}// send email} }public class BlackListNotifier implement ApplicationListener {/** notification address */private String notificationAddress;public void setNotificationAddress(String notificationAddress) {this.notificationAddress = notificationAddress;}public void onApplicationEvent(ApplicationEvent evt) {if (evt instanceof BlackListEvent) {// notify appropriate person}} }

當然，這個特定的例子或許可以用更好的方式實現（或許使用AOP特性），但是它用來說明基本的事件機制是足夠了。

3.11.3.?在Spring中使用資源

很多應用程序都需要訪問資源。資源可以包括文件，以及象web頁面或NNTP newsfeeds的東西。Spring提供了一個清晰透明的方案，以一種協議無關的方式訪問資源。ApplicationContext接口包含一個方法（getResource(String)）負責這項工作。

Resource類定義了幾個方法，這幾個方法被所有的Resource實現所共享：

表?3.5.?資源功能

方法解釋

getInputStream()	用InputStream打開資源，并返回這個InputStream。
exists()	檢查資源是否存在，如果不存在返回false
isOpen()	如果這個資源不能打開多個流將會返回true。因為除了基于文件的資源，一些資源不能被同事多次讀取，它們就會返回false。
getDescription()	返回資源的描述，通常是全限定文件名或者實際的URL。

Spring提供了幾個Resource的實現。它們都需要一個String表示的資源的實際位置。依據這個String，Spring將會自動為你選擇正確的Resource實現。當向ApplicationContext請求一個資源時，Spring首先檢查你指定的資源位置，尋找任何前綴。根據不同的ApplicationContext的實現，不同的Resource實現可被使用的。Resource最好是使用ResourceEditor來配置，比如XmlBeanFactory。

3.12.?在ApplicationContext中定制行為

BeanFactory已經提供了許多機制來控制部署在其中的bean的生命周期（比如象InitializingBean或DisposableBean的標志接口，它們的配置效果和XmlBeanFactory配置中的init-method和destroy-method屬性以及bean post-processor是相同的。在ApplicationContext中，這些也同樣可以工作，但同時也增加了一些用于定制bean和容器行為的機制。

3.12.1.?ApplicationContextAware標記接口

所有BeanFactory中可用的標志接口這里也可以使用。ApplicationContext又增加了一個bean可以實現的標志接口：org.springframework.context.ApplicationContextAware。如果一個bean實現了這個接口并且被部署到了context中，當這個bean創建的時候，將使用這個接口的setApplicationContext()方法回調這個bean，為這個bean提供一個指向當前上下文的引用，這個引用將被存儲起來以便bean以后與上下文發生交互。

3.12.2.?BeanPostProcessor

Bean post-processor（實現了org.springframework.beans.factory.config.BeanPostProcessor的java類）在上面已經敘述過了。還是值得再次提到，post-processor在ApplicationContext中使用要比在普通的BeanFactory中使用方便得多。在一個ApplicationContext中，一個實現了上述標記接口的bean將會被自動查找，并且作為一個bean post-processor被注冊，在創建工廠中的每一個bean時都會被適當地調用。

3.12.3.?BeanFactoryPostProcessor

Bean factory post-processor（實現了org.springframework.beans.factory.config.BeanFactoryPostProcessor接口的java類）在前面已經介紹過。這里也值得再提一下，bean factory post-processor在ApplicationContext中使用也要比在普通的BeanFactory中使用方便得多。在一個ApplicationContext中，一個實現了上述標記接口的bean將會被自動查找，并且作為一個bean factory post-processor被注冊，在適當的時候被調用。

3.12.4.?PropertyPlaceholderConfigurer

PropertyPlaceholderConfigurer在BeanFactory中的使用已經敘述過了。這里仍然值得再次提一下，它在ApplicationContext中的使用要更加方便一些，因為當它像其它bean一樣部署的時候，上下文會自動識別和應用任何的bean factory post-processor，比如這個。這時候就沒有必要手動地運行它。

<bean id="placeholderConfig"class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"><property name="location"><value>jdbc.properties</value></property> </bean>

3.13.?注冊附加的定制PropertyEditors

正如前面曾提到的，Spring使用標準的JavaBeans的PropertyEditor將字符串形式表示的屬性值轉換為屬性真實的復雜的類型。CustomEditorConfigurer，這個bean factory post-processor可以使ApplicationContext很方便地增加對額外的PropertyEditor的支持。

考慮一個用戶類ExoticType，以及另外一個需要ExoticType作為屬性的DependsOnExoticType類：

public class ExoticType {private String name;public ExoticType(String name) {this.name = name;} }public class DependsOnExoticType { private ExoticType type;public void setType(ExoticType type) {this.type = type;} }

當設置好的時候，我們希望能夠以字符串的形式指定屬性，同時背后的PropertyEditor會將這個字符串轉換為一個真正的Exotic類型的對象：

<bean id="sample" class="example.DependsOnExoticType"><property name="type"><value>aNameForExoticType</value></property> </bean>

而這個PorpertyEditor看起來象下面這樣：

// converts string representation to ExoticType object public class ExoticTypeEditor extends PropertyEditorSupport {private String format;public void setFormat(String format) {this.format = format;}public void setAsText(String text) {if (format != null && format.equals("upperCase")) {text = text.toUpperCase();}ExoticType type = new ExoticType(text);setValue(type);} }

最后，我們用CustomEditorConfigurer將新的PropertyEditor注冊到ApplicationContext上，然后ApplicationContext就可以在需要的時候使用這個PropertyEditor了：

<bean id="customEditorConfigurer" class="org.springframework.beans.factory.config.CustomEditorConfigurer"><property name="customEditors"><map><entry key="example.ExoticType"><bean class="example.ExoticTypeEditor"><property name="format"><value>upperCase</value></property></bean></entry></map></property> </bean>

3.14.?用方法調用的返回值來設置bean的屬性

有些時候，需要用容器中另一個bean的方法返回值來設置一個bean的屬性，或者使用其它任意類（不一定是容器中的bean）的靜態方法的返回值來設置。此外，有些時候，需要調用一個靜態或非靜態的方法來執行某些初始化工作。對于這兩個目的，可以使用MethodInvokingFactoryBean助手類。它是一個FactoryBean，可以返回一個靜態或非靜態方法的調用結果。

下面是一個基于XML的BeanFactory的bean定義的例子，它使用那個助手類調用靜態工廠方法：

<bean id="myClass" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"><property name="staticMethod"><value>com.whatever.MyClassFactory.getInstance</value></property> </bean>

下面這個例子先調用一個靜態方法，然后調用一個實例方法，來獲得一個Java System的屬性。雖然有點羅嗦，但是可以工作：

<bean id="sysProps" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"><property name="targetClass"><value>java.lang.System</value></property><property name="targetMethod"><value>getProperties</value></property> </bean> <bean id="javaVersion" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"><property name="targetObject"><ref local="sysProps"/></property><property name="targetMethod"><value>getProperty</value></property><property name="arguments"><list><value>java.version</value></list></property> </bean>

注意，實際上這個類多半用來訪問工廠方法，所以MethodInvokingFactoryBean默認以singleton方式進行操作。經由容器的第一次請求工廠生成對象將會引起調用特定的工廠方法，它的返回值將會被緩存并且返回供這次請求和以后的請求使用。這個工廠的一個內部singleton屬性可以被設置為false，從而導致每次對象的請求都會調用那個目標方法。

通過設置targetMethod屬性為一個靜態方法名的字符串來指定靜態目標方法，而設置targetClass為定義靜態方法的類。或者，通過設置targetObject屬性目標對象，設置targetMethod屬性要在目標對象上調用的方法名，來指定目標實例方法。方法調用的參數可以通過設置args屬性來指定。

3.15.?從一個web應用創建ApplicationContext

與BeanFactory總是以編程的方式創建相反，ApplicationContext可以通過使用比如ContextLoader聲明式地被創建。當然你也可以用ApplicationContext的任一種實現來以編程的方式創建它。首先，我們來看看ContextLoader以及它的實現。

ContextLoader有兩個實現：ContextLoaderListener和ContextLoaderServlet。它們兩個有著同樣的功能，除了listener不能在Servlet 2.2兼容的容器中使用。自從Servelt 2.4規范，listener被要求在web應用啟動后初始化。很多2.3兼容的容器已經實現了這個特性。使用哪一個取決于你自己，但是如果所有的條件都一樣，你大概會更喜歡ContextLoaderListener；關于兼容方面的更多信息可以參照ContextLoaderServlet的JavaDoc。

你可以象下面這樣用ContextLoaderListener注冊一個ApplicationContext：

<context-param><param-name>contextConfigLocation</param-name><param-value>/WEB-INF/daoContext.xml /WEB-INF/applicationContext.xml</param-value> </context-param><listener><listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener>

這個listener需要檢查contextConfigLocation參數。如果不存在的話，它將默認使用/WEB-INF/applicationContext.xml。如果它存在，它就會用預先定義的分隔符（逗號，分號和空格）分開分割字符串，并將這些值作為應用上下文將要搜索的位置。ContextLoaderServlet可以用來替換ContextLoaderListener。這個servlet像listener那樣使用contextConfigLocation參數。

3.16.?粘合代碼和罪惡的singleton

一個應用中的大多數代碼最好寫成依賴注射（反向控制）的風格，這樣這些代碼就和BeanFactory容器或者ApplicationContext容器無關，它們在被創建的時候從容器處得到自己的依賴，并且完全不知道容器的存在。然而，對于少量需要與其它代碼粘合的粘合層代碼來說，有時候就需要以一種singleton（或者類似singleton）的方式來訪問BeanFactory或ApplicationContext。舉例來說，第三方的代碼可能想要（以Class.forName()的方式）直接構造一個新的對象，卻沒辦法從BeanFactory中得到這些對象。如果第三方代碼構造的對象只是一個小的stub或proxy，并且使用singleton方式訪問BeanFactroy/ApplicationContext來獲得真正的對象，大多數的代碼（由BeanFactory產生的對象）仍然可以使用反向控制。因此大多數的代碼依然不需要知道容器的存在，或者容器是如何被訪問的，并保持和其它代碼解耦，有著所有該有的益處。EJB也可以使用這種stub/proxy方案代理到一個普通的BeanFactory產生的java實現的對象。雖然理想情況下BeanFactory不需要是一個singleton，但是如果每個bean使用它自己的non-singleton的BeanFactory，對于內存使用或初始化次數都是不切實際。

另一個例子，在一個多層的復雜的J2EE應用中（比如有很多JAR，EJB，以及WAR打包成一個EAR），每一層都有自己的ApplicationContext定義（有效地組成一個層次結構），如果頂層只有一個web-app（WAR）的話，比較好的做法是創建一個由不同層的XML定義文件組成的組合ApplicationContext。所有的ApplicationContext變體都可以從多個定義文件以這種方式構造出來。但是，如果在頂層有多個兄弟web-apps，為每一個web-app創建一個ApplicationContext，但是每個ApplicationContext都包含大部分相同的底層的bean定義，這就會因為內存使用而產生問題，因為創建bean的多個copy會花很長時間初始化（比如Hibernate SessionFactory），以及其它可能產生的副作用。作為替換，諸如ContextSingletonBeanFactoryLocator和SingletonBeanFactoryLocator的類可以在需要的時候以有效的singleton方式，加載多個層次的（比如一個是另一個的父親）BeanFactory或ApplicationContext，這些將會作為web-app ApplicationContext的parents。這樣做的結果就是，底層的bean定義只在需要的時候加載并且只被加載一次。

3.16.1.?使用SingletonBeanFactoryLocator和ContextSingletonBeanFactoryLocator

你可以查看SingletonBeanFactoryLocator和ContextSingletonBeanFactoryLocator的JavaDoc來獲得詳細的使用例子。

正如在EJB那一章提到的，Spring為EJB提供的方便的基類一般使用一個non-singleton的BeanFactoryLocator實現，這個可以在需要的時候被SingletonBeanFactoryLocator和ContextSingletonBeanFactoryLocator替換。

^[1]?See?第?3.3.1?節 “設置bean的屬性和合作者”

from:?http://docs.huihoo.com/spring/zh-cn/beans.html

總結

以上是生活随笔為你收集整理的Spring - Java/J2EE Application Framework 应用框架第 3 章 Beans, BeanFactory和ApplicationContext的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： Spring - Java/J2EE A
下一篇： Spring - Java/J2EE A