空間站

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有一點(diǎn)很重要，BeanFactory和ApplicationContext對(duì)待bean post-processor有少許不同。 一個(gè)ApplicationContext會(huì)自動(dòng)監(jiān)測(cè)到任何部署在它之上的實(shí)現(xiàn)了 BeanPostProcessor接口的bean， 并且把它們作為post-processor注冊(cè)，然后factory就會(huì)在bean創(chuàng)建的時(shí)候恰當(dāng)?shù)卣{(diào)用它們。 部署一個(gè)post-processor同部屬一個(gè)其他的bean并沒有什么區(qū)別。而另一方面，當(dāng)使用普通的BeanFactory的時(shí)候， 作為post-processor的bean必須通過類似下面的代碼來手動(dòng)地顯式地注冊(cè)：

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)槭止さ淖?cè)不是很方便，而且ApplicationContext是BeanFactory功能上擴(kuò)展，所以通常建議當(dāng)需要post-processor的時(shí)候最好使用ApplicationContext。

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

在BeanFactory中，使用BeanFactoryPostProcessor是手動(dòng)的，將類似于下面:

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

因?yàn)檫@個(gè)手動(dòng)的步驟并不方便，而且ApplicationContext是BeanFactory的功能擴(kuò)展，所以當(dāng)需要使用bean factory post-processor的時(shí)候通常建議使用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的屬性時(shí)，BeanFactory實(shí)質(zhì)上使用了標(biāo)準(zhǔn)的JavaBeans 的PropertyEditor將這些String轉(zhuǎn)換為屬性的復(fù)雜類型。Spring預(yù)先注冊(cè)了很多定制的PropertyEditor（比如，將一個(gè)字符串表示的classname轉(zhuǎn)換成真正的Class對(duì)象）。另外，一個(gè)類的PropertyEditor如果被恰當(dāng)?shù)孛⑶曳旁谂c它提供支持的類同一個(gè)包內(nèi)，那么Java標(biāo)準(zhǔn)的JavaBeans PropertyEditor查找機(jī)制就會(huì)自動(dòng)找到這個(gè)PropertyEditor。

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

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

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

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

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

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

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

<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中，這些也同樣可以工作，但同時(shí)也增加了一些用于定制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，這個(gè)bean factory post-processor可以使ApplicationContext很方便地增加對(duì)額外的PropertyEditor的支持。

考慮一個(gè)用戶類ExoticType，以及另外一個(gè)需要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è)置好的時(shí)候，我們希望能夠以字符串的形式指定屬性，同時(shí)背后的PropertyEditor會(huì)將這個(gè)字符串轉(zhuǎn)換為一個(gè)真正的Exotic類型的對(duì)象：

<bean  >
<property ><value>aNameForExoticType</value></property>
</bean>

而這個(gè)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注冊(cè)到ApplicationContext上，然后ApplicationContext就可以在需要的時(shí)候使用這個(gè)PropertyEditor了：

<bean
>
<property >
<map>
<entry key="example.ExoticType">
<bean >
<property >
<value>upperCase</value>
</property>
</bean>
</entry>
</map>
</property>
</bean>

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

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

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

下面這個(gè)例子先調(diào)用一個(gè)靜態(tài)方法，然后調(diào)用一個(gè)實(shí)例方法，來獲得一個(gè)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í)際上這個(gè)類多半用來訪問工廠方法，所以MethodInvokingFactoryBean默認(rèn)以singleton方式進(jìn)行操作。經(jīng)由容器的第一次請(qǐng)求工廠生成對(duì)象將會(huì)引起調(diào)用特定的工廠方法，它的返回值將會(huì)被緩存并且返回供這次請(qǐng)求和以后的請(qǐng)求使用。這個(gè)工廠的一個(gè)內(nèi)部singleton屬性可以被設(shè)置為false，從而導(dǎo)致每次對(duì)象的請(qǐng)求都會(huì)調(diào)用那個(gè)目標(biāo)方法。

通過設(shè)置targetMethod屬性為一個(gè)靜態(tài)方法名的字符串來指定靜態(tài)目標(biāo)方法，而設(shè)置targetClass為定義靜態(tài)方法的類。或者，通過設(shè)置targetObject屬性目標(biāo)對(duì)象，設(shè)置targetMethod屬性要在目標(biāo)對(duì)象上調(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有兩個(gè)實(shí)現(xiàn)：ContextLoaderListener和ContextLoaderServlet。它們兩個(gè)有著同樣的功能，除了listener不能在Servlet 2.2兼容的容器中使用。自從Servelt 2.4規(guī)范，listener被要求在web應(yīng)用啟動(dòng)后初始化。很多2.3兼容的容器已經(jīng)實(shí)現(xiàn)了這個(gè)特性。使用哪一個(gè)取決于你自己，但是如果所有的條件都一樣，你大概會(huì)更喜歡ContextLoaderListener；關(guān)于兼容方面的更多信息可以參照ContextLoaderServlet的JavaDoc。

你可以象下面這樣用ContextLoaderListener注冊(cè)一個(gè)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>
-->

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

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

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