SpringIoC容器初始化—Resource定位源碼分析

NO IMAGE

Spring IoC容器的設計中,有兩個主要的容器系列。一個是實現了BeanFactory接口的簡單容器系列,這系列容器只實現了容器基本的功能;另一個是ApplicationContext應用上下文,它在簡單容器的基礎上增加了許多面向框架的特性,同時對應用環境做了許多適配。

IoC容器的初始化過程

Spring IoC容器的初始化過程分為三個階段:Resource定位、BeanDefinition的載入和向IoC容器註冊BeanDefinitionSpring把這三個階段分離,並使用不同的模塊來完成,這樣可以讓用戶更加靈活的對這三個階段進行擴展。

  • Resource定位指的是BeanDefinition的資源定位,它由ResourceLoader通過統一的Resource接口來完成,Resource對各種形式的BeanDefinition的使用都提供了統一的接口。
  • BeanDefinition的載入是把用戶定義好的Bean表示成IoC容器內部的數據結構,而這個容器內部的數據結構就是BeanDefinitionBeanDefinition實際上就是POJO對象在IoC容器中的抽象。通過BeanDefinitionIoC容器可以方便的對POJO對象進行管理。
  • IoC容器註冊BeanDefinition是通過調用BeanDefinitionRegistry接口的實現來完成的,這個註冊過程是把載入的BeanDefinitionIoC容器進行註冊。實際上,在IoC容器內部維護著一個HashMap,而這個註冊過程其實就將BeanDefinition添加至這個HashMap

我們可以自己定義ResourceBeanFactoryBeanDefinitionReader來初始化一個容器。如下代碼片段使用了DefaultListableBeanFactory作為實際使用的IoC容器。同時,創建IoC配置文件(dispatcher-servlet.xml)的抽象資源,這個抽象資源包含了BeanDefinition的定義信息。最後,還需要創建一個載入BeanDefinition的讀取器,此處使用XmlBeanDefinitionReader,通過一個回調配置給BeanFactory

ClassPathResource res = new ClassPathResource("dispatcher-servlet.xml");
DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
reader.loadBeanDefinitions(res);

我們也可以通過ApplicationContext創建一個IoC容器。在Spring中,系統已經提供許多定義好的容器實現,而不需要自己組裝。如下代碼片段以FileSystemXmlApplicationContext為例創建了一個IoC容器。

FileSystemXmlApplicationContext context = 
new FileSystemXmlApplicationContext("classpath:dispatcher-servlet.xml");

無論使用哪種方式初始化IoC容器,都會經歷上述三個階段。本篇文章將結合Spring 4.0.2源碼,並以FileSystemXmlApplicationContext為例對IoC容器初始化的第一階段,也就是Resource定位階段進行分析。

BeanDefinition的Resource定位

下圖展示了FileSystemXmlApplicationContext的繼承體系,FileSystemXmlApplicationContext繼承自AbstractApplicationContext,而AbstractApplicationContext又繼承自DefaultResourceLoaderDefaultResourceLoader實現了ResourceLoader接口。因此FileSystemXmlApplicationContext具備讀取定義了BeanDefinitionResource的能力。

SpringIoC容器初始化—Resource定位源碼分析

我們的分析入口是new FileSystemXmlApplicationContext("classpath:dispatcher-servlet.xml");,這句代碼調用了FileSystemXmlApplicationContext的構造方法。FileSystemXmlApplicationContext的構造方法源碼如下(只提取與本次分析關聯的代碼)。

    public FileSystemXmlApplicationContext(String configLocation) throws BeansException {
this(new String[]{configLocation}, true, (ApplicationContext)null);
}
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh,     
ApplicationContext parent) throws BeansException {
super(parent);
this.setConfigLocations(configLocations);
if(refresh) {
this.refresh();
}
}

在創建FileSystemXmlApplicationContext時,我們僅傳入了包含BeanDefinition的配置文件路徑(classpath:dispatcher-servlet.xml),由此調用FileSystemXmlApplicationContext(String configLocation)構造方法。接著,FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)構造方法被間接調用,在該構造方法內部,refresh方法完成了整個IoC容器的初始化。因此,refresh方法是我們分析的下一個入口。

