beans包提供了以編程方式管理和操作bean的基本功能 而context包增加了ApplicationContext 它以壹種更加面向框架的方式增強了BeanFactory的功能
context包的基礎是位於ntext包中的ApplicationContext接口 它是由BeanFactory接口派生而來的 提供了BeanFactory的所有功能 為了以壹種更面向框架的方式工作 使用分層和繼承關系的上下文 context包還提供了壹下的功能
a MessageSource 對I N消息的訪問
b 資源訪問 例如URL和文件
c 事件傳遞給是吸納了ApplicationListener接口的bean
d 載入多個(有繼承關系）上下文 使得每壹個上下文都專註於壹個特定的層是 比如應用的web層
國際化支持
ApplicationContext擴展了MessageSource接口 因而提供了messaging的功能(I N或者國際化) 同NestingMessageSource壹起使用 還能處理分級的信息 這些是spring提供的處理信息的基本接口
當壹個ApplicationContext被加載時 它會自動查找在context中定義的MessageSource bean 這個bean必須交做messageSource 如果找了這樣壹個bean 所有對上述方法的調用將被委托給找到的messageSource 如果沒有找到messageSource ApplicationContext將會嘗試查找他的父親是否包含有同名的bean 如果有 它將把找到的bean作為MessageSource 如果他沒有找到任何的信息處理源 他會創建壹個StaticMessageSource
Spring目前提供了兩個MessageSource的實現 他們是
ResourceBundleMessageSource和StaticMessageSource 兩者都實現了NestingMessageSource壹邊能夠處理嵌套的信息 StaticMessageSource很少被使用 但是他提供了編程的方式向source增加信息 我們經常使用的是ResourceBundleMessageSource
在Spring中使用資源
ApplicationContext繼承了ResourceLoader接口 在這個接口中 定義了getResource()方法 如下
Resource getResource(String location)
該方法返回壹個資源句柄 這個句柄應該總是壹個可重復使用的資源描述符 允許多次調用getInputStream();
getResource()方法的參數是壹個資源訪問地址 例如
file:\c:/test data
classpath:test data(從classpath路徑中查找test dat文件並返回他的資源句柄)
WEB INF/test dat
註意 getResource()方法返回的Resource句柄並不意味著資源實際存在 妳需要調用Resource接口的exists()方法判斷資源是否存在
Resource提供了與協議無關的特性
事件傳遞
ApplicationContext中的時間處理是通過AppcationEvent類和ApplicationListener接口來提供的 如果上下文中部署了壹個實現了ApplicationListener接口的bean 每次壹個ApplicationEvent發布到ApplicationContext時 那個bean就會被通知 實質撒謊功能 這是標準的Observer設計模式
Spring提供的三個標準事件
a ContextRefreshedEvent
當ApplicationContext已經初始化或刷新後發送的事件 這裏初始化意味著 所有的bean被裝載 singleton被預實例化 以及ApplicationContext已經準備好
b ContextClosedEvent
當使用ApplicationContext的close()方法結束上下文的時候發送的事件 這裏意味著 singleton被銷毀
c RequestHandledEvent
壹個與web相關的事件 告訴所有的bean壹個HTTP請求已經被響應了（這個時間將會在壹個請求結束後被發送—) 註意 這個時間只能應用於使用了Spring的DispatcherServlet的web應用
=========================================================================================
LifeCycle
InitializingBean/init method
實現 springframework beans factory InitializingBean接口允許壹個bean在他的所有必需的屬性被BeanFactory設置後 來執行初始化的工作
當然可以使用init method來取代實現這個接口 以讓應用不與sprin *** 生耦合
如果壹個bean既實現了InitializingBean 又指定了init method 則spring會先調InitializingBean的方法 在調init method指定的方法
DisposableBean/destroy method
實現 springframework beans factory DisposableBean接口允許壹個bean 可以在包含他的BeanFactory銷毀的時候得到壹個回調
註意 BeanFactory對bean的管理默認是單實例的 如果bean不是單示例的 spring就不能管理他的生命周期
BeanFactoryAware
對於實現了 springframework beans factory BeanFactoryAware接口的類 當它被BeanFactory創建後 它會擁有壹個指向創建他的BeanFactory的引用
BeanNameAware
如果壹個bean實現了 springframework beans factory BeanNameAware接口 並且被部署到壹個BeanFactory中 那麽BeanFactory就會通過這個接口來調用bean 以便通知這個bean他被部署的id 這個回調發生在普通的bean屬性設置之後 在初始化回調之前 比如InitializingBean的afterProperteis方法（或者自定義的init method)
Bean的生命周期如下
Bean的構造
調用setXXX()方法設置Bean的屬性
調用BeanNameAware的setBeanName();
調用BeanFactoryAware的setBeanFactory()方法
調用BeanPostProcessor的postProcessBeforeInitialization()方法
調用InitializingBean的afterPropertiesSet()方法
調用自定義的初始化方法
調用BeanPostProcessor類的postProcessAfterInitialization()方法
調用DisposableBean的destroy()方法
調用自定義的銷毀方法
========================================================================================
擴展Spring的Ioc框架
Spring框架的IoC組件被設計為可擴展的 通常應用開發者並不需要子類化各個BeanFactory或ApplicationContext的實現類 通過插入特定接入接口的實現 Spring的IoC容器就可以不受限制的進行擴展
BeanPostProcessor:在創建bean之後調用
BeanFactoryPostProcessors 在創建bean之前調用
如果想在spring容器完成壹個bean的實例化後 再對他進行初始化之前或之後執行壹些自定義的邏輯 可以插入壹個或多個BeanPostProcessor的實例
springframewonfig BeanPostProcessor接口包含了兩個回調方法 當壹個類作為容器的後置處理器(post processor）被註冊後 對於由容器創建的每個bean實例 在任壹個初始化方法（例如afterProperties和利用init method聲明的方法）調用前後後置處理器會從容器中分別獲取壹個回調 後置處理器可以隨意對這個bean實例執行他所期望的動作 也包括完全忽略這個回調
BeanFactory和ApplicationContext對待bean後置處理器稍有不同
ApplicationContext會自動檢測任何提供給他的在配置元數據中定義實現了BeanPostProcessor接口的bean 並把它們註冊為後置處理器 然後在容器創建bean的適當時候調用它 部署壹個後置處理器同部署其他的bean並沒有什麽區別 無需其他的動作 而另壹方面 當使用BeanFactory的時候 bean後置處理器鼻息編寫代碼顯示的去註冊
我們看到的下壹個擴展點是
springframewonfig BeanFactoryPostProcessor 出壹個主要的區別外 這個接口的寓意類似於BeanPostProcessor BeanFactoryPostProcessor作用於bean的定義上（例如 提供給容易的配置元數據） 也就是說 Spring IoC容器允許BeanFactoryPostProcessor在容易實際實例化任何bean之前讀取配置元數據並可能修改它
Spring包含了許多已有的bean工廠後置處理器 例如PropertyResourceConfigure和PropertyPlaceHolderConfigure以及? BeanNameAutoProxyCreator
在壹個BeanFactory中 應用BeanFactoryPostProcessor需要手工編碼實現 而ApplicationContext則會檢測部署在它之上實現了BeanFactoryPostProcessor接口的bean 並在適當的時候自動把它們用做bean工作後置處理器 部署壹個後置處理器同部署其他的bean並沒有什麽區別 無需其他的動作
PropertyPlaceholderConfigurer
作為壹個bean工廠後置處理器的實現 可以用來將BeanFactory定義中的壹些屬性值放置到另壹個單獨的Java Properties格式的文件中 這就允許用戶在部署應用的時候定制壹些關鍵屬性（例如數據庫URL 用戶名和密碼） 而不用對主XML定義文件或容器所用文件進行復雜和危險的修改
PropertyOverrideConfigurer
類似於PropertyPlaceholderConfigurer 但是與後者相比 前者對於bean屬性可以有卻興致或者根本沒有值 如果起覆蓋左右的Properties文件沒有某個bean屬性的內容 那麽將使用卻行的上下文定義
bean工廠的定義並不會議室到被覆蓋 所以僅僅擦看XML定義文件並不能立刻明顯的知道覆蓋配置是否被起作用了 在多個PropertyOverrideConfigurer對壹個bean屬性定義了不同的值的時候 最後壹個將取勝
***他使用beanName propertyName來指定值 而且不需要在bean中進行配置
註冊用戶自定義的PropertyEditors
a 當用字符串值設置bean的屬性時 BeanFactory實質上使用了標準的JavaBeans的PropertyEditor將這些String轉換為屬性的復雜類型 Spring預先註冊了很多定制的PropertyEditor（比如 將壹個字符串表示我的classname轉換成陣陣的Class對象）
b 要編寫壹個屬性編輯器 可以實現PropertyEditor接口 更為簡便的方式是從PropertyEditorSupport類繼承
要使用自定義的PropertyEditors 必須使用 springframewonfig CustomEditorConfigurer來註冊自定義的屬性編輯器
FactoryBean可以用來做代理
springframework beans factory FactoryBean
**要想得到FactoryBean本身 需要在beanName前面加上& 即&beanName
*********BeanFactory和ApplicationContext的區別*********
ApplicationContext是在ApplicationContext初始化的時候就把所有的bean都創建好了 並存放在緩存中
lishixinzhi/Article/program/Java/ky/201311/28565