Spring建立Bean的過程 【摘抄】

1. beans包提供了以編程方式管理和操作bean的準系統，而context包增加了ApplicationContext,它以一種更加面向架構的方式增強了BeanFactory的功能。

2. context包的基礎是位於org.springframework.context包中的ApplicationContext介面。它是由 BeanFactory介面派生而來的，提供了BeanFactory的所有功能。為了以一種更面向架構的方式工作，使用分層和繼承關係的上下文，context包還提供了一下的功能。

a. MessageSource,對I18N訊息的訪問。

b. 資源訪問，例如URL和檔案

c. 事件傳遞給是吸納了ApplicationListener介面的bean

d. 載入多個(有繼承關係）上下文，使得每一個上下文都專註於一個特定的層是，比如應用的web層。

國際化支援

1. ApplicationContext擴充了MessageSource介面，因而提供了messaging的功能(I18N或者國際化)。同 NestingMessageSource一起使用，還能處理分級的資訊，這些是spring提供的處理資訊的基本介面。

2. 當一個ApplicationContext被載入時，它會自動尋找在context中定義的MessageSource bean。這個bean必須交做messageSource.如果找了這樣一個bean,所有對上述方法的調用將被委託給找到的 messageSource。如果沒有找到messageSource,ApplicationContext將會嘗試尋找他的父親是否包含有同名的 bean。如果有，它將把找到的bean作為MessageSource.如果他沒有找到任何的資訊處理源，他會建立一個 StaticMessageSource。

3. Spring目前提供了兩個MessageSource的實現，他們是

ResourceBundleMessageSource和StaticMessageSource.兩者都實現了 NestingMessageSource一邊能夠處理嵌套的資訊。StaticMessageSource很少被使用，但是他提供了編程的方式向 source增加資訊，我們經常使用的是ResourceBundleMessageSource.

在Spring中使用資源

1. ApplicationContext繼承了ResourceLoader介面，在這個介面中，定義了getResource()方法，如下：

Resource getResource(String location)

該方法返回一個資源控制代碼。這個控制代碼應該總是一個可重複使用的資源描述符，允許多次調用getInputStream();

2. getResource()方法的參數是一個資源訪問地址，例如：

file:\c:/test.data

classpath:test.data(從classpath路徑中尋找test.dat檔案並返回他的資源控制代碼)

WEB-INF/test.dat

注意：getResource()方法返回的Resource控制代碼並不意味著資源實際存在，你需要調用Resource介面的exists()方法判斷資源是否存在。

Resource提供了與協議無關的特性。
事件傳遞

1. ApplicationContext中的時間處理是通過AppcationEvent類和ApplicationListener介面來提供的。如果上下文中部署了一個實現了ApplicationListener介面的bean,每次一個ApplicationEvent發布到 ApplicationContext時，那個bean就會被通知。實質撒謊功能，這是標準的Observer設計模式。

2. Spring提供的三個標準事件

a. ContextRefreshedEvent

當ApplicationContext已經初始化或重新整理後發送的事件。這裡初始化意味著：所有的bean被裝載，singleton被預執行個體化，以及ApplicationContext已經準備好。

b. ContextClosedEvent

當使用ApplicationContext的close()方法結束內容相關的時候發送的事件。這裡意味著：singleton被銷毀。

c. RequestHandledEvent

一個與web相關的事件，告訴所有的bean一個HTTP請求已經被響應了（這個時間將會在一個請求結束後被發送—)。注意，這個時間只能應用於使用了Spring的DispatcherServlet的web應用。

===================================

LifeCycle

1. InitializingBean/init-method

實現org.springframework.beans.factory.InitializingBean介面允許一個bean在他的所有必需的屬性被BeanFactory設定後，來執行初始化的工作。

當然可以使用init-method來取代實現這個介面，以讓應用不與spring產生耦合。

如果一個bean既實現了InitializingBean，又指定了init-method,則spring會先調InitializingBean的方法，在調init-method指定的方法。

2. DisposableBean/destroy-method

實現org.springframework.beans.factory.DisposableBean介面允許一個bean，可以在包含他的BeanFactory銷毀的時候得到一個回調。

注意：BeanFactory對bean的管理預設是單一實例的，如果bean不是單樣本的，spring就不能管理他的生命週期。
3. BeanFactoryAware

對於實現了org.springframework.beans.factory.BeanFactoryAware介面的類，當它被BeanFactory建立後，它會擁有一個指向建立他的BeanFactory的引用。

4. BeanNameAware

如果一個bean實現了org.springframework.beans.factory.BeanNameAware介面，並且被部署到一個BeanFactory中，那麼BeanFactory就會通過這個介面來調用bean,以便通知這個bean他被部署的id。這個回調發生在普通的 bean屬性設定之後，在初始化回調之前，比如InitializingBean的afterProperteis方法（或者自訂的init- method)。

Bean的生命週期如下

1. Bean的構造

2. 調用setXXX()方法設定Bean的屬性

3. 調用BeanNameAware的setBeanName();