refresh方法的具體實現定義在FileSystemXmlApplicationContext的父類AbstractApplicationContext中,對應的源碼如下。

    public void refresh() throws BeansException, IllegalStateException {
Object var1 = this.startupShutdownMonitor;
synchronized(this.startupShutdownMonitor) {
this.prepareRefresh();
ConfigurableListableBeanFactory beanFactory = this.obtainFreshBeanFactory();
this.prepareBeanFactory(beanFactory);
try {
this.postProcessBeanFactory(beanFactory);
this.invokeBeanFactoryPostProcessors(beanFactory);
this.registerBeanPostProcessors(beanFactory);
this.initMessageSource();
this.initApplicationEventMulticaster();
this.onRefresh();
this.registerListeners();
this.finishBeanFactoryInitialization(beanFactory);
this.finishRefresh();
} catch (BeansException var5) {
this.destroyBeans();
this.cancelRefresh(var5);
throw var5;
}
}
}

refresh方法中,通過obtainFreshBeanFactory方法,ConfigurableListableBeanFactory類型的BeanFactory被創建。我們接著進入obtainFreshBeanFactory方法,obtainFreshBeanFactory方法也定義在AbstractApplicationContext中。

    protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
this.refreshBeanFactory();
ConfigurableListableBeanFactory beanFactory = this.getBeanFactory();
if(this.logger.isDebugEnabled()) {
this.logger.debug("Bean factory for " + this.getDisplayName() + ": " + beanFactory);
}
return beanFactory;
}
protected abstract void refreshBeanFactory() throws BeansException, IllegalStateException;

我們重點關注refreshBeanFactory方法的實現。在AbstractApplicationContext中,refreshBeanFactory方法僅僅是個聲明,具體的實現委託給了子類完成。此處,refreshBeanFactory方法的具體實現定義在了AbstractRefreshableApplicationContextAbstractRefreshableApplicationContext正是繼承自AbstractApplicationContext,這點我們可以從上文的繼承體系圖可以得知。refreshBeanFactory方法在AbstractRefreshableApplicationContext中的定義如下。

    protected final void refreshBeanFactory() throws BeansException {
if(this.hasBeanFactory()) {
this.destroyBeans();
this.closeBeanFactory();
}
try {
DefaultListableBeanFactory ex = this.createBeanFactory();
ex.setSerializationId(this.getId());
this.customizeBeanFactory(ex);
this.loadBeanDefinitions(ex);
Object var2 = this.beanFactoryMonitor;
synchronized(this.beanFactoryMonitor) {
this.beanFactory = ex;
}
} catch (IOException var5) {
throw new ApplicationContextException("I/O error parsing bean definition source for " + this.getDisplayName(), var5);
}
}
protected abstract void loadBeanDefinitions(DefaultListableBeanFactory var1) throws BeansException, IOException;

refreshBeanFactory方法首先會判斷是否已經建立的BeanFactory,如果已經建立,那麼需要銷燬並關閉該BeanFactory。接著,refreshBeanFactory方法通過createBeanFactory方法創建了一個IoC容器供ApplicationContext使用,且這個IoC容器的實際類型為DefaultListableBeanFactory。同時,refreshBeanFactory方法將這個IoC容器作為參數,調用loadBeanDefinitions載入了BeanDefinition(本文暫不分析載入過程的具體操作)。

loadBeanDefinitions方法也僅僅在AbstractRefreshableApplicationContext中聲明,具體的實現定義在AbstractXmlApplicationContext中,從繼承體系圖我們可以得知AbstractXmlApplicationContext正是AbstractRefreshableApplicationContext的子類。loadBeanDefinitions方法對應的源碼如下。

    protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
beanDefinitionReader.setEnvironment(this.getEnvironment());
beanDefinitionReader.setResourceLoader(this);
beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
this.initBeanDefinitionReader(beanDefinitionReader);
this.loadBeanDefinitions(beanDefinitionReader);
}
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
Resource[] configResources = this.getConfigResources();
if(configResources != null) {
reader.loadBeanDefinitions(configResources);
}
String[] configLocations = this.getConfigLocations();
if(configLocations != null) {
reader.loadBeanDefinitions(configLocations);
}
}

