空間站

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

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

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

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

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

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

當以編程的方式使用一個BeanFactory，子bean定義用ChildBeanDefinition類表示。 大多數的用戶從來不需要以這個方式使用它們，而是在類似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就無法自己實例化；它實際上僅僅是一個純模版或抽象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（以及其他可能的容器）將會預實例化它。

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個方法：

一個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。

一個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

<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

當用字符串值設置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的方式被部署，并且被自動監測和應用。

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

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

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

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

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

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

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

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

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

<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>

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

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

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

一個應用中的大多數代碼最好寫成依賴注射（反向控制）的風格，這樣這些代碼就和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定義只在需要的時候加載并且只被加載一次。