在認真學習Rod.Johnson的三部曲之一:<<Professional Java Development with the spring framework>>,順便也看了看源代碼想知道個究竟,拋磚引玉,有興趣的同志一起討論研究吧!
以下內容引自博客: http://www.javaeye.com/wiki/Spring-source
,歡迎指導:)
在Spring中,IOC容器的重要地位我們就不多說了,對于Spring的使用者而言,IOC容器實際上是什么呢?我們可以說BeanFactory就是我們看到的IoC容器,當然了Spring為我們準備了許多種IoC容器來使用,這樣可以方便我們從不同的層面,不同的資源位置,不同的形式的定義信息來建立我們需要的IoC容器。
在Spring中,最基本的IOC容器接口是BeanFactory - 這個接口為具體的IOC容器的實現作了最基本的功能規定 - 不管怎么著,作為IOC容器,這些接口你必須要滿足應用程序的最基本要求:
Java代碼
?1
public
?
interface
?BeanFactory?
{
?2
?3
????
//
這里是對FactoryBean的轉義定義,因為如果使用bean的名字檢索FactoryBean得到的對象是工廠生成的對象,
?4
????
//
如果需要得到工廠本身,需要轉義???????
?5
????String?FACTORY_BEAN_PREFIX?
=
?
"
&
"
;
?6
?7
?8
????
//
這里根據bean的名字,在IOC容器中得到bean實例,這個IOC容器就是一個大的抽象工廠。
?9
????Object?getBean(String?name)?
throws
?BeansException;
10
11
????
//
這里根據bean的名字和Class類型來得到bean實例,和上面的方法不同在于它會拋出異常:如果根據名字取得的bean實例的Class類型和需要的不同的話。
12
????Object?getBean(String?name,?Class?requiredType)?
throws
?BeansException;
13
14
????
//
這里提供對bean的檢索,看看是否在IOC容器有這個名字的bean
15
????
boolean
?containsBean(String?name);
16
17
????
//
這里根據bean名字得到bean實例,并同時判斷這個bean是不是單件
18
????
boolean
?isSingleton(String?name)?
throws
?NoSuchBeanDefinitionException;
19
20
????
//
這里對得到bean實例的Class類型
21
????Class?getType(String?name)?
throws
?NoSuchBeanDefinitionException;
22
23
????
//
這里得到bean的別名,如果根據別名檢索,那么其原名也會被檢索出來
24
????String[]?getAliases(String?name);
25
26
}



?2

?3

?4

?5

?6

?7

?8

?9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

在BeanFactory里只對IOC容器的基本行為作了定義,根本不關心你的bean是怎樣定義怎樣加載的 - 就像我們只關心從這個工廠里我們得到到什么產品對象,至于工廠是怎么生產這些對象的,這個基本的接口不關心這些。如果要關心工廠是怎樣產生對象的,應用程序需要使用具體的IOC容器實現- 當然你可以自己根據這個BeanFactory來實現自己的IOC容器,但這個沒有必要,因為Spring已經為我們準備好了一系列工廠來讓我們使用。比如XmlBeanFactory就是針對最基礎的BeanFactory的IOC容器的實現 - 這個實現使用xml來定義IOC容器中的bean。
Spring提供了一個BeanFactory的基本實現,XmlBeanFactory同樣的通過使用模板模式來得到對IOC容器的抽象- AbstractBeanFactory,DefaultListableBeanFactory這些抽象類為其提供模板服務。其中通過resource 接口來抽象bean定義數據,對Xml定義文件的解析通過委托給XmlBeanDefinitionReader來完成。下面我們根據書上的例子,簡單的演示IOC容器的創建過程:
Java代碼
1
????ClassPathResource?res?
=
?
new
?ClassPathResource(
"
beans.xml
"
);
2
????DefaultListableBeanFactory?factory?
=
?
new
?DefaultListableBeanFactory();
3
????XmlBeanDefinitionReader?reader?
=
?
new
?XmlBeanDefinitionReader(factory);
4
????reader.loadBeanDefinitions(res);
這些代碼演示了以下幾個步驟: 
2

3

4