4. 調用BeanFactoryAware的setBeanFactory()方法

5. 調用BeanPostProcessor的postProcessBeforeInitialization()方法

6. 調用InitializingBean的afterPropertiesSet()方法

7. 調用自訂的初始化方法

8. 調用BeanPostProcessor類的postProcessAfterInitialization()方法

9. 調用DisposableBean的destroy()方法

10. 調用自訂的銷毀方法。

================================

擴充Spring的Ioc架構

Spring架構的IoC組件被設計為可擴充的。通常應用開發人員並不需要子類化各個BeanFactory或ApplicationContext的實作類別，通過插入特定接入介面的實現，Spring的IoC容器就可以不受限制的進行擴充。

BeanPostProcessor:在建立bean之後調用

BeanFactoryPostProcessors：在建立bean之前調用
1. 如果想在spring容器完成一個bean的執行個體化後，再對他進行初始化之前或之後執行一些自訂的邏輯，可以插入一個或多個BeanPostProcessor的執行個體。

2. org.springframework.beans.factory.config.BeanPostProcessor介面包含了兩個回調方法。當一個類作為容器的後置處理器(post-processor）被註冊後，對於由容器建立的每個bean執行個體，在任一個初始化方法（例如 afterProperties和利用init-method聲明的方法）調用前後後置處理器會從容器中分別擷取一個回調。後置處理器可以隨意對這個 bean執行個體執行他所期望的動作，也包括完全忽略這個回調。

3.BeanFactory和ApplicationContext對待bean後置處理器稍有不同。

ApplicationContext會自動檢測任何提供給他的在配置中繼資料中定義實現了BeanPostProcessor介面的bean, 並把它們註冊為後置處理器，然後在容器建立bean的適當時候調用它。部署一個後置處理器同部署其他的bean並沒有什麼區別，無需其他的動作。而另一方面，當使用BeanFactory的時候，bean後置處理器鼻息編寫代碼顯示的去註冊。

4. 我們看到的下一個擴充點是：

org.springframework.beans.factory.config.BeanFactoryPostProcessor。出一個主要的區別外，這個介面的寓意類似於BeanPostProcessor。BeanFactoryPostProcessor作用於bean的定義上（例如：提供給容易的配置中繼資料）；也就是說，Spring IoC容器允許BeanFactoryPostProcessor在容易實際執行個體化任何bean之前讀取配置中繼資料並可能修改它。

5. Spring包含了許多已有的bean工廠後置處理器，例如PropertyResourceConfigure和PropertyPlaceHolderConfigure以及   BeanNameAutoProxyCreator。

6. 在一個BeanFactory中，應用BeanFactoryPostProcessor需要手工編碼實現。而ApplicationContext則會檢測部署在它之上實現了BeanFactoryPostProcessor介面的bean,並在適當的時候自動把它們用做bean工作後置處理器。部署一個後置處理器同部署其他的bean並沒有什麼區別，無需其他的動作。

7. PropertyPlaceholderConfigurer

作為一個bean工廠後置處理器的實現，可以用來將BeanFactory定義中的一些屬性值放置到另一個單獨的Java Properties格式的檔案中。這就允許使用者在部署應用的時候定製一些關鍵屬性（例如資料庫URL，使用者名稱和密碼），而不用對主XML定義檔案或容器所用檔案進行複雜和危險的修改。

8. PropertyOverrideConfigurer

類似於PropertyPlaceholderConfigurer，但是與後者相比，前者對於bean屬性可以有卻興緻或者根本沒有值。如果起覆蓋左右的Properties檔案沒有某個bean屬性的內容，那麼將使用卻行的上下文定義。

bean工廠的定義並不會議室到被覆蓋，所以僅僅擦看XML定義檔案並不能立刻明顯的知道覆蓋配置是否被起作用了。在多個PropertyOverrideConfigurer對一個bean屬性定義了不同的值的時候，最後一個將取勝。

***他使用beanName.propertyName來指定值，而且不需要在bean中進行配置。

9. 註冊使用者自訂的PropertyEditors

a.當用字串值設定bean的屬性時，BeanFactory實質上使用了標準的JavaBeans的PropertyEditor將這些 String轉換為屬性的複雜類型。Spring預先註冊了很多定製的PropertyEditor（比如,將一個字串表示我的classname轉換成陣陣的Class對象）

b. 要編寫一個屬性編輯器，可以實現PropertyEditor介面，更為簡便的方式是從PropertyEditorSupport類繼承。

要使用自訂的PropertyEditors，必須使用org.springframework.beans.factory.config.CustomEditorConfigurer來註冊自訂的屬性編輯器。

10. FactoryBean可以用來做代理。

org.springframework.beans.factory.FactoryBean

**要想得到FactoryBean本身，需要在beanName前面加上&,即&beanName.

*********BeanFactory和ApplicationContext的區別*********

ApplicationContext是在ApplicationContext初始化的時候就把所有的bean都建立好了，並存放在緩衝中。

BeanFactory是在需要得到bean的時候才去建立他的執行個體