空間站

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

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

注意：正如我們已經(jīng)提到過的，對于大型的應(yīng)用，自動裝配不鼓勵使用，因?yàn)樗コ四愕暮献黝惖耐该餍院徒Y(jié)構(gòu)。

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

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

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

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

<bean  >
<property ><value>parent</value></property>
<property ><value>1</value></property>
</bean>
<bean
parent="inheritedTestBean" init-method="initialize">
<property ><value>override</value></property>
<!-- age should inherit value of 1 from parent -->
</bean>

這個父bean就無法自己實(shí)例化；它實(shí)際上僅僅是一個純模版或抽象bean，充當(dāng)子定義的父定義。 若要嘗試單獨(dú)使用這樣的父bean（比如將它作為其他bean的ref屬性而引用，或者直接使用這個父 bean的id調(diào)用getBean()方法），將會導(dǎo)致一個錯誤。同樣地，容器內(nèi)部的preInstantiateSingletons方法會完全忽略這種既沒有parent屬性也沒有class屬性的bean定義，因?yàn)樗鼈兪遣煌暾摹?

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

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

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

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

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

有一點(diǎn)很重要，BeanFactory和ApplicationContext對待bean post-processor有少許不同。 一個ApplicationContext會自動監(jiān)測到任何部署在它之上的實(shí)現(xiàn)了 BeanPostProcessor接口的bean， 并且把它們作為post-processor注冊，然后factory就會在bean創(chuàng)建的時候恰當(dāng)?shù)卣{(diào)用它們。 部署一個post-processor同部屬一個其他的bean并沒有什么區(qū)別。而另一方面，當(dāng)使用普通的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
...

因?yàn)槭止さ淖圆皇呛芊奖悖褹pplicationContext是BeanFactory功能上擴(kuò)展，所以通常建議當(dāng)需要post-processor的時候最好使用ApplicationContext。

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

在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將會檢測它所部署的實(shí)現(xiàn)了BeanFactoryPostProcessor 接口的bean，然后在適當(dāng)?shù)臅r候?qū)⑺鼈冏鳛閎ean factory post-processor而使用。部署這些post-processor與部署其他的bean并沒有什么區(qū)別。

因?yàn)檫@個手動的步驟并不方便，而且ApplicationContext是BeanFactory的功能擴(kuò)展，所以當(dāng)需要使用bean factory post-processor的時候通常建議使用ApplicationContext

<bean   destroy-method="close">
<property ><value>${jdbc.driverClassName}</value></property>
<property ><value>${jdbc.url}</value></property>
<property ><value>${jdbc.username}</value></property>
<property ><value>${jdbc.password}</value></property>
</bean>

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

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

beanName.property=value

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

當(dāng)用字符串值設(shè)置bean的屬性時，BeanFactory實(shí)質(zhì)上使用了標(biāo)準(zhǔn)的JavaBeans 的PropertyEditor將這些String轉(zhuǎn)換為屬性的復(fù)雜類型。Spring預(yù)先注冊了很多定制的PropertyEditor（比如，將一個字符串表示的classname轉(zhuǎn)換成真正的Class對象）。另外，一個類的PropertyEditor如果被恰當(dāng)?shù)孛⑶曳旁谂c它提供支持的類同一個包內(nèi)，那么Java標(biāo)準(zhǔn)的JavaBeans PropertyEditor查找機(jī)制就會自動找到這個PropertyEditor。

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

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

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

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

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

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

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

<beans>
<bean
>
<property >
<list>
<value>format</value>
<value>exceptions</value>
<value>windows</value>
</list>
</property>
</bean>
</beans> 

<bean  >
<property >
<list>
<value>black@list.org</value>
<value>white@list.org</value>
<value>john@doe.org</value>
</list>
</property>
</bean>
<bean  >
<property >
<value>spam@list.org</value>
</property>
</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
}
}
}

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

<!-- property placeholder post-processor -->
<bean
>
<property ><value>jdbc.properties</value></property>
</bean>

正如前面曾提到的，Spring使用標(biāo)準(zhǔn)的JavaBeans的PropertyEditor將字符串形式表示的屬性值轉(zhuǎn)換為屬性真實(shí)的復(fù)雜的類型。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;
}
}

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

<bean  >
<property ><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
>
<property >
<map>
<entry key="example.ExoticType">
<bean >
<property >
<value>upperCase</value>
</property>
</bean>
</entry>
</map>
</property>
</bean>

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

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

<bean  >
<property ><value>com.whatever.MyClassFactory.getInstance</value></property>
</bean>

下面這個例子先調(diào)用一個靜態(tài)方法，然后調(diào)用一個實(shí)例方法，來獲得一個Java System的屬性。雖然有點(diǎn)羅嗦，但是可以工作：

<bean  >
<property ><value>java.lang.System</value></property>
<property ><value>getProperties</value></property>
</bean>
<bean  >
<property ><ref local="sysProps"/></property>
<property ><value>getProperty</value></property>
<property >
<list>
<value>java.version</value>
</list>
</property>
</bean>

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

通過設(shè)置targetMethod屬性為一個靜態(tài)方法名的字符串來指定靜態(tài)目標(biāo)方法，而設(shè)置targetClass為定義靜態(tài)方法的類。或者，通過設(shè)置targetObject屬性目標(biāo)對象，設(shè)置targetMethod屬性要在目標(biāo)對象上調(diào)用的方法名，來指定目標(biāo)實(shí)例方法。方法調(diào)用的參數(shù)可以通過設(shè)置args屬性來指定。

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

ContextLoader有兩個實(shí)現(xiàn)：ContextLoaderListener和ContextLoaderServlet。它們兩個有著同樣的功能，除了listener不能在Servlet 2.2兼容的容器中使用。自從Servelt 2.4規(guī)范，listener被要求在web應(yīng)用啟動后初始化。很多2.3兼容的容器已經(jīng)實(shí)現(xiàn)了這個特性。使用哪一個取決于你自己，但是如果所有的條件都一樣，你大概會更喜歡ContextLoaderListener；關(guān)于兼容方面的更多信息可以參照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>
<!-- OR USE THE CONTEXTLOADERSERVLET INSTEAD OF THE LISTENER
<servlet>
<servlet-name>context</servlet-name>
<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
-->

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

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

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