?? 1. 創建IOC配置文件的抽象資源
?? 2. 創建一個BeanFactory
?? 3. 把讀取配置信息的BeanDefinitionReader,這里是XmlBeanDefinitionReader配置給BeanFactory
?? 4. 從定義好的資源位置讀入配置信息,具體的解析過程由XmlBeanDefinitionReader來完成,這樣完成整個載入bean定義的過程。我們的IoC容器就建立起來了。在BeanFactory的源代碼中我們可以看到:
Java代碼
?1
public
?
class
?XmlBeanFactory?
extends
?DefaultListableBeanFactory?
{
?2
????
//
這里為容器定義了一個默認使用的bean定義讀取器
?3
????
private
?
final
?XmlBeanDefinitionReader?reader?
=
?
new
?XmlBeanDefinitionReader(
this
);
?4
????
public
?XmlBeanFactory(Resource?resource)?
throws
?BeansException?
{
?5
????????
this
(resource,?
null
);
?6
????}
?7
????
//
在初始化函數中使用讀取器來對資源進行讀取,得到bean定義信息。
?8
????
public
?XmlBeanFactory(Resource?resource,?BeanFactory?parentBeanFactory)?
throws
?BeansException?
{
?9
????????
super
(parentBeanFactory);
10
????????
this
.reader.loadBeanDefinitions(resource);
11
????}
我們在后面會看到讀取器讀取資源和注冊bean定義信息的整個過程,基本上是和上下文的處理是一樣的,從這里我們可以看到上下文和 XmlBeanFactory這兩種IOC容器的區別,BeanFactory往往不具備對資源定義的能力,而上下文可以自己完成資源定義,從這個角度上看上下文更好用一些。 


?2

?3

?4



?5

?6

?7

?8



?9

10

11

仔細分析Spring BeanFactory的結構,我們來看看在BeanFactory基礎上擴展出的ApplicationContext - 我們最常使用的上下文。除了具備BeanFactory的全部能力,上下文為應用程序又增添了許多便利:
??? * 可以支持不同的信息源,我們看到ApplicationContext擴展了MessageSource
??? * 訪問資源 , 體現在對ResourceLoader和Resource的支持上面,這樣我們可以從不同地方得到bean定義資源
??? * 支持應用事件,繼承了接口ApplicationEventPublisher,這樣在上下文中引入了事件機制而BeanFactory是沒有的。
ApplicationContext允許上下文嵌套 - 通過保持父上下文可以維持一個上下文體系 - 這個體系我們在以后對Web容器中的上下文環境的分析中可以清楚地看到。對于bean的查找可以在這個上下文體系中發生,首先檢查當前上下文,其次是父上下文,逐級向上,這樣為不同的Spring應用提供了一個共享的bean定義環境。這個我們在分析Web容器中的上下文環境時也能看到。
ApplicationContext提供IoC容器的主要接口,在其體系中有許多抽象子類比如AbstractApplicationContext為具體的BeanFactory的實現,比如FileSystemXmlApplicationContext和 ClassPathXmlApplicationContext提供上下文的模板,使得他們只需要關心具體的資源定位問題。當應用程序代碼實例化 FileSystemXmlApplicationContext的時候,得到IoC容器的一種具體表現 - ApplicationContext,從而應用程序通過ApplicationContext來管理對bean的操作。
BeanFactory 是一個接口,在實際應用中我們一般使用ApplicationContext來使用IOC容器,它們也是IOC容器展現給應用開發者的使用接口。對應用程序開發者來說,可以認為BeanFactory和ApplicationFactory在不同的使用層面上代表了SPRING提供的IOC容器服務。
下面我們具體看看通過FileSystemXmlApplicationContext是怎樣建立起IOC容器的, 顯而易見我們可以通過new來得到IoC容器:
1
???ApplicationContext?
=
?
new
?FileSystemXmlApplicationContext(xmlPath);
調用的是它初始化代碼:
1
????
public
?FileSystemXmlApplicationContext(String[]?configLocations,?
boolean
?refresh,?ApplicationContext?parent)
2
????????????
throws
?BeansException?
{
3
????????
super
(parent);
4
????????
this
.configLocations?
=
?configLocations;
5
????????
if
?(refresh)?
{
6
??????????
//
這里是IoC容器的初始化過程,其初始化過程的大致步驟由AbstractApplicationContext來定義
7
????????????refresh();
8
????????}
9
????}
refresh的模板在AbstractApplicationContext: 
2



3

4

5



6

7

8

9

?1
????
public
?
void
?refresh()?
throws
?BeansException,?IllegalStateException?
{
?2
????????
synchronized
?(
this
.startupShutdownMonitor)?
{
?3
????????????
synchronized
?(
this
.activeMonitor)?
{
?4
????????????????
this
.active?
=
?
true
;
?5
????????????}
?6
?7
????????????
//
?這里需要子類來協助完成資源位置定義,bean載入和向IOC容器注冊的過程
?8
????????????refreshBeanFactory();
?9
????????????



10
?????}
這個方法包含了整個BeanFactory初始化的過程,對于特定的FileSystemXmlBeanFactory,我們看到定位資源位置由refreshBeanFactory()來實現: 


?2



?3



?4

?5

?6

?7

?8

?9





10

在AbstractXmlApplicationContext中定義了對資源的讀取過程,默認由XmlBeanDefinitionReader來讀取:
?1
????
protected
?
void
?loadBeanDefinitions(DefaultListableBeanFactory?beanFactory)?
throws
?IOException?
{
?2
????????
//
?這里使用XMLBeanDefinitionReader來載入bean定義信息的XML文件
?3
????????XmlBeanDefinitionReader?beanDefinitionReader?
=
?
new
?XmlBeanDefinitionReader(beanFactory);
?4
?5
????????
//
這里配置reader的環境,其中ResourceLoader是我們用來定位bean定義信息資源位置的
?6
????????
//
/因為上下文本身實現了ResourceLoader接口,所以可以直接把上下文作為ResourceLoader傳遞給XmlBeanDefinitionReader
?7
????????beanDefinitionReader.setResourceLoader(
this
);
?8
????????beanDefinitionReader.setEntityResolver(
new
?ResourceEntityResolver(
this
));
?9
10
????????initBeanDefinitionReader(beanDefinitionReader);
11
????????
//
這里轉到定義好的XmlBeanDefinitionReader中對載入bean信息進行處理
12
????????loadBeanDefinitions(beanDefinitionReader);
13
????}
轉到beanDefinitionReader中進行處理:


?2

?3

?4

?5

?6

?7

?8

?9

10

11

12

13

?1
protected
?
void
?loadBeanDefinitions(XmlBeanDefinitionReader?reader)?
throws
?BeansException,?IOException?
{???
?2
????Resource[]?configResources?
=
?getConfigResources();???
?3
????
if
?(configResources?
!=
?
null
)?
{???
?4
????????
//
調用XmlBeanDefinitionReader來載入bean定義信息。???
?5
????????reader.loadBeanDefinitions(configResources);???
?6
????}
???
?7
????String[]?configLocations?
=
?getConfigLocations();???
?8
????
if
?(configLocations?
!=
?
null
)?
{???
?9
????????reader.loadBeanDefinitions(configLocations);???
10
????}
???
11
}
??
12
而在作為其抽象父類的AbstractBeanDefinitionReader中來定義載入過程:


?2

?3



?4

?5

?6

?7

?8



?9

10

11

12

?1
????
public
?
int
?loadBeanDefinitions(String?location)?
throws
?BeanDefinitionStoreException?
{
?2
?????
//
這里得到當前定義的ResourceLoader,默認的我們使用DefaultResourceLoader
?3
?????ResourceLoader?resourceLoader?
=
?getResourceLoader();
?4
?????

//
如果沒有找到我們需要的ResourceLoader,直接拋出異常
?5
????????
if
?(resourceLoader?
instanceof
?ResourcePatternResolver)?
{
?6
????????????
//
?這里處理我們在定義位置時使用的各種pattern,需要ResourcePatternResolver來完成
?7
????????????
try
?
{
?8
????????????????Resource[]?resources?
=
?((ResourcePatternResolver)?resourceLoader).getResources(location);
?9
????????????????
int
?loadCount?
=
?loadBeanDefinitions(resources);
10
????????????????
return
?loadCount;
11
????????????}
12
??????????
..
13
????????}
14
????????
else
?
{
15
????????????
//
?這里通過ResourceLoader來完成位置定位
16
????????????Resource?resource?
=
?resourceLoader.getResource(location);
17
????????????
//
?這里已經把一個位置定義轉化為Resource接口,可以供XmlBeanDefinitionReader來使用了
18
????????????
int
?loadCount?
=
?loadBeanDefinitions(resource);
19
????????????
return
?loadCount;
20
????????}
21
????}
當我們通過ResourceLoader來載入資源,別忘了了我們的GenericApplicationContext也實現了ResourceLoader接口: 


?2

?3

?4




?5



?6

?7



?8

?9

10

11

12



13

14



15

16

17

18

19

20

21

?1
????
public
?
class
?GenericApplicationContext?
extends
?AbstractApplicationContext?
implements
?BeanDefinitionRegistry?
{
?2
????????
public
?Resource?getResource(String?location)?
{
?3
????????????
//
這里調用當前的loader也就是DefaultResourceLoader來完成載入
?4
????????????
if
?(
this
.resourceLoader?
!=
?
null
)?
{
?5
????????????????
return
?
this
.resourceLoader.getResource(location);
?6
????????????}
?7
????????????
return
?
super
.getResource(location);
?8
????????}
?9
????
.
10
????}
而我們的FileSystemXmlApplicationContext就是一個DefaultResourceLoader - GenericApplicationContext()通過DefaultResourceLoader: 


?2



?3

?4



?5

?6

?7

?8

?9



10

?1
????
public
?Resource?getResource(String?location)?
{
?2
????????
//
如果是類路徑的方式,那需要使用ClassPathResource來得到bean文件的資源對象
?3
????????
if
?(location.startsWith(CLASSPATH_URL_PREFIX))?
{
?4
????????????
return
?
new
?ClassPathResource(location.substring(CLASSPATH_URL_PREFIX.length()),?getClassLoader());
?5
????????}
?6
????????
else
?
{
?7
????????????
try
?
{
?8
????????????????
//
?如果是URL方式,使用UrlResource作為bean文件的資源對象
?9
????????????????URL?url?
=
?
new
?URL(location);
10
????????????????
return
?
new
?UrlResource(url);
11
????????????}
12
????????????
catch
?(MalformedURLException?ex)?
{
13
????????????????
//
?如果都不是,那我們只能委托給子類由子類來決定使用什么樣的資源對象了
14
????????????????
return
?getResourceByPath(location);
15
????????????}
16
????????}
17
????}
我們的FileSystemXmlApplicationContext本身就是是DefaultResourceLoader的實現類,他實現了以下的接口: 


?2

?3



?4

?5

?6



?7



?8

?9

10

11

12



13

14

15

16

17

1
????
protected
?Resource?getResourceByPath(String?path)?
{
2
????????
if
?(path?
!=
?
null
?
&&
?path.startsWith(
"
/
"
))?
{
3
????????????path?
=
?path.substring(
1
);
4
????????}
5
????????
//
這里使用文件系統資源對象來定義bean文件
6
????????
return
?
new
?FileSystemResource(path);
7
????}
這樣代碼就回到了FileSystemXmlApplicationContext中來,他提供了FileSystemResource來完成從文件系統得到配置文件的資源定義。這樣,就可以從文件系統路徑上對IOC配置文件進行加載 - 當然我們可以按照這個邏輯從任何地方加載,在Spring中我們看到它提供的各種資源抽象,比如ClassPathResource, URLResource,FileSystemResource等來供我們使用。上面我們看到的是定位Resource的一個過程,而這只是加載過程的一部分 - 我們回到AbstractBeanDefinitionReaderz中的loadDefinitions(resource)來看看得到代表bean文件的資源定義以后的載入過程,默認的我們使用XmlBeanDefinitionReader:


2



3

4

5

6

7

?1
????
public
?
int
?loadBeanDefinitions(EncodedResource?encodedResource)?
throws
?BeanDefinitionStoreException?
{
?2
????????
.
?3
????????
try
?
{
?4
????????????
//
這里通過Resource得到InputStream的IO流
?5
????????????InputStream?inputStream?
=
?encodedResource.getResource().getInputStream();
?6
????????????
try
?
{
?7
????????????????
//
從InputStream中得到XML的解析源
?8
????????????????InputSource?inputSource?
=
?
new
?InputSource(inputStream);
?9
????????????????
if
?(encodedResource.getEncoding()?
!=
?
null
)?
{
10
????????????????????inputSource.setEncoding(encodedResource.getEncoding());
11
????????????????}
12
????????????????
//
這里是具體的解析和注冊過程
13
????????????????
return
?doLoadBeanDefinitions(inputSource,?encodedResource.getResource());
14
????????????}
15
????????????
finally
?
{
16
????????????????
//
關閉從Resource中得到的IO流
17
????????????????inputStream.close();
18
????????????}
19
????????}
20
???????????


21
????}
22
23
????
protected
?
int
?doLoadBeanDefinitions(InputSource?inputSource,?Resource?resource)
24
????????????
throws
?BeanDefinitionStoreException?
{
25
????????
try
?
{
26
????????????
int
?validationMode?
=
?getValidationModeForResource(resource);
27
????????????
//
通過解析得到DOM,然后完成bean在IOC容器中的注冊
28
????????????Document?doc?
=
?
this
.documentLoader.loadDocument(
29
????????????????????inputSource,?
this
.entityResolver,?
this
.errorHandler,?validationMode,?
this
.namespaceAware);
30
????????????
return
?registerBeanDefinitions(doc,?resource);
31
????????}
32
????
.
33
????}
我們看到先把定義文件解析為DOM對象,然后進行具體的注冊過程:


?2



?3



?4

?5

?6



?7

?8

?9



10

11

12

13

14

15



16

17

18

19

20




21

22

23

24



25



26

27

28

29

30

31

32



33

?1
????
public
?
int
?registerBeanDefinitions(Document?doc,?Resource?resource)?
throws
?BeanDefinitionStoreException?
{
?2
????????
//
?這里定義解析器,使用XmlBeanDefinitionParser來解析xml方式的bean定義文件?-?現在的版本不用這個解析器了,使用的是XmlBeanDefinitionReader
?3
????????
if
?(
this
.parserClass?
!=
?
null
)?
{
?4
????????????XmlBeanDefinitionParser?parser?
=
?5
????????????????????(XmlBeanDefinitionParser)?BeanUtils.instantiateClass(
this
.parserClass);
?6
????????????
return
?parser.registerBeanDefinitions(
this
,?doc,?resource);
?7
????????}
?8
????????
//
?具體的注冊過程,首先得到XmlBeanDefinitionReader,來處理xml的bean定義文件
?9
????????BeanDefinitionDocumentReader?documentReader?
=
?createBeanDefinitionDocumentReader();
10
????????
int
?countBefore?
=
?getBeanFactory().getBeanDefinitionCount();
11
????????documentReader.registerBeanDefinitions(doc,?createReaderContext(resource));
12
????????
return
?getBeanFactory().getBeanDefinitionCount()?
-
?countBefore;
13
????}
具體的在BeanDefinitionDocumentReader中完成對,下面是一個簡要的注冊過程來完成bean定義文件的解析和IOC容器中bean的初始化 


?2

?3



?4

?5

?6

?7

?8

?9

10

11

12

13

?1
????
public
?
void
?registerBeanDefinitions(Document?doc,?XmlReaderContext?readerContext)?
{
?2
????????
this
.readerContext?
=
?readerContext;
?3
?4
????????logger.debug(
"
Loading?bean?definitions
"
);
?5
????????Element?root?
=
?doc.getDocumentElement();
?6
?7
????????BeanDefinitionParserDelegate?delegate?
=
?createHelper(readerContext,?root);
?8
?9
????????preProcessXml(root);
10
????????parseBeanDefinitions(root,?delegate);
11
????????postProcessXml(root);
12
????}
13
14
????
protected
?
void
?parseBeanDefinitions(Element?root,?BeanDefinitionParserDelegate?delegate)?
{
15
????????
if
?(delegate.isDefaultNamespace(root.getNamespaceURI()))?
{
16
????????????
//
這里得到xml文件的子節點,比如各個bean節點?????????
17
????????????NodeList?nl?
=
?root.getChildNodes();
18
19
????????????
//
這里對每個節點進行分析處理
20
????????????
for
?(
int
?i?
=
?
0
;?i?
<
?nl.getLength();?i
++
)?
{
21
????????????????Node?node?
=
?nl.item(i);
22
????????????????
if
?(node?
instanceof
?Element)?
{
23
????????????????????Element?ele?
=
?(Element)?node;
24
????????????????????String?namespaceUri?
=
?ele.getNamespaceURI();
25
????????????????????
if
?(delegate.isDefaultNamespace(namespaceUri))?
{
26
????????????????????????
//
這里是解析過程的調用,對缺省的元素進行分析比如bean元素
27
????????????????????????parseDefaultElement(ele,?delegate);
28
????????????????????}
29
????????????????????
else
?
{
30
????????????????????????delegate.parseCustomElement(ele);
31
????????????????????}
32
????????????????}
33
????????????}
34
????????}
?
else
?
{
35
????????????delegate.parseCustomElement(root);
36
????????}
37
????}
38
39
????
private
?
void
?parseDefaultElement(Element?ele,?BeanDefinitionParserDelegate?delegate)?
{
40
????????
//
這里對元素Import進行處理
41
????????
if
?(DomUtils.nodeNameEquals(ele,?IMPORT_ELEMENT))?
{
42
????????????importBeanDefinitionResource(ele);
43
????????}
44
????????
else
?
if
?(DomUtils.nodeNameEquals(ele,?ALIAS_ELEMENT))?
{
45
????????????String?name?
=
?ele.getAttribute(NAME_ATTRIBUTE);
46
????????????String?alias?
=
?ele.getAttribute(ALIAS_ATTRIBUTE);
47
????????????getReaderContext().getReader().getBeanFactory().registerAlias(name,?alias);
48
????????????getReaderContext().fireAliasRegistered(name,?alias,?extractSource(ele));
49
????????}
50
????????
//
這里對我們最熟悉的bean元素進行處理
51
????????
else
?
if
?(DomUtils.nodeNameEquals(ele,?BEAN_ELEMENT))?
{
52
????????????
//
委托給BeanDefinitionParserDelegate來完成對bean元素的處理,這個類包含了具體的bean解析的過程。
53
????????????
//
?把解析bean文件得到的信息放到BeanDefinition里,他是bean信息的主要載體,也是IOC容器的管理對象。
54
????????????BeanDefinitionHolder?bdHolder?
=
?delegate.parseBeanDefinitionElement(ele);
55
????????????
if
?(bdHolder?
!=
?
null
)?
{
56
????????????????bdHolder?
=
?delegate.decorateBeanDefinitionIfRequired(ele,?bdHolder);
57
????????????????
//
?這里是向IOC容器注冊,實際上是放到IOC容器的一個map里
58
????????????????BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder,?getReaderContext().getRegistry());
59
60
????????????????
//
?這里向IOC容器發送事件,表示解析和注冊完成。
61
????????????????getReaderContext().fireComponentRegistered(
new
?BeanComponentDefinition(bdHolder));
62
????????????}
63
????????}
64
????}
我們看到在parseBeanDefinition中對具體bean元素的解析式交給BeanDefinitionParserDelegate來完成的,下面我們看看解析完的bean是怎樣在IOC容器中注冊的: 


?2

?3

?4

?5

?6

?7

?8

?9

10

11

12

13

14



15



16

17

18

19

20



21

22



23

24

25



26

27

28

29



30

31

32

33

34



35

36

37

38

39



40

41



42

43

44



45

46

47

48

49

50

51



52

53

54

55



56

57

58

59

60

61

62

63

64

在BeanDefinitionReaderUtils調用的是:
?1
????
public
?
static
?
void
?registerBeanDefinition(
?2
????????????BeanDefinitionHolder?bdHolder,?BeanDefinitionRegistry?beanFactory)?
throws
?BeansException?
{
?3
?4
????????
//
?這里得到需要注冊bean的名字;
?5
????????String?beanName?
=
?bdHolder.getBeanName();
?6
????????
//
這是調用IOC來注冊的bean的過程,需要得到BeanDefinition
?7
????????beanFactory.registerBeanDefinition(beanName,?bdHolder.getBeanDefinition());
?8
?9
????????
//
?別名也是可以通過IOC容器和bean聯系起來的進行注冊
10
????????String[]?aliases?
=
?bdHolder.getAliases();
11
????????
if
?(aliases?
!=
?
null
)?
{
12
????????????
for
?(
int
?i?
=
?
0
;?i?
<
?aliases.length;?i
++
)?
{
13
????????????????beanFactory.registerAlias(beanName,?aliases[i]);
14
????????????}
15
????????}
16
????}
我們看看XmlBeanFactory中的注冊實現:

?2



?3

?4

?5

?6

?7

?8

?9

10

11



12



13

14

15

16

?1
????
//
---------------------------------------------------------------------
?2
????
//
?這里是IOC容器對BeanDefinitionRegistry接口的實現
?3
????
//
---------------------------------------------------------------------
?4
?5
????
public
?
void
?registerBeanDefinition(String?beanName,?BeanDefinition?beanDefinition)
?6
????????????
throws
?BeanDefinitionStoreException?
{
?7
?8
????????
..
//
這里省略了對BeanDefinition的驗證過程
?9
????????
//
先看看在容器里是不是已經有了同名的bean,如果有拋出異常。
10
????????Object?oldBeanDefinition?
=
?
this
.beanDefinitionMap.get(beanName);
11
????????
if
?(oldBeanDefinition?
!=
?
null
)?
{
12
????????????
if
?(
!
this
.allowBeanDefinitionOverriding)?
{
13
????????????

..
14
????????}
15
????????
else
?
{
16
????????????
//
把bean的名字加到IOC容器中去
17
????????????
this
.beanDefinitionNames.add(beanName);
18
????????}
19
????????
//
這里把bean的名字和Bean定義聯系起來放到一個HashMap中去,IOC容器通過這個Map來維護容器里的Bean定義信息。
20
????????
this
.beanDefinitionMap.put(beanName,?beanDefinition);
21
????????removeSingleton(beanName);
22
????}
這樣就完成了Bean定義在IOC容器中的注冊,就可被IOC容器進行管理和使用了。 
?2

?3

?4

?5

?6



?7

?8


?9

10

11



12



13




14

15



16

17

18

19

20

21

22

從上面的代碼來看,我們總結一下IOC容器初始化的基本步驟:
??? * 初始化的入口在容器實現中的refresh()調用來完成
??? * 對bean 定義載入IOC容器使用的方法是loadBeanDefinition,其中的大致過程如下:通過ResourceLoader來完成資源文件位置的定位,DefaultResourceLoader是默認的實現,同時上下文本身就給出了ResourceLoader的實現,可以從類路徑,文件系統, URL等方式來定為資源位置。如果是XmlBeanFactory作為IOC容器,那么需要為它指定bean定義的資源,也就是說bean定義文件時通過抽象成Resource來被IOC容器處理的,容器通過BeanDefinitionReader來完成定義信息的解析和Bean信息的注冊,往往使用的是XmlBeanDefinitionReader來解析bean的xml定義文件 - 實際的處理過程是委托給BeanDefinitionParserDelegate來完成的,從而得到bean的定義信息,這些信息在Spring中使用BeanDefinition對象來表示 - 這個名字可以讓我們想到loadBeanDefinition,RegisterBeanDefinition這些相關的方法 - 他們都是為處理BeanDefinitin服務的,IoC容器解析得到BeanDefinition以后,需要把它在IOC容器中注冊,這由IOC實現 BeanDefinitionRegistry接口來實現。注冊過程就是在IOC容器內部維護的一個HashMap來保存得到的 BeanDefinition的過程。這個HashMap是IoC容器持有bean信息的場所,以后對bean的操作都是圍繞這個HashMap來實現的。
??? * 然后我們就可以通過BeanFactory和ApplicationContext來享受到Spring IOC的服務了.
在使用IOC容器的時候,我們注意到除了少量粘合代碼,絕大多數以正確IoC風格編寫的應用程序代碼完全不用關心如何到達工廠,因為容器將把這些對象與容器管理的其他對象鉤在一起。基本的策略是把工廠放到已知的地方,最好是放在對預期使用的上下文有意義的地方,以及代碼將實際需要訪問工廠的地方。 Spring本身提供了對聲明式載入web應用程序用法的應用程序上下文,并將其存儲在ServletContext中的框架實現。具體可以參見以后的文章。
在使用Spring IOC容器的時候我們還需要區別兩個概念:
Beanfactory 和Factory bean,其中BeanFactory指的是IOC容器的編程抽象,比如ApplicationContext, XmlBeanFactory等,這些都是IOC容器的具體表現,需要使用什么樣的容器由客戶決定但Spring為我們提供了豐富的選擇。而 FactoryBean只是一個可以在IOC容器中被管理的一個bean,是對各種處理過程和資源使用的抽象,Factory bean在需要時產生另一個對象,而不返回FactoryBean本省,我們可以把它看成是一個抽象工廠,對它的調用返回的是工廠生產的產品。所有的 Factory bean都實現特殊的org.springframework.beans.factory.FactoryBean接口,當使用容器中factory bean的時候,該容器不會返回factory bean本身,而是返回其生成的對象。Spring包括了大部分的通用資源和服務訪問抽象的Factory bean的實現,其中包括:
對JNDI查詢的處理,對代理對象的處理,對事務性代理的處理,對RMI代理的處理等,這些我們都可以看成是具體的工廠,看成是SPRING為我們建立好的工廠。也就是說Spring通過使用抽象工廠模式為我們準備了一系列工廠來生產一些特定的對象,免除我們手工重復的工作,我們要使用時只需要在IOC容器里配置好就能很方便的使用了。
現在我們來看看在Spring的事件機制,Spring中有3個標準事件,ContextRefreshEvent, ContextCloseEvent,RequestHandledEvent他們通過ApplicationEvent接口,同樣的如果需要自定義時間也只需要實現ApplicationEvent接口,參照ContextCloseEvent的實現可以定制自己的事件實現:
?1
public
?
class
?ContextClosedEvent?
extends
?ApplicationEvent?
{
?2
?3
????
public
?ContextClosedEvent(ApplicationContext?source)?
{
?4
????????
super
(source);
?5
????}
?6
?7
????
public
?ApplicationContext?getApplicationContext()?
{
?8
????????
return
?(ApplicationContext)?getSource();
?9
????}
10
}
可以通過顯現ApplicationEventPublishAware接口,將事件發布器耦合到ApplicationContext這樣可以使用 ApplicationContext框架來傳遞和消費消息,然后在ApplicationContext中配置好bean就可以了,在消費消息的過程中,接受者通過實現ApplicationListener接收消息。 


?2

?3



?4

?5

?6

?7



?8

?9

10

比如可以直接使用Spring的ScheduleTimerTask和TimerFactoryBean作為定時器定時產生消息,具體可以參見《Spring框架高級編程》。
TimerFactoryBean是一個工廠bean,對其中的ScheduleTimerTask進行處理后輸出,參考ScheduleTimerTask的實現發現它最后調用的是jre的TimerTask:
1
????
public
?
void
?setRunnable(Runnable?timerTask)?
{
2
????????
this
.timerTask?
=
?
new
?DelegatingTimerTask(timerTask);
3
????}
在書中給出了一個定時發送消息的例子,當然可以可以通過定時器作其他的動作,有兩種方法: 


2

3

1.定義MethodInvokingTimerTaskFactoryBean定義要執行的特定bean的特定方法,對需要做什么進行封裝定義;
2.定義TimerTask類,通過extends TimerTask來得到,同時對需要做什么進行自定義
然后需要定義具體的定時器參數,通過配置ScheduledTimerTask中的參數和timerTask來完成,以下是它需要定義的具體屬性,timerTask是在前面已經定義好的bean
1
????
private
?TimerTask?timerTask;
2
3
????
private
?
long
?delay?
=
?
0
;
4
5
????
private
?
long
?period?
=
?
0
;
6
7
????
private
?
boolean
?fixedRate?
=
?
false
;
最后,需要在ApplicationContext中注冊,需要把ScheduledTimerTask配置到FactoryBean - TimerFactoryBean,這樣就由IOC容器來管理定時器了。參照 
2

3

4

5

6

7

TimerFactoryBean的屬性,可以定制一組定時器。
?1
public
?
class
?TimerFactoryBean?
implements
?FactoryBean,?InitializingBean,?DisposableBean?
{
?2
?3
????
protected
?
final
?Log?logger?
=
?LogFactory.getLog(getClass());
?4
?5
????
private
?ScheduledTimerTask[]?scheduledTimerTasks;
?6
?7
????
private
?
boolean
?daemon?
=
?
false
;
?8
?9
????
private
?Timer?timer;
10
11
????

..
12
}
如果要發送時間我們只需要在定義好的ScheduledTimerTasks中publish定義好的事件就可以了。具體可以參考書中例子的實現,這里只是結合FactoryBean的原理做一些解釋。如果結合事件和定時器機制,我們可以很方便的實現heartbeat(看門狗),書中給出了這個例子,這個例子實際上結合了Spring事件和定時機制的使用兩個方面的知識 - 當然了還有IOC容器的知識(任何Spring應用我想都逃不掉IOC的魔爪:) 


?2

?3

?4

?5

?6

?7

?8

?9

10

11




12
