- Spring技術(shù)內(nèi)幕：深入解析Spring架構(gòu)與設(shè)計原理（第2版）
- 計文柯
- 7327字
- 2018-12-31 19:55:37
2.3 IoC容器的初始化過程
簡單來說，IoC容器的初始化是由前面介紹的refresh()方法來啟動的，這個方法標志著IoC容器的正式啟動。具體來說，這個啟動包括BeanDefinition的Resouce定位、載入和注冊三個基本過程。如果我們了解如何編程式地使用IoC容器，就可以清楚地看到Resource定位和載入過程的接口調(diào)用。在下面的內(nèi)容里，我們將會詳細分析這三個過程的實現(xiàn)。
在分析之前，要提醒讀者注意的是，Spring把這三個過程分開，并使用不同的模塊來完成，如使用相應(yīng)的ResourceLoader、BeanDefinitionReader等模塊，通過這樣的設(shè)計方式，可以讓用戶更加靈活地對這三個過程進行剪裁或擴展，定義出最適合自己的IoC容器的初始化過程。
第一個過程是Resource定位過程。這個Resource定位指的是BeanDefinition的資源定位，它由ResourceLoader通過統(tǒng)一的Resource接口來完成，這個Resource對各種形式的BeanDefinition的使用都提供了統(tǒng)一接口。對于這些BeanDefinition的存在形式，相信大家都不會感到陌生。比如，在文件系統(tǒng)中的Bean定義信息可以使用FileSystemResource來進行抽象；在類路徑中的Bean定義信息可以使用前面提到的ClassPathResource來使用，等等。這個定位過程類似于容器尋找數(shù)據(jù)的過程，就像用水桶裝水先要把水找到一樣。
第二個過程是BeanDefinition的載入。這個載入過程是把用戶定義好的Bean表示成IoC容器內(nèi)部的數(shù)據(jù)結(jié)構(gòu)，而這個容器內(nèi)部的數(shù)據(jù)結(jié)構(gòu)就是BeanDefinition。下面介紹這個數(shù)據(jù)結(jié)構(gòu)的詳細定義。具體來說，這個BeanDefinition實際上就是POJO對象在IoC容器中的抽象，通過這個BeanDefinition定義的數(shù)據(jù)結(jié)構(gòu)，使IoC容器能夠方便地對POJO對象也就是Bean進行管理。在下面的章節(jié)中，我們會對這個載入的過程進行詳細的分析，使大家對整個過程有比較清楚的了解。
第三個過程是向IoC容器注冊這些BeanDefinition的過程。這個過程是通過調(diào)用BeanDefinitionRegistry接口的實現(xiàn)來完成的。這個注冊過程把載入過程中解析得到的BeanDefinition向IoC容器進行注冊。通過分析，我們可以看到，在IoC容器內(nèi)部將BeanDefinition注入到一個HashMap中去，IoC容器就是通過這個HashMap來持有這些BeanDefinition數(shù)據(jù)的。
值得注意的是，這里談的是IoC容器初始化過程，在這個過程中，一般不包含Bean依賴注入的實現(xiàn)。在Spring IoC的設(shè)計中，Bean定義的載入和依賴注入是兩個獨立的過程。依賴注入一般發(fā)生在應(yīng)用第一次通過getBean向容器索取Bean的時候。但有一個例外值得注意，在使用IoC容器時有一個預(yù)實例化的配置，通過這個預(yù)實例化的配置（具體來說，可以通過為Bean定義信息中的lazyinit屬性），用戶可以對容器初始化過程作一個微小的控制，從而改變這個被設(shè)置了lazyinit屬性的Bean的依賴注入過程。舉例來說，如果我們對某個Bean設(shè)置了lazyinit屬性，那么這個Bean的依賴注入在IoC容器初始化時就預(yù)先完成了，而不需要等到整個初始化完成以后，第一次使用getBean時才會觸發(fā)。
了解了IoC容器進行初始化的大致輪廓之后，下面我們詳細地介紹在IoC容器的初始化過程中，BeanDefinition的資源定位、載入和解析過程是怎么實現(xiàn)的。
2.3.1 BeanDefinition的Resource定位
以編程的方式使用DefaultListableBeanFactory時，首先定義一個Resource來定位容器使用的BeanDefinition。這時使用的是ClassPathResource，這意味著Spring會在類路徑中去尋找以文件形式存在的BeanDefinition信息。
ClassPathResource res = new ClassPathResource("beans.xml");
這里定義的Resource并不能由DefaultListableBeanFactory直接使用，Spring通過BeanDefinitionReader來對這些信息進行處理。在這里，我們也可以看到使用Application-Context相對于直接使用DefaultListableBeanFactory的好處。因為在ApplicationContext中，Spring已經(jīng)為我們提供了一系列加載不同Resource的讀取器的實現(xiàn)，而DefaultListableBeanFactory只是一個純粹的IoC容器，需要為它配置特定的讀取器才能完成這些功能。當然，有利就有弊，使用DefaultListableBeanFactory這種更底層的容器，能提高定制IoC容器的靈活性。
回到我們經(jīng)常使用的ApplicationContext上來，例如FileSystemXmlApplicationContext、ClassPathXmlApplicationContext以及XmlWebApplicationContext等。簡單地從這些類的名字上分析，可以清楚地看到它們可以提供哪些不同的Resource讀入功能，比如FileSystemXmlApplicationContext可以從文件系統(tǒng)載入Resource，ClassPathXmlApplication-Context可以從Class Path載入Resource，XmlWebApplicationContext可以在Web容器中載入Resource，等等。
下面以FileSystemXmlApplicationContext為例，通過分析這個ApplicationContext的實現(xiàn)來看看它是怎樣完成這個Resource定位過程的。作為輔助，我們可以在圖2-5中看到相應(yīng)的ApplicationContext繼承體系。
圖2-5 FileSystemXmlApplicationContext的繼承體系
從源代碼實現(xiàn)的角度，我們可以近距離關(guān)心以FileSystemXmlApplicationConext為核心的繼承體系，如圖2-6所示。
圖2-6 源代碼角度的FileSystemXmlApplicationContext的繼承關(guān)系
從圖2-6中可以看到，這個FileSystemXmlApplicationContext已經(jīng)通過繼承Abstract-ApplicationContext具備了ResourceLoader讀入以Resource定義的BeanDefinition的能力，因為AbstractApplicationContext的基類是DefaultResourceLoader。下面讓我們看看FileSystemXmlApplicationContext的具體實現(xiàn)，如代碼清單2-4所示。
代碼清單2-4 FileSystemXmlApplicationContext的實現(xiàn)
public class FileSystemXmlApplicationContext extends AbstractXmlApplicationContext {
public FileSystemXmlApplicationContext() {
}
public FileSystemXmlApplicationContext(ApplicationContext parent) {
super(parent);
}
//這個構(gòu)造函數(shù)的configLocation包含的是BeanDefinition所在的文件路徑
FileSystemXmlApplicationContext(String configLocation) throws BeansException {
this(new String[] {configLocation}, true, null);
}
//這個構(gòu)造函數(shù)允許configLocation包含多個BeanDefinition的文件路徑
public FileSystemXmlApplicationContext(String[] configLocations) throws BeansException {
this(configLocations, true, null);
}
//這個構(gòu)造函數(shù)在允許configLocation包含多個BeanDefinition的文件路徑的同時，還允許指定
//自己的雙親IoC容器
public FileSystemXmlApplicationContext(String[] configLocations, ApplicationContext parent)
throws BeansException {
this(configLocations, true, parent);
}
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh)
throws BeansException {
this(configLocations, refresh, null);
}
//在對象的初始化過程中，調(diào)用refresh函數(shù)載入BeanDefinition，這個refresh啟動了
//BeanDefinition的載入過程，我們會在下面進行詳細分析
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh,
ApplicationContext parent)
throws BeansException {
super(parent);
setConfigLocations(configLocations);
if (refresh) {
refresh();
}
}
//這是應(yīng)用于文件系統(tǒng)中Resource的實現(xiàn)，通過構(gòu)造一個FileSystemResource來得到一個在文件
//系統(tǒng)中定位的BeanDefinition
//這個getResourceByPath是在BeanDefinitionReader的loadBeanDefintion中被調(diào)用的
//loadBeanDefintion采用了模板模式，具體的定位實現(xiàn)實際上是由各個子類來完成的protected Resource getResourceByPath(String path) {
if (path != null && path.startsWith("/")) {
path = path.substring(1);
}
return new FileSystemResource(path);
}
}
在FileSystemApplicationContext中，我們可以看到在構(gòu)造函數(shù)中，實現(xiàn)了對configuration進行處理的功能，讓所有配置在文件系統(tǒng)中的，以XML文件方式存在的BeanDefnition都能夠得到有效的處理，比如，實現(xiàn)了getResourceByPath方法，這個方法是一個模板方法，是為讀取Resource服務(wù)的。對于IoC容器功能的實現(xiàn)，這里沒有涉及，因為它繼承了AbstractXmlApplicationContext，關(guān)于IoC容器功能相關(guān)的實現(xiàn)，都是在FileSystemXmlApplicationContext中完成的，但是在構(gòu)造函數(shù)中通過refresh來啟動IoC容器的初始化，這個refresh方法非常重要，也是我們以后分析容器初始化過程實現(xiàn)的一個重要入口。
注意 FileSystemApplicationContext是一個支持XML定義BeanDefinition的ApplicationContext，并且可以指定以文件形式的BeanDefinition的讀入，這些文件可以使用文件路徑和URL定義來表示。在測試環(huán)境和獨立應(yīng)用環(huán)境中，這個ApplicationContext是非常有用的。
根據(jù)圖2-7的調(diào)用關(guān)系分析，我們可以清楚地看到整個BeanDefinition資源定位的過程。這個對BeanDefinition資源定位的過程，最初是由refresh來觸發(fā)的，這個refresh的調(diào)用是在FileSystemXmlBeanFactory的構(gòu)造函數(shù)中啟動的，大致的調(diào)用過程如圖2-8所示。
圖2-7 getResourceByPath的調(diào)用關(guān)系
圖2-8 getResourceByPath的調(diào)用過程
從Spring源代碼實現(xiàn)的角度，我們可以通過Eclipse的功能，查看詳細的方法調(diào)用棧，如圖2-7所示。
大家看了上面的調(diào)用過程可能會比較好奇，這個FileSystemXmlApplicationContext在什么地方定義了BeanDefinition的讀入器BeanDefinitionReader，從而完成BeanDefinition信息的讀入呢？在前面分析過，在IoC容器的初始化過程中，BeanDefinition資源的定位、讀入和注冊過程是分開進行的，這也是解耦的一個體現(xiàn)。關(guān)于這個讀入器的配置，可以到FileSystemXmlApplicationContext的基類AbstractRefreshableApplicationContext中看看它是怎樣實現(xiàn)的。
我們重點看看AbstractRefreshableApplicationContext的refreshBeanFactory方法的實現(xiàn)，這個refreshBeanFactory被FileSystemXmlApplicationContext構(gòu)造函數(shù)中的refresh調(diào)用。在這個方法中，通過createBeanFactroy構(gòu)建了一個IoC容器供ApplicationContext使用。這個IoC容器就是我們前面提到過的DefaultListableBeanFactory，同時，它啟動了loadBeanDefinitions來載入BeanDefinition，這個過程和前面以編程式的方法來使用IoC容器（XmlBeanFactory）的過程非常類似。
從代碼清單2-4中可以看到，在初始化FileSystmXmlApplicationContext的過程中，通過IoC容器的初始化的refresh來啟動整個調(diào)用，使用的IoC容器是DefultListableBeanFactory。具體的資源載入在XmlBeanDefinitionReader讀入BeanDefinition時完成，在XmlBeanDefinitionReader的基類AbstractBeanDefinitionReader中可以看到這個載入過程的具體實現(xiàn)。對載入過程的啟動，可以在AbstractRefreshableApplicationContext的loadBeanDefinitions方法中看到，如代碼清單2-5所示。
代碼清單2-5 AbstractRefreshableApplicationContext對容器的初始化
protected final void refreshBeanFactory() throws BeansException {
//這里判斷，如果已經(jīng)建立了BeanFactory，則銷毀并關(guān)閉該BeanFactory
if (hasBeanFactory()) {
destroyBeans();
closeBeanFactory();
}
//這里是創(chuàng)建并設(shè)置持有的DefaultListableBeanFactor的地方同時調(diào)用
//loadBeanDefinitions再載入BeanDefinition的信息
try {
DefaultListableBeanFactory beanFactory = createBeanFactory();
beanFactory.setSerializationId(getId());
customizeBeanFactory(beanFactory);
loadBeanDefinitions(beanFactory);
synchronized (this.beanFactoryMonitor) {
this.beanFactory = beanFactory;
}
}
catch (IOException ex) {
throw new ApplicationContextException("I/O error parsing XML document for "
+ getDisplayName(), ex);
}
}
//這就是在上下文中創(chuàng)建DefaultListableBeanFactory的地方，而getInternalParentBeanFactory()
//的具體實現(xiàn)可以
//參看AbstractApplicationContext中的實現(xiàn)，會根據(jù)容器已有的雙親IoC容器的信息來生成
// DefaultListableBeanFactory的雙親IoC容器
protected DefaultListableBeanFactory createBeanFactory() {
return new DefaultListableBeanFactory(getInternalParentBeanFactory());
}
//這里是使用BeanDefinitionReader載入Bean定義的地方，因為允許有多種載入方式，雖然用得
//最多的是XML定義的形式，這里通過一個抽象函數(shù)把具體的實現(xiàn)委托給子類來完成
protected abstract void loadBeanDefinitions(DefaultListableBeanFactory beanFactory)
throws IOException, BeansException;
public int loadBeanDefinitions(String location, Set actualResources) throws
BeanDefinitionStoreException {
//這里取得 ResourceLoader,使用的是DefaultResourceLoader
ResourceLoader resourceLoader = getResourceLoader();
if (resourceLoader == null) {
throw new BeanDefinitionStoreException(
"Cannot import bean definitions from location [" + location + "]:
no ResourceLoader available");
}
//這里對Resource的路徑模式進行解析，比如我們設(shè)定的各種Ant格式的路徑定義，得到需要的
//Resource集合，這些Resource集合指向我們已經(jīng)定義好的BeanDefinition信息，可以是多個文件
if (resourceLoader instanceof ResourcePatternResolver) {
trylt@span b=1> {
//調(diào)用DefaultResourceLoader的getResource完成具體的Resource定位
Resource[] resources = ((ResourcePatternResolver) resourceLoader).
getResources(location);
int loadCount = loadBeanDefinitions(resources);
if (actualResources != null) {
for (int i = 0; i < resources.length; i++) {
actualResources.add(resources[i]);
}
}
if (logger.isDebugEnabled()) {
logger.debug("Loaded " + loadCount + " bean definitions from
location pattern [" + location + "]");
}
return loadCount;
}
catch (IOException ex) {
throw new BeanDefinitionStoreException(
"Could not resolve bean definition resource pattern
[" + location + "]", ex);
}
}
else {
// 調(diào)用DefaultResourceLoader的getResource完成具體的Resource定位
Resource resource = resourceLoader.getResource(location);
int loadCount = loadBeanDefinitions(resource);
if (actualResources != null) {
actualResources.add(resource);
}
if (logger.isDebugEnabled()) {
logger.debug("Loaded " + loadCount + " bean definitions from location
[" + location + "]");
}
return loadCount;
}
}
//對于取得Resource的具體過程，我們可以看看DefaultResourceLoader是怎樣完成的
public Resource getResource(String location) {
Assert.notNull(location, "Location must not be null");
//這里處理帶有classpath標識的Resource
if (location.startsWith(CLASSPATH_URL_PREFIX)) {
return new ClassPathResource(location.substring(CLASSPATH_
URL_PREFIX.length()), getClassLoader());
}
else {
try {
// 這里處理URL標識的Resource定位
URL url = new URL(location);
return new UrlResource(url);
}
catch (MalformedURLException ex) {
//如果既不是classpath，也不是URL標識的Resource定位，則把getResource的
//重任交給getResourceByPath,這個方法是一個protected方法，默認的實現(xiàn)是得到
//一個ClassPathContextResource,這個方法常常會用子類來實現(xiàn)
return getResourceByPath(location);
}
}
}
前面我們看到的getResourceByPath會被子類FileSystemXmlApplicationContext實現(xiàn)，這個方法返回的是一個FileSystemResource對象，通過這個對象，Spring可以進行相關(guān)的I/O操作，完成BeanDefinition的定位。分析到這里已經(jīng)一目了然，它實現(xiàn)的就是對path進行解析，然后生成一個FileSystemResource對象并返回，如代碼清單2-6所示。
代碼清單2-6 FileSystemXmlApplicationContext生成FileSystemResource對象
protected Resource getResourceByPath(String path) {
if (path != null && path.startsWith("/")) {
path = path.substring(1);
}
return new FileSystemResource(path);
}
如果是其他的ApplicationContext，那么會對應(yīng)生成其他種類的Resource，比如ClassPathResource、ServletContextResource等。關(guān)于Spring中Resource的種類，可以在圖2-9的Resource類的繼承關(guān)系中了解。作為接口的Resource定義了許多與I/O相關(guān)的操作，這些操作也都可以從圖2-9中的Resource的接口定義中看到。這些接口對不同的Resource實現(xiàn)代表著不同的意義，是Resource的實現(xiàn)需要考慮的。Resource接口的實現(xiàn)在Spring中的設(shè)計如圖2-9所示。
圖2-9 Resource的定義和繼承關(guān)系
從圖2-9中我們可以看到Resource的定義和它的繼承關(guān)系，通過對前面的實現(xiàn)原理的分析，我們以FileSystemXmlApplicationContext的實現(xiàn)原理為例子，了解了Resource定位問題的解決方案，即以FileSystem方式存在的Resource的定位實現(xiàn)。在BeanDefinition定位完成的基礎(chǔ)上，就可以通過返回的Resource對象來進行BeanDefinition的載入了。在定位過程完成以后，為BeanDefinition的載入創(chuàng)造了I/O操作的條件，但是具體的數(shù)據(jù)還沒有開始讀入。這些數(shù)據(jù)的讀入將在下面介紹的BeanDefinition的載入和解析中來完成。仍然以水桶為例子，這里就像用水桶去打水，要先找到水源。這里完成對Resource的定位，就類似于水源已經(jīng)找到了，下面就是打水的過程了，類似于把找到的水裝到水桶里的過程。找水不簡單，但是與打水相比，我們發(fā)現(xiàn)打水更需要技巧。
2.3.2 BeanDefinition的載入和解析
在完成對代表BeanDefinition的Resource定位的分析后，下面來了解整個BeanDefinition信息的載入過程。對IoC容器來說，這個載入過程，相當于把定義的BeanDefinition在IoC容器中轉(zhuǎn)化成一個Spring內(nèi)部表示的數(shù)據(jù)結(jié)構(gòu)的過程。IoC容器對Bean的管理和依賴注入功能的實現(xiàn)，是通過對其持有的BeanDefinition進行各種相關(guān)操作來完成的。這些BeanDefinition數(shù)據(jù)在IoC容器中通過一個HashMap來保持和維護。當然這只是一種比較簡單的維護方式，如果需要提高IoC容器的性能和容量，完全可以自己做一些擴展。
下面，從DefaultListableBeanFactory的設(shè)計入手，看看IoC容器是怎樣完成BeanDefinition載入的。這個DefaultListableBeanFactory在前面已經(jīng)碰到過多次，相信大家對它一定不會感到陌生。在開始分析之前，先回到IoC容器的初始化入口，也就是看一下refresh方法。這個方法的最初是在FileSystemXmlApplicationContext的構(gòu)造函數(shù)中被調(diào)用的，它的調(diào)用標志著容器初始化的開始，這些初始化對象就是BeanDefinition數(shù)據(jù)，初始化入口如代碼清單2-7所示。
代碼清單2-7 啟動BeanDefinition的載入
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh,
ApplicationContext parent) throws BeansException {
super(parent);
setConfigLocations(configLocations);
//這里調(diào)用容器的refresh，是載入BeanDefinition的入口
if (refresh) {
refresh();
}
}
對容器的啟動來說，refresh是一個很重要的方法，下面介紹一下它的實現(xiàn)。該方法在AbstractApplicationContext類（它是FileSystemXmlApplicationContext的基類）中找到，它詳細地描述了整個ApplicationContext的初始化過程，比如BeanFactory的更新，MessageSource和PostProcessor的注冊，等等。這里看起來更像是對ApplicationContext進行初始化的模板或執(zhí)行提綱，這個執(zhí)行過程為Bean的生命周期管理提供了條件。熟悉IoC容器使用的讀者，從這一系列調(diào)用的名字就能大致了解應(yīng)用上下文初始化的主要內(nèi)容。這里就直接列出代碼，不做太多的解釋了。這個IoC容器的refresh過程如代碼清單2-8所示。
代碼清單2-8 對IoC容器執(zhí)行refresh的過程
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
prepareRefresh();
//這里是在子類中啟動refreshBeanFactory()的地方
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// Prepare the bean factory for use in this context.
prepareBeanFactory(beanFactory);
try {
//設(shè)置BeanFactoy的后置處理
postProcessBeanFactory(beanFactory);
//調(diào)用BeanFactory的后處理器，這些后處理器是在Bean定義中向容器注冊的
invokeBeanFactoryPostProcessors(beanFactory);
//注冊Bean的后處理器，在Bean創(chuàng)建過程中調(diào)用。
registerBeanPostProcessors(beanFactory);
//對上下文中的消息源進行初始化
initMessageSource();
//初始化上下文中的事件機制
initApplicationEventMulticaster();
//初始化其他的特殊Bean
onRefresh();
//檢查監(jiān)聽Bean并且將這些Bean向容器注冊
registerListeners();
//實例化所有的(non-lazy-init)單件
finishBeanFactoryInitialization(beanFactory);
//發(fā)布容器事件，結(jié)束Refresh過程
finishRefresh();
}
catch (BeansException ex) {
//為防止Bean資源占用，在異常處理中，銷毀已經(jīng)在前面過程中生成的單件Bean
destroyBeans();
// 重置 'active'標志
cancelRefresh(ex);
throw ex;
}
}
}
進入到AbstractRefreshableApplicationContext的refreshBeanFactory()方法中，在這個方法中創(chuàng)建了BeanFactory。在創(chuàng)建IoC容器前，如果已經(jīng)有容器存在，那么需要把已有的容器銷毀和關(guān)閉，保證在refresh以后使用的是新建立起來的IoC容器。這么看來，這個refresh非常像重啟動容器，就像重啟動計算機那樣。在建立好當前的IoC容器以后，開始了對容器的初始化過程，比如BeanDefinition的載入，具體的交互過程如圖2-10所示。
圖2-10 BeanDefinition載入中的交互過程
可以從AbstractRefreshableApplicationContext的refreshBeanFactory方法開始，了解這個Bean定義信息載入的過程，具體實現(xiàn)如代碼清單2-9所示。
代碼清單2-9 AbstractRefreshableApplicationContext的refreshBeanFactory方法
protected final void refreshBeanFactory() throws BeansException {
if (hasBeanFactory()) {
destroyBeans();
closeBeanFactory();
}
try {
//創(chuàng)建IoC容器，這里使用的是DefaultListableBeanFactory
DefaultListableBeanFactory beanFactory = createBeanFactory();
beanFactory.setSerializationId(getId());
customizeBeanFactory(beanFactory);
//啟動對BeanDefintion的載入
loadBeanDefinitions(beanFactory);
synchronized (this.beanFactoryMonitor) {
this.beanFactory = beanFactory;
}
}
catch (IOException ex) {
throw new ApplicationContextException("I/O error parsing XML document for "
+ getDisplayName(), ex);
}
}
這里調(diào)用的loadBeanDefinitions實際上是一個抽象方法，那么實際的載入過程發(fā)生在哪里呢？我們看看前面提到的loadBeanDefinitions在AbstractRefreshableApplicationContext的子類AbstractXmlApplicationContext中的實現(xiàn)，在這個loadBeanDefinitions中，初始化了讀取器XmlBeanDefinitionReader，然后把這個讀取器在IoC容器中設(shè)置好（過程和編程式使用XmlBeanFactory是類似的），最后是啟動讀取器來完成BeanDefinition在IoC容器中的載入，如代碼清單2-10所示。
代碼清單2-10 AbstractXmlApplicationContext中的loadBeanDefinitions
public abstract class AbstractXmlApplicationContext extends
AbstractRefreshableConfigApplicationContext {
publiclt@span b=1> AbstractXmlApplicationContext()lt@span b=1> {
}
public AbstractXmlApplicationContext(ApplicationContext parent) {
super(parent);
}
//這里是實現(xiàn)loadBeanDefinitions的地方
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws IOException {
//創(chuàng)建XmlBeanDefinitionReader，并通過回調(diào)設(shè)置到BeanFactory中去，創(chuàng)建BeanFactory
//的過程可以參考上文對編程式使用IoC容器的相關(guān)分析，這里和前面一樣，使用的也是
DefaultListableBeanFactory
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinition
Reader(beanFactory);
//這里設(shè)置XmlBeanDefinitionReader，為XmlBeanDefinitionReader配
//ResourceLoader，因為DefaultResourceLoader是父類，所以this可以直接被使用
beanDefinitionReader.setResourceLoader(this);
beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
//這是啟動Bean定義信息載入的過程
initBeanDefinitionReader(beanDefinitionReader);
loadBeanDefinitions(beanDefinitionReader);
}
protected void initBeanDefinitionReader(XmlBeanDefinitionReader beanDefinitionReader) {
}
接著就是loadBeanDefinitions調(diào)用的地方，首先得到BeanDefinition信息的Resource定位，然后直接調(diào)用XmlBeanDefinitionReader來讀取，具體的載入過程是委托給BeanDefinitionReader完成的。因為這里的BeanDefinition是通過XML文件定義的，所以這里使用XmlBeanDefinitionReader來載入BeanDefinition到容器中，如代碼清單2-11所示。
代碼清單2-11 XmlBeanDefinitionReader載入BeanDefinition
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws
BeansException, IOException {
//以Resource的方式獲得配置文件的資源位置
Resource[] configResources = getConfigResources();
if (configResources != null) {
reader.loadBeanDefinitions(configResources);
}
//以String的形式獲得配置文件的位置
String[] configLocations = getConfigLocations();
if (configLocations != null) {
reader.loadBeanDefinitions(configLocations);
}
}
protected Resource[] getConfigResources() {
return null;
}
}
通過以上對實現(xiàn)原理的分析，我們可以看到，在初始化FileSystmXmlApplicationContext的過程中是通過調(diào)用IoC容器的refresh來啟動整個BeanDefinition的載入過程的，這個初始化是通過定義的XmlBeanDefinitionReader來完成的。同時，我們也知道實際使用的IoC容器是DefultListableBeanFactory，具體的Resource載入在XmlBeanDefinitionReader讀入BeanDefinition時實現(xiàn)。因為Spring可以對應(yīng)不同形式的BeanDefinition。由于這里使用的是XML方式的定義，所以需要使用XmlBeanDefinitionReader。如果使用了其他的BeanDefinition方式，就需要使用其他種類的BeanDefinitionReader來完成數(shù)據(jù)的載入工作。在XmlBeanDefinitionReader的實現(xiàn)中可以看到，是在reader.loadBeanDefinitions中開始進行BeanDefinition的載入的，而這時XmlBeanDefinitionReader的父類AbstractBean-Definition-Reader已經(jīng)為BeanDefinition的載入做好了準備，如代碼清單2-12所示。
代碼清單2-12 AbstractBeanDefinitionReader載入BeanDefinition
public int loadBeanDefinitions(Resource[] resources) throws
BeanDefinitionStoreException {
//如果Resource為空，則停止BeanDefinition的載入
//然后啟動載入BeanDefinition的過程,這個過程會遍歷整個Resource集合所
//包含的BeanDefinition信息
Assert.notNull(resources, "Resource array must not be null");
int counter = 0;
for (int i = 0; i < resources.length; i++) {
counter += loadBeanDefinitions(resources[i]);
}
return counter;
}
這里調(diào)用的是loadBeanDefinitions(Resource res)方法，但這個方法在AbstractBean-DefinitionReader類里是沒有實現(xiàn)的，它是一個接口方法，具體的實現(xiàn)在XmlBean-DefinitionReader中。在讀取器中，需要得到代表XML文件的Resource，因為這個Resource對象封裝了對XML文件的I/O操作，所以讀取器可以在打開I/O流后得到XML的文件對象。有了這個文件對象以后，就可以按照Spring的Bean定義規(guī)則來對這個XML的文檔樹進行解析了，這個解析是交給BeanDefinitionParserDelegate來完成的，看起來實現(xiàn)脈絡(luò)很清楚。具體可以參考代碼實現(xiàn)，如代碼清單2-13所示。
代碼清單2-13 對BeanDefinition的載入實現(xiàn)
//這里是調(diào)用的入口
public int loadBeanDefinitions(Resource resource) throws BeanDefinitionStoreException {
return loadBeanDefinitions(new EncodedResource(resource));
}
//這里是載入XML形式的BeanDefinition的地方
public int loadBeanDefinitions(EncodedResource encodedResource) throws
BeanDefinitionStoreException {
Assert.notNull(encodedResource, "EncodedResource must not be null");
if (logger.isInfoEnabled()) {
logger.info("Loading XML bean definitions from " + encodedResource.getResource());
}
Set<EncodedResource> currentResources = this.
resourcesCurrentlyBeingLoaded.get();
if (currentResources == null) {
currentResources = new HashSet<EncodedResource>(4);
this.resourcesCurrentlyBeingLoaded.set(currentResources);
}
if (!currentResources.add(encodedResource)) {
throw new BeanDefinitionStoreException(
"Detected recursive loading of " + encodedResource + " - check
your import definitions!");
}
//這里得到XML文件，并得到IO的InputSource準備進行讀取
try {
InputStream inputStream = encodedResource.
getResource().getInputStream();
try {
InputSource inputSource = new InputSource(inputStream);
if (encodedResource.getEncoding() != null) {
inputSource.setEncoding(encodedResource.getEncoding());
}
return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
}
finally {
inputStream.close();
}
}
catch (IOException ex) {
throw new BeanDefinitionStoreException(
"IOException parsing XML document from " + encodedResource.
getResource(), ex);
}
finally {
currentResources.remove(encodedResource);
if (currentResources.isEmpty()) {
this.resourcesCurrentlyBeingLoaded.set(null);
}
}
}
//具體的讀取過程可以在doLoadBeanDefinitions方法中找到
//這是從特定的XML文件中實際載入BeanDefinition的地方
protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
throws BeanDefinitionStoreException {
try {
int validationMode = getValidationModeForResource(resource);
//這里取得XML文件的Document對象，這個解析過程是由 documentLoader完成的這個
//documentLoader是DefaultDocumentLoader,在定義documentLoader的地方創(chuàng)建
Document doc = this.documentLoader.loadDocument(
inputSource, getEntityResolver(), this.errorHandler,
validationMode, isNamespaceAware());
//這里啟動的是對BeanDefinition解析的詳細過程，這個解析會使用到Spring的Bean
//配置規(guī)則，是我們下面需要詳細講解的內(nèi)容
return registerBeanDefinitions(doc, resource);
}
catch (BeanDefinitionStoreException ex) {
throw ex;
}
catch (SAXParseException ex) {
throw new XmlBeanDefinitionStoreException(resource.getDescription(),
"Line " + ex.getLineNumber() + " in XML document from " + resource
+ " is invalid", ex);
}
catch (SAXException ex) {
throw new XmlBeanDefinitionStoreException(resource.getDescription(),
"XML document from " + resource + " is invalid", ex);
}
catch (ParserConfigurationException ex) {
throw new BeanDefinitionStoreException(resource.getDescription(),
"Parser configuration exception parsing XML from " + resource, ex);
}
catch (IOException ex) {
throw new BeanDefinitionStoreException(resource.getDescription(),
"IOException parsing XML document from " + resource, ex);
}
catch (Throwable ex) {
throw new BeanDefinitionStoreException(resource.getDescription(),
"Unexpected exception parsing XML document from " + resource, ex);
}
}
感興趣的讀者可以到DefaultDocumentLoader中去看看如何得到Document對象，這里就不詳細分析了。我們關(guān)心的是Spring的BeanDefinion是怎樣按照Spring的Bean語義要求進行解析并轉(zhuǎn)化為容器內(nèi)部數(shù)據(jù)結(jié)構(gòu)的，這個過程是在registerBeanDefinitions(doc, resource)中完成的。具體的過程是由BeanDefinitionDocumentReader來完成的，這個registerBeanDefinition還對載入的Bean的數(shù)量進行了統(tǒng)計。具體過程如代碼清單2-14所示。
代碼清單2-14 registerBeanDefinition的代碼實現(xiàn)
public int registerBeanDefinitions(Document doc, Resource resource) throws
BeanDefinitionStoreException {
//這里得到 BeanDefinitionDocumentReader來對XML的BeanDefinition進行解析
BeanDefinitionDocumentReader documentReader = createBeanDefinition
DocumentReader();
int countBefore = getRegistry().getBeanDefinitionCount();
//具體的解析過程在這個registerBeanDefinitions中完成
documentReader.registerBeanDefinitions(doc, createReaderContext(resource));
return getRegistry().getBeanDefinitionCount() - countBefore;
}
BeanDefinition的載入分成兩部分，首先通過調(diào)用XML的解析器得到document對象，但這些document對象并沒有按照Spring的Bean規(guī)則進行解析。在完成通用的XML解析以后，才是按照Spring的Bean規(guī)則進行解析的地方，這個按照Spring的Bean規(guī)則進行解析的過程是在documentReader中實現(xiàn)的。這里使用的documentReader是默認設(shè)置好的DefaultBean-DefinitionDocumentReader。這個DefaultBeanDefinitionDocumentReader的創(chuàng)建是在后面的方法中完成的，然后再完成BeanDefinition的處理，處理的結(jié)果由BeanDefinitionHolder對象來持有。這個BeanDefinitionHolder除了持有BeanDefinition對象外，還持有其他與BeanDefinition的使用相關(guān)的信息，比如Bean的名字、別名集合等。這個BeanDefinition-Holder的生成是通過對Document文檔樹的內(nèi)容進行解析來完成的，可以看到這個解析過程是由BeanDefinition-ParserDelegate來實現(xiàn)（具體在processBeanDefinition方法中實現(xiàn)）的，同時這個解析是與Spring對BeanDefinition的配置規(guī)則緊密相關(guān)的。具體的實現(xiàn)原理如代碼清單2-15所示。
代碼清單2-15 創(chuàng)建BeanDefinitionDocumentReader
protected BeanDefinitionDocumentReader createBeanDefinitionDocumentReader() {
return BeanDefinitionDocumentReader.class.cast(BeanUtils.instantiateClass
(this.documentReaderClass));
}
//這樣，得到了 documentReader以后，為具體的Spring Bean的解析過程準備好了數(shù)據(jù)
//這里是處理BeanDefinition的地方，具體的處理委托給 BeanDefinitionParserDelegate來
//完成，ele對應(yīng)在Spring BeanDefinition中定義的XML元素
protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate
delegate) {
/＊ BeanDefinitionHolder是BeanDefinition對象的封裝類，封裝了
BeanDefinition，Bean的名字和別名。用它來完成向IoC容器注冊。
得到這個 BeanDefinitionHolder就意味著BeanDefinition是通過
BeanDefinitionParserDelegate對XML元素的信息按照Spring的Bean規(guī)則進行解析得到的＊/
BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
if (bdHolder != null) {
bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
try {
// 這里是向IoC容器注冊解析得到BeanDefinition的地方
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder,
getReaderContext().getRegistry());
}
catch (BeanDefinitionStoreException ex) {
getReaderContext().error("Failed to register bean definition
with name '" + bdHolder.getBeanName() + "'", ele, ex);
}
// 在BeanDefinition向IoC容器注冊完以后，發(fā)送消息
getReaderContext().fireComponentRegistered(new
BeanComponentDefinition(bdHolder));
}
}
具體的Spring BeanDefinition的解析是在BeanDefinitionParserDelegate中完成的。這個類里包含了對各種Spring Bean定義規(guī)則的處理，感興趣的讀者可以仔細研究。比如我們最熟悉的對Bean元素的處理是怎樣完成的，也就是怎樣處理在XML定義文件中出現(xiàn)的<bean></bean>這個最常見的元素信息。在這里會看到對那些熟悉的BeanDefinition定義的處理，比如id、name、aliase等屬性元素。把這些元素的值從XML文件相應(yīng)的元素的屬性中讀取出來以后，設(shè)置到生成的BeanDefinitionHolder中去。這些屬性的解析還是比較簡單的。對于其他元素配置的解析，比如各種Bean的屬性配置，通過一個較為復(fù)雜的解析過程，這個過程是由parseBeanDefinitionElement來完成的。解析完成以后，會把解析結(jié)果放到BeanDefinition對象中并設(shè)置到BeanDefinitionHolder中去，如代碼清單2-16所示。
代碼清單2-16 BeanDefinitionParserDelegate對Bean元素定義的處理
public BeanDefinitionHolder parseBeanDefinitionElement(Element ele, BeanDefinition
containingBean) {
//這里取得在<bean>元素中定義的id、name和aliase屬性的值
String id = ele.getAttribute(ID_ATTRIBUTE);
String nameAttr = ele.getAttribute(NAME_ATTRIBUTE);
List<String> aliases = new ArrayList<String>();
iflt@span b=1> (StringUtils.hasLength(nameAttr))lt@span b=1> {
String[] nameArr = StringUtils.tokenizeToStringArray(nameAttr,
BEAN_NAME_DELIMITERS);
aliases.addAll(Arrays.asList(nameArr));
}
String beanName = id;
if (!StringUtils.hasText(beanName) && !aliases.isEmpty()) {
beanName = aliases.remove(0);
if (logger.isDebugEnabled()) {
logger.debug("No XML 'id' specified - using '" + beanName +
"' as bean name and " + aliases + " as aliases");
}
}
if (containingBean == null) {
checkNameUniqueness(beanName, aliases, ele);
}
//這個方法會引發(fā)對Bean元素的詳細解析
AbstractBeanDefinition beanDefinition = parseBeanDefinitionElement(ele,
beanName, containingBean);
if (beanDefinition != null) {
if (!StringUtils.hasText(beanName)) {
try {
if (containingBean != null) {
beanName = BeanDefinitionReaderUtils.generateBeanName(
beanDefinition, this.readerContext.getRegistry(), true);
}
else {
beanName = this.readerContext.generateBeanName
(beanDefinition);
String beanClassName = beanDefinition.getBeanClassName();
if (beanClassName != null &&
beanName.startsWith(beanClassName) && beanName.length() >
beanClassName.length() &&
!this.readerContext.getRegistry().
isBeanNameInUse(beanClassName)) {
aliases.add(beanClassName);
}
}
if (logger.isDebugEnabled()) {
logger.debug("Neither XML 'id' nor 'name' specified - " +
"using generated bean name [" + beanName + "]");
}
}
catch (Exception ex) {
error(ex.getMessage(), ele);
return null;
}
}
String[] aliasesArray = StringUtils.toStringArray(aliases);
return new BeanDefinitionHolder(beanDefinition, beanName, aliasesArray);
}
return null;
}
上面介紹了對Bean元素進行解析的過程，也就是BeanDefinition依據(jù)XML的<bean>定義被創(chuàng)建的過程。這個BeanDefinition可以看成是對<bean>定義的抽象，如圖2-11所示。這個數(shù)據(jù)對象中封裝的數(shù)據(jù)大多都是與<bean>定義相關(guān)的，也有很多就是我們在定義Bean時看到的那些Spring標記，比如常見的init-method、destroy-method、factory-method，等等，這個BeanDefinition數(shù)據(jù)類型是非常重要的，它封裝了很多基本數(shù)據(jù)，這些基本數(shù)據(jù)都是IoC容器需要的。有了這些基本數(shù)據(jù)，IoC容器才能對Bean配置進行處理，才能實現(xiàn)相應(yīng)的容器特性。
圖2-11 BeanDefinition的數(shù)據(jù)定義
beanClass、description、lazyInit這些屬性都是在配置bean時經(jīng)常碰到的，都集中在這里。這個BeanDefinition是IoC容器體系中非常重要的核心數(shù)據(jù)結(jié)構(gòu)。通過解析以后，這些數(shù)據(jù)已經(jīng)做好在IoC容器里大顯身手的準備了。對BeanDefinition元素的處理如代碼清單2-17所示，在這個過程中可以看到對Bean定義的相關(guān)處理，比如對元素attribute值的處理，對元素屬性值的處理，對構(gòu)造函數(shù)設(shè)置的處理，等等。
代碼清單2-17 對BeanDefinition定義元素的處理
public AbstractBeanDefinition parseBeanDefinitionElement(
Element ele, String beanName, BeanDefinition containingBean) {
this.parseState.push(new BeanEntry(beanName));
//這里只讀取定義的<bean>中設(shè)置的class名字，然后載入到BeanDefinition中去，只是做個
//記錄，并不涉及對象的實例化過程，對象的實例化實際上是在依賴注入時完成的
String className = null;
if (ele.hasAttribute(CLASS_ATTRIBUTE)) {
className = ele.getAttribute(CLASS_ATTRIBUTE).trim();
}
try {
String parent = null;
if (ele.hasAttribute(PARENT_ATTRIBUTE)) {
parent = ele.getAttribute(PARENT_ATTRIBUTE);
}
//這里生成需要的BeanDefinition對象，為Bean定義信息的載入做準備
AbstractBeanDefinition bd = createBeanDefinition(className, parent);
//這里對當前的Bean元素進行屬性解析，并設(shè)置description的信息
parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);
bd.setDescription(DomUtils.getChildElementValueByTagName(ele,
DESCRIPTION_ELEMENT));
//從名字可以清楚地看到，這里是對各種<bean>元素的信息進行解析的地方
parseMetaElements(ele, bd);
parseLookupOverrideSubElements(ele, bd.getMethodOverrides());
parseReplacedMethodSubElements(ele, bd.getMethodOverrides());
//解析<bean>的構(gòu)造函數(shù)設(shè)置
parseConstructorArgElements(ele, bd);
//解析<bean>的property設(shè)置
parsePropertyElements(ele, bd);
parseQualifierElements(ele, bd);
bd.setResource(this.readerContext.getResource());
bd.setSource(extractSource(ele));
return bd;
}
//下面這些異常是在配置Bean出現(xiàn)問題時經(jīng)常會看到的，原來是在這里拋出的這些檢查是在
//createBeanDefinition時進行的，會檢查Bean的class設(shè)置是否正確，比如這個類是否能找到
catch (ClassNotFoundException ex) {
error("Bean class [" + className + "] not found", ele, ex);
}
catch (NoClassDefFoundError err) {
error("Class that bean class [" + className + "] depends on not found", ele, err);
}
catch (Throwable ex) {
error("Unexpected failure during bean definition parsing", ele, ex);
}
finally {
this.parseState.pop();
}
return null;
}
上面是具體生成BeanDefinition的地方。在這里，我們舉一個對property進行解析的例子來完成對整個BeanDefinition載入過程的分析，還是在類BeanDefinitionParserDelegate的代碼中，一層一層地對BeanDefinition中的定義進行解析，比如從屬性元素集合到具體的每一個屬性元素，然后才是對具體的屬性值的處理。根據(jù)解析結(jié)果，對這些屬性值的處理會被封裝成PropertyValue對象并設(shè)置到BeanDefinition對象中去，如代碼清單2-18所示。
代碼清單2-18 對BeanDefinition中Property元素集合的處理
// 這里對指定Bean元素的property子元素集合進行解析
public void parsePropertyElements(Element beanEle, BeanDefinition bd) {
//遍歷所有Bean元素下定義的property元素
NodeList nl = beanEle.getChildNodes();
for (int i = 0; i < nl.getLength(); i++) {
Node node = nl.item(i);
if (node instanceof Element && DomUtils.nodeNameEquals(node,
PROPERTY_ELEMENT)) {
//在判斷是property元素后對該property元素進行解析的過程
parsePropertyElement((Element) node, bd);
}
}
}
public void parsePropertyElement(Element ele, BeanDefinition bd) {
//這里取得property的名字
String propertyName = ele.getAttribute(NAME_ATTRIBUTE);
if (!StringUtils.hasLength(propertyName)) {
error("Tag 'property' must have a 'name' attribute", ele);
return;
}
this.parseState.push(new PropertyEntry(propertyName));
try {
//如果同一個Bean中已經(jīng)有同名的property存在，則不進行解析，直接返回。也就是說，
//如果在同一個Bean中有同名的property設(shè)置，那么起作用的只是第一個
if (bd.getPropertyValues().contains(propertyName)) {
error("Multiple 'property' definitions for property '"
+ propertyName + "'", ele);
return;
}
//這里是解析property值的地方，返回的對象對應(yīng)對Bean定義的property屬性設(shè)置的
//解析結(jié)果，這個解析結(jié)果會封裝到PropertyValue對象中，然后設(shè)置
到BeanDefinitionHolder中去
Object val = parsePropertyValue(ele, bd, propertyName);
PropertyValue pv = new PropertyValue(propertyName, val);
parseMetaElements(ele, pv);
pv.setSource(extractSource(ele));
bd.getPropertyValues().addPropertyValue(pv);
}
finally {
this.parseState.pop();
}
}
//這里取得property元素的值，也許是一個list或其他
public Object parsePropertyValue(Element ele, BeanDefinition bd, String propertyName) {
String elementName = (propertyName != null) ?
"<property> element for property '" + propertyName + "'" :
"<constructor-arg> element";
NodeList nl = ele.getChildNodes();
Element subElement = null;
for (int i = 0; i < nl.getLength(); i++) {
Node node = nl.item(i);
if (node instanceof Element && !DomUtils.nodeNameEquals(node,
DESCRIPTION_ELEMENT) &&
!DomUtils.nodeNameEquals(node, META_ELEMENT)) {
if (subElement != null) {
error(elementName + " must not contain more than one sub-element", ele);
}
elselt@span b=1> {
subElement = (Element) node;
}
}
}
//這里判斷property的屬性，是ref還是value，不允許同時是ref和value
boolean hasRefAttribute = ele.hasAttribute(REF_ATTRIBUTE);
boolean hasValueAttribute = ele.hasAttribute(VALUE_ATTRIBUTE);
if ((hasRefAttribute && hasValueAttribute) ||
((hasRefAttribute || hasValueAttribute) && subElement != null)) {
error(elementName +
" is only allowed to contain either 'ref' attribute OR
'value' attribute OR sub-element", ele);
}
//如果是ref，創(chuàng)建一個ref的數(shù)據(jù)對象RuntimeBeanReference，這個對象封裝了ref的信息
if (hasRefAttribute) {
String refName = ele.getAttribute(REF_ATTRIBUTE);
if (!StringUtils.hasText(refName)) {
error(elementName + " contains empty 'ref' attribute", ele);
}
RuntimeBeanReference ref = new RuntimeBeanReference(refName);
ref.setSource(extractSource(ele));
return ref;
}
//如果是value，創(chuàng)建一個value的數(shù)據(jù)對象TypedStringValue ,這個對象封裝了value的信息
else if (hasValueAttribute) {
TypedStringValue valueHolder = new TypedStringValue(ele.
getAttribute(VALUE_ATTRIBUTE));
valueHolder.setSource(extractSource(ele));
return valueHolder;
}
//如果還有子元素，觸發(fā)對子元素的解析
else if (subElement != null) {
return parsePropertySubElement(subElement, bd);
}
else {
error(elementName + " must specify a ref or value", ele);
return null;
}
}
這里是對property子元素的解析過程，Array、List、Set、Map、Prop等各種元素都會在這里進行解析，生成對應(yīng)的數(shù)據(jù)對象，比如ManagedList、ManagedArray、ManagedSet等。這些Managed類是Spring對具體的BeanDefinition的數(shù)據(jù)封裝。具體的解析過程讀者可以去查看自己感興趣的部分，比如parseArrayElement、parseListElement、parseSetElement、parseMapElement、parsePropElement對應(yīng)著不同類型的數(shù)據(jù)解析，同時這些具體的解析方法在BeanDefinitionParserDelegate類中也都能夠找到。因為方法命名很清晰，所以從方法名字上就能夠很快地找到。下面以對Property的元素進行解析的過程為例，通過它的實現(xiàn)來說明具體的解析過程是怎樣完成的，如代碼清單2-19所示。
代碼清單2-19 對屬性元素進行解析
public Object parsePropertySubElement(Element ele, BeanDefinition bd, String
defaultValueType) {
if (!isDefaultNamespace(ele.getNamespaceURI())) {
return parseNestedCustomElement(ele, bd);
}
else if (DomUtils.nodeNameEquals(ele, BEAN_ELEMENT)) {
BeanDefinitionHolder nestedBd = parseBeanDefinitionElement(ele, bd);
if (nestedBd != null) {
nestedBd = decorateBeanDefinitionIfRequired(ele, nestedBd, bd);
}
return nestedBd;
}
else if (DomUtils.nodeNameEquals(ele, REF_ELEMENT)) {
String refName = ele.getAttribute(BEAN_REF_ATTRIBUTE);
boolean toParent = false;
if (!StringUtils.hasLength(refName)) {
refName = ele.getAttribute(LOCAL_REF_ATTRIBUTE);
if (!StringUtils.hasLength(refName)) {
refName = ele.getAttribute(PARENT_REF_ATTRIBUTE);
toParent = true;
if (!StringUtils.hasLength(refName)) {
error("'bean', 'local' or 'parent' is required for <ref> element", ele);
return null;
}
}
}
if (!StringUtils.hasText(refName)) {
error("<ref> element contains empty target attribute", ele);
return null;
}
RuntimeBeanReference ref = new RuntimeBeanReference(refName, toParent);
ref.setSource(extractSource(ele));
return ref;
}
else if (DomUtils.nodeNameEquals(ele, IDREF_ELEMENT)) {
return parseIdRefElement(ele);
}
else if (DomUtils.nodeNameEquals(ele, VALUE_ELEMENT)) {
return parseValueElement(ele, defaultValueType);
}
else if (DomUtils.nodeNameEquals(ele, NULL_ELEMENT)) {
TypedStringValue nullHolder = new TypedStringValue(null)
nullHolder.setSource(extractSource(ele));
return nullHolder;
}
else if (DomUtils.nodeNameEquals(ele, ARRAY_ELEMENT)) {
return parseArrayElement(ele, bd);
}
else if (DomUtils.nodeNameEquals(ele, LIST_ELEMENT)) {
return parseListElement(ele, bd);
}
else if (DomUtils.nodeNameEquals(ele, SET_ELEMENT)) {
return parseSetElement(ele, bd);
}
else if (DomUtils.nodeNameEquals(ele, MAP_ELEMENT)) {
return parseMapElement(ele, bd);
}
else if (DomUtils.nodeNameEquals(ele, PROPS_ELEMENT)) {
return parsePropsElement(ele);
}
else {
error("Unknown property sub-element: [" + ele.getNodeName() + "]", ele);
return null;
}
}
下面看看List這樣的屬性配置是怎樣被解析的，依然是在BeanDefinitionParserDelegate中，返回的是一個List對象，這個List是Spring定義的ManagedList，作為封裝List這類配置定義的數(shù)據(jù)封裝，如代碼清單2-20所示。
代碼清單2-20 解析BeanDefinition中的List元素
public List parseListElement(Element collectionEle, BeanDefinition bd) {
String defaultElementType = collectionEle.getAttribute(VALUE_TYPE_ATTRIBUTE);
NodeList nl = collectionEle.getChildNodes();
ManagedList<Object> target = new ManagedList<Object>(nl.getLength());
target.setSource(extractSource(collectionEle));
target.setElementTypeName(defaultElementType);
target.setMergeEnabled(parseMergeAttribute(collectionEle));
//具體的List元素的解析過程
parseCollectionElements(nl, target, bd, defaultElementType);
return target;
}
protected void parseCollectionElements(
NodeList elementNodes, Collection<Object> target, BeanDefinition bd,
String defaultElementType) {
//遍歷所有的元素節(jié)點，并判斷其類型是否為Element
for (int i = 0; i < elementNodes.getLength(); i++) {
Node node = elementNodes.item(i);
if (node instanceof Element && !DomUtils.nodeNameEquals(n o d e, DESCRIPTION_ELEMENT)) {
//加入到target中，target是一個ManagedList，同時觸發(fā)對下一層子元素的解析過程，
//這是一個遞歸的調(diào)用
target.add(parsePropertySubElement((Element) node, bd, defaultElementType));
}
}
}
經(jīng)過這樣逐層地解析，我們在XML文件中定義的BeanDefinition就被整個載入到了IoC容器中，并在容器中建立了數(shù)據(jù)映射。在IoC容器中建立了對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，或者說可以看成是POJO對象在IoC容器中的抽象，這些數(shù)據(jù)結(jié)構(gòu)可以以AbstractBeanDefinition為入口，讓IoC容器執(zhí)行索引、查詢和操作。簡單的POJO操作背后其實蘊含著一個復(fù)雜的抽象過程，經(jīng)過以上的載入過程，IoC容器大致完成了管理Bean對象的數(shù)據(jù)準備工作（或者說是初始化過程）。但是，重要的依賴注入實際上在這個時候還沒有發(fā)生，現(xiàn)在，在IoC容器BeanDefinition中存在的還只是一些靜態(tài)的配置信息。嚴格地說，這時候的容器還沒有完全起作用，要完全發(fā)揮容器的作用，還需完成數(shù)據(jù)向容器的注冊。
2.3.3 BeanDefinition在IoC容器中的注冊
前面已經(jīng)分析過BeanDefinition在IoC容器中載入和解析的過程。在這些動作完成以后，用戶定義的BeanDefinition信息已經(jīng)在IoC容器內(nèi)建立起了自己的數(shù)據(jù)結(jié)構(gòu)以及相應(yīng)的數(shù)據(jù)表示，但此時這些數(shù)據(jù)還不能供IoC容器直接使用，需要在IoC容器中對這些BeanDefinition數(shù)據(jù)進行注冊。這個注冊為IoC容器提供了更友好的使用方式，在DefaultListableBeanFactory中，是通過一個HashMap來持有載入的BeanDefinition的，這個HashMap的定義在DefaultListableBeanFactory中可以看到，如下所示。
/＊＊ Map of bean definition objects, keyed by bean name ＊/
private final Map<String, BeanDefinition> beanDefinitionMap = new
ConcurrentHashMap<String, BeanDefinition>();
將解析得到的BeanDefinition向IoC容器中的beanDefinitionMap注冊的過程是在載入BeanDefinition完成后進行的，注冊的調(diào)用過程如圖2-12所示。
圖2-12 注冊的調(diào)用過程
從源代碼實現(xiàn)的角度，可以看到相關(guān)的調(diào)用關(guān)系如圖2-13所示。
圖2-13 registerBeanDefinition的調(diào)用關(guān)系
我們跟蹤以上的代碼調(diào)用去看一下具體的注冊實現(xiàn)，在DefaultListableBeanFactory中實現(xiàn)了BeanDefinitionRegistry的接口，這個接口的實現(xiàn)完成BeanDefinition向容器的注冊。這個注冊過程不復(fù)雜，就是把解析得到的BeanDefinition設(shè)置到hashMap中去。需要注意的是，如果遇到同名的BeanDefinition，進行處理的時候需要依據(jù)allowBeanDefinitionOverriding的配置來完成。具體的實現(xiàn)如代碼清單2-21所示。
代碼清單2-21 BeanDefinition注冊的實現(xiàn)
public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition) throws
BeanDefinitionStoreException {
Assert.hasText(beanName, "'beanName' must not be empty");
Assert.notNull(beanDefinition, "BeanDefinition must not be null");
if (beanDefinition instanceof AbstractBeanDefinition) {
try {
((AbstractBeanDefinition) beanDefinition).validate();
}
catch (BeanDefinitionValidationException ex) {
throw new BeanDefinitionStoreException(beanDefinition.
getResourceDescription(), beanName,
"Validation of bean definition failed", ex);
}
}
//注冊的過程需要synchronized，保證數(shù)據(jù)的一致性
synchronized (this.beanDefinitionMap) {
//這里檢查是不是有相同名字的BeanDefinition已經(jīng)在IoC容器中注冊了，如果有相同名字的
//BeanDefinition，但又不允許覆蓋，那么會拋出異常
Object oldBeanDefinition = this.beanDefinitionMap.get(beanName);
if (oldBeanDefinition != null) {
if (!this.allowBeanDefinitionOverriding) {
throw new BeanDefinitionStoreException
(beanDefinition.getResourceDescription(), beanName,
"Cannot register bean definition [" +
beanDefinition + "] for bean '" + beanName +
"': There is already [" + oldBeanDefinition + "] bound.");
}
else {
if (this.logger.isInfoEnabled()) {
this.logger.info("Overriding bean definition for bean
'" + beanName +
"': replacing [" + oldBeanDefinition + "]
with [" + beanDefinition + "]");
}
}
}
/＊這是正常注冊BeanDefinition的過程，把Bean的名字存入到beanDefinitionNames的同時，把
beanName作為Map的key,把beanDefinition作為value存入到IoC容器持有的beanDefinitionMap中去＊/
else {
this.beanDefinitionNames.add(beanName);
this.frozenBeanDefinitionNames = null;
}
this.beanDefinitionMap.put(beanName, beanDefinition);
resetBeanDefinition(beanName);
}
}
完成了BeanDefinition的注冊，就完成了IoC容器的初始化過程。此時，在使用的IoC容器DefaultListableBeanFactory中已經(jīng)建立了整個Bean的配置信息，而且這些BeanDefinition已經(jīng)可以被容器使用了，它們都在beanDefinitionMap里被檢索和使用。容器的作用就是對這些信息進行處理和維護。這些信息是容器建立依賴反轉(zhuǎn)的基礎(chǔ)，有了這些基礎(chǔ)數(shù)據(jù)，下面我們看一下在IoC容器中，依賴注入是怎樣完成的。
- 流量的秘密：Google Analytics網(wǎng)站分析與優(yōu)化技巧（第2版）
- JavaScript高效圖形編程
- Bulma必知必會
- Easy Web Development with WaveMaker
- Python深度學習原理、算法與案例
- Hands-On Nuxt.js Web Development
- TypeScript 2.x By Example
- C語言程序設(shè)計
- Python編程快速上手2
- Beginning C# 7 Hands-On：The Core Language
- Dart：Scalable Application Development
- JBoss AS 7 Development
- Web應(yīng)用程序設(shè)計：ASP
- UG 12.0數(shù)控編程實例教程
- C++碼農(nóng)日記（全程視頻講解）