loadBeanDefinitions(DefaultListableBeanFactory beanFactory)中,定義了BeanDefinition的讀入器beanDefinitionReaderSpring把定位、讀入和註冊的過程解耦,這正是體現之處之一。接著beanDefinitionReader作為參數,調用loadBeanDefinitions(XmlBeanDefinitionReader reader)方法,如果configResources為空,那麼reader就會根據configLocations調用readerloadBeanDefinitions去加載相應的Resource。在AbstractBeanDefinitionReaderXmlBeanDefinitionReader中個自定義了不同的loadBeanDefinitions方法,與我們本次分析相關的代碼定義在AbstractBeanDefinitionReader中,如下所示。

    public int loadBeanDefinitions(String... locations) throws BeanDefinitionStoreException {
Assert.notNull(locations, "Location array must not be null");
int counter = 0;
String[] var3 = locations;
int var4 = locations.length;
for(int var5 = 0; var5 < var4; ++var5) {
String location = var3[var5];
counter += this.loadBeanDefinitions(location);
}
return counter;
}
public int loadBeanDefinitions(String location) throws BeanDefinitionStoreException {
return this.loadBeanDefinitions(location, (Set)null);
}
public int loadBeanDefinitions(String location, Set<Resource> actualResources) throws BeanDefinitionStoreException {
ResourceLoader resourceLoader = this.getResourceLoader();
if(resourceLoader == null) {
throw new BeanDefinitionStoreException("Cannot import bean definitions from location [" + location + "]: no ResourceLoader available");
} else {
int loadCount;
if(!(resourceLoader instanceof ResourcePatternResolver)) {
Resource var11 = resourceLoader.getResource(location);
loadCount = this.loadBeanDefinitions((Resource)var11);
if(actualResources != null) {
actualResources.add(var11);
}
if(this.logger.isDebugEnabled()) {
this.logger.debug("Loaded " + loadCount + " bean definitions from location [" + location + "]");
}
return loadCount;
} else {
try {
Resource[] resource =
((ResourcePatternResolver)resourceLoader).getResources(location);
loadCount = this.loadBeanDefinitions(resource);
if(actualResources != null) {
Resource[] var6 = resource;
int var7 = resource.length;
for(int var8 = 0; var8 < var7; ++var8) {
Resource resource1 = var6[var8];
actualResources.add(resource1);
}
}
if(this.logger.isDebugEnabled()) {
this.logger.debug("Loaded " + loadCount + " bean definitions from location pattern [" + location + "]");
}
return loadCount;
} catch (IOException var10) {
throw new BeanDefinitionStoreException("Could not resolve bean definition resource pattern [" + location + "]", var10);
}
}
}
}

loadBeanDefinitions(String location, Set<Resource> actualResources)方法中,我們可以看到,Resource的定位工作交給了ResourceLoader來完成。對於取得Resource的具體過程,我們可以看看DefaultResourceLoader是怎樣完成的,對應源碼如下。

    public Resource getResource(String location) {
Assert.notNull(location, "Location must not be null");
if(location.startsWith("classpath:")) {
return new ClassPathResource(location.substring("classpath:".length()),
this.getClassLoader());
} else {
try {
URL ex = new URL(location);
return new UrlResource(ex);
} catch (MalformedURLException var3) {
return this.getResourceByPath(location);
}
}
}

由於我們傳入的locationclasspath:dispatcher-servlet.xml,因此getResource方法會生成一個ClassPathResource並返回,如果我們傳入的是一個文件路徑,那麼會調用getResourceByPath方法,getResourceByPath方法定義在FileSystemXmlApplicationContext中,對應的源碼如下。

    protected Resource getResourceByPath(String path) {
if(path != null && path.startsWith("/")) {
path = path.substring(1);
}
return new FileSystemResource(path);
}

到此,我們完成了IoC容器在初始化過程中的Resource定位過程的流程分析,這為接下來進行BeanDefinition數據的載入和解析創造了條件。

後續我會對BeanDefinition的載入和解析過程結合源碼進行分析,歡迎關注。若本文存在分析不妥之處,建議發送郵件至tinylcy (at) gmail.com交流。

相關文章

如何實現一個WebServer

如何實現一個分佈式RPC框架

如何實現一個JavaClass解析器

自己動手實現一個UnixShell