[TOC] 上篇已經對IoC容器的設計進行了分析( "Spring源碼閱讀 IoC容器解析" ),本篇將對 經典的繼承層次圖進行詳細的分析,在心中形成一個大致的印象,以便後面一步步調試源碼的時候,不會太眼花繚亂。讓我們一步步的前進吧... 繼承層次圖概覽 使用IDEA的繼承層次工具生成如下的圖(選中 ...
目錄
- 繼承層次圖概覽
- ConfigurableApplicationContext分析
- AbstractApplicationContext
- GenericApplicationContext
- GenericXmlApplicationContext
- StaticApplicationContext
- ResourceAdapterApplicationContext
- GenericGroovyApplicationContext
- AnnotationConfigApplicationContext
- AbstractRefreshableApplicationContext
- AbstractRefreshableConfigApplicationContext
- AbstractXmlApplicationContext
- FileSystemXmlApplicationContext
- ClassPathXmlApplicationContext
- WebApplicationContext
- 本文思維導圖
上篇已經對IoC容器的設計進行了分析(Spring源碼閱讀-IoC容器解析),本篇將對ApplicationContext
經典的繼承層次圖進行詳細的分析,在心中形成一個大致的印象,以便後面一步步調試源碼的時候,不會太眼花繚亂。讓我們一步步的前進吧...
繼承層次圖概覽
使用IDEA的繼承層次工具生成如下的圖(選中ApplicationContext --> Ctrl+H):
(溫馨提示:雙擊可查看高清大圖)
從上圖能很清楚的看出,ApplicationContext
的子介面分為兩個部分:
ConfigurableApplicationContext
:大部分的應用上下文都實現了該介面WebApplicationContext
:在web應用程式中使用
ConfigurableApplicationContext分析
從上面的類的繼承層次圖能看到,ConfigurableApplicationContext
是比較上層的一個介面,該介面也是比較重要的一個介面,幾乎所有的應用上下文都實現了該介面。該介面在ApplicationContext
的基礎上提供了配置應用上下文的能力,此外提供了生命周期的控制能力。先看一下該介面的繼承關係圖(為了更加簡潔,去掉了ApplicationContext
繼承的介面):
(溫馨提示:雙擊可查看高清大圖)
Closeable
介面用於關閉應用上下文,釋放所有的資源和鎖,這也包括摧毀所有緩存的單例的bean,常見的try-with-resources用法如下,執行完try體中的代碼後會自動的調用close
方法:
try (ConfigurableApplicationContext cac = ...) {
// 編寫代碼
...
}
Lifecycle
定義了啟動/停止生命周期的控制的一些方法,其中的方法如下:
void start(); // 啟動組件
void stop(); // 停止組件
boolean isRunning(); // 組件是否正在運行
接下來看一下ConfigurableApplicationContext
中的方法:
void setId(String id); // 設置應用上下文唯一的id
void setParent(ApplicationContext parent); // 設置應用程式上下文的父級
void setEnvironment(ConfigurableEnvironment environment); // 設置應用上下文的環境
ConfigurableEnvironment getEnvironment(); // 獲取應用上下文的環境
// 添加一個新的BeanFactoryPostProcessor
void addBeanFactoryPostProcessor(BeanFactoryPostProcessor postProcessor);
// 添加應用程式監聽器
void addApplicationListener(ApplicationListener<?> listener);
// 添加協議解析器,可能會覆蓋預設的規則
void addProtocolResolver(ProtocolResolver resolver);
// 載入或者刷新配置
void refresh() throws BeansException, IllegalStateException;
// 向JVM runtime註冊一個關閉鉤子,JVM關閉時關閉這個上下文
void registerShutdownHook();
// 應用程式上問下是否是激活狀態
boolean isActive();
// 獲取應用上下文內部的bean factory
ConfigurableListableBeanFactory getBeanFactory() throws IllegalStateException;
上面的這些方法基本上是提供了對某些特性的實現進行支撐的方法。
看了這麼多方法,下麵看一下ApplicationContext
的抽象的實現。
AbstractApplicationContext
AbstractApplicationContext
是ApplicationContext
介面的抽象實現,這個抽象類僅僅是實現了公共的上下文特性。這個抽象類使用了模板方法設計模式,需要具體的實現類去實現這些抽象的方法。對相關介面的實現如下:
ApplicationContext
介面的實現ConfigurableApplicationContext
介面的實現BeanFactory
介面的實現ListableBeanFactory
介面的實現HierarchicalBeanFactory
介面的實現MessageSource
介面的實現ResourcePatternResolver
的實現Lifecycle
介面的實現
本文不會詳細的講解這個類中的具體的實現細節,後面會有更加的詳細的介紹。下麵看下裡面的抽象方法:
// 刷新BeanFactory,用於執行實際的配置載入,該方法在其他的初始化工作之前被refresh()方法調用
protected abstract void refreshBeanFactory() throws BeansException, IllegalStateException;
// 關閉BeanFactory,用於釋放內部使用的BeanFactory·
protected abstract void closeBeanFactory();
// 獲取內部使用的BeanFactory
public abstract ConfigurableListableBeanFactory getBeanFactory() throws IllegalStateException;
那麼對需要實現的方法經過抽象後,只剩下少量的需要子類去實現的方法。
GenericApplicationContext
GenericApplicationContext
繼承自AbstractApplicationContext
,是為通用目的設計的,它能載入各種配置文件,例如xml,properties等等。它的內部持有一個DefaultListableBeanFactory
的實例,實現了BeanDefinitionRegistry
介面,以便允許向其應用任何bean的定義的讀取器。為了能夠註冊bean的定義,refresh()
只允許調用一次。常見的使用如下:
GenericApplicationContext ctx = new GenericApplicationContext();
XmlBeanDefinitionReader xmlReader = new XmlBeanDefinitionReader(ctx);
xmlReader.loadBeanDefinitions(new ClassPathResource("applicationContext.xml"));
PropertiesBeanDefinitionReader propReader = new PropertiesBeanDefinitionReader(ctx);
propReader.loadBeanDefinitions(new ClassPathResource("otherBeans.properties"));
ctx.refresh();
MyBean myBean = (MyBean) ctx.getBean("myBean");
..
這個類的實現沒有太多需要註意的地方,需要註意的有兩點:
- 內部使用的
DefaultListableBeanFactory
的實例,提供了一些方法來配置該實例,例如是否允許bean定義的覆蓋、是否允許bean之間的迴圈應用等等。 - 該類實現了
BeanDefinitionRegistry
,bean的定義註冊。以便能通過BeanDefinitionReader
讀取bean的配置,並註冊。BeanDefinitionRegistry
介面的實現是直接使用內部的DefaultListableBeanFactory
的實例。
GenericXmlApplicationContext
GenericXmlApplicationContext
繼承自GenericApplicationContext
,內置了對XML的支持。它非常的方便和靈活,是ClassPathXmlApplicationContext
和FileSystemXmlApplicationContext
的一種替代品。可以發現,它的內部有一個XmlBeanDefinitionReader
的實例,專門用於處理XML的配置。
StaticApplicationContext
StaticApplicationContext
繼承自GenericApplicationContext
,主要用於編程式的註入bean和消息,而不是從外部的配置源讀取bean的定義。主要是在測試時非常有用。通過閱讀源代碼可以看到,它的內部有一個StaticMessageSource
的實例,使用addMessage
方法添加消息。每次在編程式的註入bean時,都會創建一個GenericBeanDefinition
的實例。
ResourceAdapterApplicationContext
ResourceAdapterApplicationContext
繼承自GenericApplicationContext
,是為JCA(J2EE Connector Architecture)的ResourceAdapter設計的,主要用於傳遞BootstrapContext
的實例給實現了BootstrapContextAware
介面且由spring管理的bean。覆蓋了postProcessBeanFactory
方法來實現此功能。
GenericGroovyApplicationContext
GenericGroovyApplicationContext
繼承自GenericApplicationContext
,實現了GroovyObject
介面以便能夠使用點的語法(.xx)取代getBean
方法來獲取bean。它主要用於Groovy bean的定義,與GenericXmlApplicationContext
一樣,它也能解析XML格式定義的bean。內部使用GroovyBeanDefinitionReader
來完成groovy腳本和XML的解析。
AnnotationConfigApplicationContext
AnnotationConfigApplicationContext
繼承自GenericApplicationContext
,提供了註解配置(例如:Configuration、Component、inject等)和類路徑掃描(scan方法)的支持,可以使用register(Class<?>... annotatedClasses)
來註冊一個一個的進行註冊。實現了AnnotationConfigRegistry介面,來完成對註冊配置的支持,只有兩個方法:register和scan。內部使用AnnotatedBeanDefinitionReader
來完成註解配置的解析,使用ClassPathBeanDefinitionScanner
來完成類路徑下的bean定義的掃描。
AbstractRefreshableApplicationContext
AbstractRefreshableApplicationContext
繼承自AbstractApplicationContext
,支持多次進行刷新(多次調用refresh
方法),每次刷新時在內部創建一個新的bean工廠的實例。子類僅僅需要實現loadBeanDefinitions
方法,該方法在每次刷新時都會調用。
AbstractRefreshableConfigApplicationContext
AbstractRefreshableConfigApplicationContext
繼承自AbstractRefreshableApplicationContext
,添加了對指定的配置文件路徑的公共的處理,可以把他看作基於XML的應用上下文的基類。實現瞭如下的兩個介面:
BeanNameAware
用於設置上下文的bean的名稱,只有一個方法:void setBeanName(String name)
InitializingBean
用於上下文一切就緒後,如果還未刷新,那麼就執行刷新操作,只有一個方法:void afterPropertiesSet()
AbstractXmlApplicationContext
AbstractXmlApplicationContext
繼承自AbstractRefreshableConfigApplicationContext
,用於描繪包含能被XmlBeanDefinitionReader
所理解的bean定義的XML文檔。子類只需要實現getConfigResources
和getConfigLocations
來提供配置文件資源。
FileSystemXmlApplicationContext
FileSystemXmlApplicationContext
繼承自AbstractXmlApplicationContext
,用於解析文件系統中XML配置文件。文件的路徑可以是具體的文件路徑,例如:xxx/application.xml,也可以是ant風格的配置,例如:xxx/*-context.xml。
看下麵的通過文件路徑來獲取資源的代碼:
@Override
protected Resource getResourceByPath(String path) {
if (path.startsWith("/")) {
path = path.substring(1);
}
return new FileSystemResource(path);
}
文件路徑前面的/
會被去掉,無論是否路徑前面是否加上/
,文件路徑都會解析成相對路徑,即基於JVM的當前工作路徑。獲取到的資源對象是FileSystemResource
,用於處理文件系統相關的資源。
ClassPathXmlApplicationContext
ClassPathXmlApplicationContext
繼承自AbstractXmlApplicationContext
,和FileSystemXmlApplicationContext
類似,只不過ClassPathXmlApplicationContext
是用於處理類路徑下的XML配置文件。文件的路徑可以是具體的文件路徑,例如:xxx/application.xml,也可以是ant風格的配置,例如:xxx/*-context.xml。
WebApplicationContext
該介面提供了在web應用中的配置,介面提供了一個ServletContext getServletContext()
用來獲取ServletContext
對象。該介面會和ServletContext的一個屬性進行綁定,這個屬性就是ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE
。定義了三個作用域的名稱:SCOPE_REQUEST
,SCOPE_SESSION
,SCOPE_APPLICATION
。在工廠中的bean的名稱:SERVLET_CONTEXT_BEAN_NAME
。ServletContext初始化參數名稱:CONTEXT_PARAMETERS_BEAN_NAME
。在工廠中ServletContext屬性值環境bean的名稱:CONTEXT_ATTRIBUTES_BEAN_NAME
。
ConfigurableWebApplicationContext
ConfigurableWebApplicationContext
繼承自WebApplicationContext
和ConfigurableApplicationContext
,提供了web應用上下文的可配置的能力。相關介面定義如下:
// 設置web應用上下文的ServletContext
void setServletContext(@Nullable ServletContext servletContext);
// 設置web應用上下文的ServletConfig
void setServletConfig(@Nullable ServletConfig servletConfig);
// 獲取web應用上下文的ServletConfig
ServletConfig getServletConfig();
// 設置web應用上下文的命名空間
void setNamespace(@Nullable String namespace);
// 獲取web應用上下文的命名空間
String getNamespace();
// 以初始化參數的形式設置web應用上下文的配置文件位置
void setConfigLocation(String configLocation);
// 設置web應用上下文的配置文件的位置
void setConfigLocations(String... configLocations);
// 獲取web應用上下文的配置文件位置
String[] getConfigLocations();
上面的介面主要都是一些設置或者獲取的方法,在web應用上下文中需要用到的一些東西。
GenericWebApplicationContext
GenericWebApplicationContext
繼承自GenericApplicationContext
,實現了ConfigurableWebApplicationContext
和ThemeSource
介面。該類設計的目的不是在web.xml中進行聲明式的安裝,而是編程式的安裝,例如使用WebApplicationInitializers
來構建內嵌的上下文。該介面在ConfigurableWebApplicationContext
的內容都是一個偽實現,調用其中的大多數方法都會拋出異常。你也許註意到了,他實現了ThemeSource
介面,那麼他有什麼用呢?字面意思是主題源,它設計的目的主要是用於消息的國際化。
StaticWebApplicationContext
StaticWebApplicationContext
繼承自StaticApplicationContext
實現了ConfigurableWebApplicationContext
和ThemeSource
介面。該介面主要是用在測試的環境,不用於產品環境。
AbstractRefreshableWebApplicationContext
GenericWebApplicationContext
繼承自AbstractRefreshableConfigApplicationContext
,實現了ConfigurableWebApplicationContext
和ThemeSource
介面,主要是用於web環境下。在web程式啟動的時候,提供一個configLocations
屬性,通過ConfigurableWebApplicationContext
介面來進行填充。子類化這個介面是很簡單的,所有你所需要做的事情就是實現loadBeanDefinitions
方法,來實現你自己的bean定義的載入邏輯。
XmlWebApplicationContext
XmlWebApplicationContext
繼承自AbstractRefreshableWebApplicationContext
,接受能被XmlBeanDefinitionReader
所理解的XML文檔配置。對於根上下文,預設的配置文件路徑是/WEB-INF/applicationContext.xml
,對於命名空間為test-servlet的上下文,預設的配置文件路徑是/WEB-INF/test-servlet.xml
(就像servlet-name為test的DispatcherServlet實例)。
預設的配置文件路徑處理的代碼如下:
protected String[] getDefaultConfigLocations() {
if (getNamespace() != null) {
return new String[] {DEFAULT_CONFIG_LOCATION_PREFIX + getNamespace() + DEFAULT_CONFIG_LOCATION_SUFFIX};
}
else {
return new String[] {DEFAULT_CONFIG_LOCATION};
}
}
和其他的上下文一樣,bean定義的載入也是在void loadBeanDefinitions(DefaultListableBeanFactory beanFactory)
方法中,使用的是XmlBeanDefinitionReader
。
GroovyWebApplicationContext
GroovyWebApplicationContext
繼承自AbstractRefreshableWebApplicationContext
,實現了GroovyObject
介面,接受能被GroovyBeanDefinitionReader
所理解的groovy bean定義腳本和XML文檔配置。對於web環境,基本上是和GenericGroovyApplicationContext
是等價的。對於根上下文,預設的配置文件路徑是/WEB-INF/applicationContext.groovy
,對於命名空間為test-servlet的上下文,預設的配置文件路徑是/WEB-INF/test-servlet.xml
(就像servlet-name為test的DispatcherServlet實例)。
預設的配置文件路徑處理的代碼如下:
protected String[] getDefaultConfigLocations() {
if (getNamespace() != null) {
return new String[] {DEFAULT_CONFIG_LOCATION_PREFIX + getNamespace() + DEFAULT_CONFIG_LOCATION_SUFFIX};
}
else {
return new String[] {DEFAULT_CONFIG_LOCATION};
}
}
和其他的上下文一樣,bean定義的載入也是在void loadBeanDefinitions(DefaultListableBeanFactory beanFactory)
方法中,使用的是GroovyBeanDefinitionReader
。
AnnotationConfigWebApplicationContext
AnnotationConfigWebApplicationContext
繼承自AbstractRefreshableWebApplicationContext
,
接受註解的類作為輸入(特殊的@Configuration註解類,一般的@Component註解類,與JSR-330相容的javax.inject註解)。允許一個一個的註入,同樣也能使用類路徑掃描。對於web環境,基本上是和AnnotationConfigApplicationContext
等價的。使用AnnotatedBeanDefinitionReader
來對註解的bean進行處理,使用ClassPathBeanDefinitionScanner
來對類路徑下的bean進行掃描。
部分代碼如下:
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) {
AnnotatedBeanDefinitionReader reader = getAnnotatedBeanDefinitionReader(beanFactory);
ClassPathBeanDefinitionScanner scanner = getClassPathBeanDefinitionScanner(beanFactory);
...
if (!this.annotatedClasses.isEmpty()) {
....
reader.register(ClassUtils.toClassArray(this.annotatedClasses));
}
if (!this.basePackages.isEmpty()) {
....
scanner.scan(StringUtils.toStringArray(this.basePackages));
}
String[] configLocations = getConfigLocations();
if (configLocations != null) {
for (String configLocation : configLocations) {
try {
Class<?> clazz = ClassUtils.forName(configLocation, getClassLoader());
if (logger.isTraceEnabled()) {
logger.trace("Registering [" + configLocation + "]");
}
reader.register(clazz);
}
catch (ClassNotFoundException ex) {
....
}
}
}
}
}