《Spring技术内幕》——2.3节IoC容器的初始化过程-阿里云开发者社区

开发者社区> 华章出版社> 正文
登录阅读全文

《Spring技术内幕》——2.3节IoC容器的初始化过程

简介: 本节书摘来自华章社区《Spring技术内幕》一书中的第2章,第2.3节IoC容器的初始化过程,作者:计文柯,更多章节内容可以访问云栖社区“华章社区”公众号查看

2.3 IoC容器的初始化过程
简单来说,IoC容器的初始化是由前面介绍的refresh()方法来启动的,这个方法标志着IoC容器的正式启动。具体来说,这个启动包括BeanDefinition的Resouce定位、载入和注册三个基本过程。如果我们了解如何编程式地使用IoC容器,就可以清楚地看到Resource定位和载入过程的接口调用。在下面的内容里,我们将会详细分析这三个过程的实现。
在分析之前,要提醒读者注意的是,Spring把这三个过程分开,并使用不同的模块来完成,如使用相应的ResourceLoader、BeanDefinitionReader等模块,通过这样的设计方式, 可以让用户更加灵活地对这三个过程进行剪裁或扩展,定义出最适合自己的IoC容器的初始化过程。
第一个过程是Resource定位过程。这个Resource定位指的是BeanDefinition的资源定位,它由ResourceLoader通过统一的Resource接口来完成,这个Resource对各种形式的BeanDefinition的使用都提供了统一接口。对于这些BeanDefinition的存在形式,相信大家都不会感到陌生。比如,在文件系统中的Bean定义信息可以使用FileSystemResource来进行抽象;在类路径中的Bean定义信息可以使用前面提到的ClassPathResource来使用,等等。这个定位过程类似于容器寻找数据的过程,就像用水桶装水先要把水找到一样。
第二个过程是BeanDefinition的载入。这个载入过程是把用户定义好的Bean表示成IoC容器内部的数据结构,而这个容器内部的数据结构就是BeanDefinition。下面介绍这个数据结构的详细定义。具体来说,这个BeanDefinition实际上就是POJO对象在IoC容器中的抽象,通过这个BeanDefinition定义的数据结构,使IoC容器能够方便地对POJO对象也就是Bean进行管理。在下面的章节中,我们会对这个载入的过程进行详细的分析,使大家对整个过程有比较清楚的了解。
第三个过程是向IoC容器注册这些BeanDefinition的过程。这个过程是通过调用BeanDefinitionRegistry接口的实现来完成的。这个注册过程把载入过程中解析得到的BeanDefinition向IoC容器进行注册。通过分析,我们可以看到,在IoC容器内部将BeanDefinition注入到一个HashMap中去,IoC容器就是通过这个HashMap来持有这些BeanDefinition数据的。
值得注意的是,这里谈的是IoC容器初始化过程,在这个过程中,一般不包含Bean依赖注入的实现。在Spring IoC的设计中,Bean定义的载入和依赖注入是两个独立的过程。依赖注入一般发生在应用第一次通过getBean向容器索取Bean的时候。但有一个例外值得注意,在使用IoC容器时有一个预实例化的配置,通过这个预实例化的配置(具体来说,可以通过为Bean定义信息中的lazyinit属性),用户可以对容器初始化过程作一个微小的控制,从而改变这个被设置了lazyinit属性的Bean的依赖注入过程。举例来说,如果我们对某个Bean设置了lazyinit属性,那么这个Bean的依赖注入在IoC容器初始化时就预先完成了,而不需要等到整个初始化完成以后,第一次使用getBean时才会触发。
了解了IoC容器进行初始化的大致轮廓之后,下面我们详细地介绍在IoC容器的初始化过程中,BeanDefinition的资源定位、载入和解析过程是怎么实现的。
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已经为我们提供了一系列加载不同Resource的读取器的实现,而DefaultListableBeanFactory只是一个纯粹的IoC容器,需要为它配置特定的读取器才能完成这些功能。当然,有利就有弊,使用DefaultListableBeanFactory这种更底层的容器,能提高定制IoC容器的灵活性。
回到我们经常使用的ApplicationContext上来,例如FileSystemXmlApplicationContext、ClassPathXmlApplicationContext以及XmlWebApplicationContext等。简单地从这些类的名字上分析,可以清楚地看到它们可以提供哪些不同的Resource读入功能,比如FileSystemXmlApplicationContext可以从文件系统载入Resource,ClassPathXmlApplication-Context可以从Class Path载入Resource,XmlWebApplicationContext可以在Web容器中载入Resource,等等。
下面以FileSystemXmlApplicationContext为例,通过分析这个ApplicationContext的实现来看看它是怎样完成这个Resource定位过程的。作为辅助,我们可以在图2-5中看到相应的ApplicationContext继承体系。


9b7773a3b43151a6b8b6370977d0682e3db8c66f

从源代码实现的角度,我们可以近距离关心以FileSystemXmlApplicationConext为核心的继承体系,如图2-6所示。


180a36fa9d8cdafc04da0240a96825e5a1c9107d

从图2-6中可以看到,这个FileSystemXmlApplicationContext已经通过继承Abstract-ApplicationContext具备了ResourceLoader读入以Resource定义的BeanDefinition的能力,因为AbstractApplicationContext的基类是DefaultResourceLoader。下面让我们看看FileSystemXmlApplicationContext的具体实现,如代码清单2-4所示。
代码清单2-4 FileSystemXmlApplicationContext的实现

public class FileSystemXmlApplicationContext extends AbstractXmlApplicationContext {
    public FileSystemXmlApplicationContext() {
    }
    public FileSystemXmlApplicationContext(ApplicationContext parent) {
        super(parent);
    }
    //这个构造函数的configLocation包含的是BeanDefinition所在的文件路径
    public FileSystemXmlApplicationContext(String configLocation) throws BeansException {
        this(new String[] {configLocation}, true, null);
    }
    //这个构造函数允许configLocation包含多个BeanDefinition的文件路径
    public FileSystemXmlApplicationContext(String[] configLocations) throws BeansException {
        this(configLocations, true, null);
    }
    //这个构造函数在允许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);
    }
    //在对象的初始化过程中,调用refresh函数载入BeanDefinition,这个refresh启动了
    //BeanDefinition的载入过程,我们会在下面进行详细分析
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh,
    ApplicationContext parent)
            throws BeansException {
        super(parent);
        setConfigLocations(configLocations);
        if (refresh) {
            refresh();
        }
    }
    //这是应用于文件系统中Resource的实现,通过构造一个FileSystemResource来得到一个在文件
    //系统中定位的BeanDefinition
    //这个getResourceByPath是在BeanDefinitionReader的loadBeanDefintion中被调用的
    //loadBeanDefintion采用了模板模式,具体的定位实现实际上是由各个子类来完成的
protected Resource getResourceByPath(String path) {
    if (path != null && path.startsWith("/")) {
        path = path.substring(1);
    }
    return new FileSystemResource(path);
    }
}

在FileSystemApplicationContext中,我们可以看到在构造函数中,实现了对configuration进行处理的功能,让所有配置在文件系统中的,以XML文件方式存在的BeanDefnition都能够得到有效的处理,比如,实现了getResourceByPath方法,这个方法是一个模板方法,是为读取Resource服务的。对于IoC容器功能的实现,这里没有涉及,因为它继承了AbstractXmlApplicationContext,关于IoC容器功能相关的实现,都是在FileSystemXmlApplicationContext中完成的,但是在构造函数中通过refresh来启动IoC容器的初始化,这个refresh方法非常重要,也是我们以后分析容器初始化过程实现的一个重要入口。
注意 FileSystemApplicationContext是一个支持XML定义BeanDefinition的ApplicationContext,并且可以指定以文件形式的BeanDefinition的读入,这些文件可以使用文件路径和URL定义来表示。在测试环境和独立应用环境中,这个ApplicationContext是非常有用的。
根据图2-7的调用关系分析,我们可以清楚地看到整个BeanDefinition资源定位的过程。这个对BeanDefinition资源定位的过程,最初是由refresh来触发的,这个refresh的调用是在FileSystemXmlBeanFactory的构造函数中启动的,大致的调用过程如图2-8所示。
从Spring源代码实现的角度,我们可以通过Eclipse的功能,查看详细的方法调用栈,如图2-7所示。
大家看了上面的调用过程可能会比较好奇,这个FileSystemXmlApplicationContext在什么地方定义了BeanDefinition的读入器BeanDefinitionReader,从而完成BeanDefinition信息的读入呢 ?在前面分析过,在IoC容器的初始化过程中,BeanDefinition资源的定位、读入和注册过程是分开进行的,这也是解耦的一个体现。关于这个读入器的配置,可以到FileSystemXmlApplicationContext的基类AbstractRefreshableApplicationContext中看看它是怎样实现的。


103a4ed82fca1886cdff7c9f936c2b9ce1005000

我们重点看看AbstractRefreshableApplicationContext的refreshBeanFactory方法的实现,这个refreshBeanFactory被FileSystemXmlApplicationContext构造函数中的refresh调用。在这个方法中,通过createBeanFactroy构建了一个IoC容器供ApplicationContext使用。这个IoC容器就是我们前面提到过的DefaultListableBeanFactory,同时,它启动了loadBeanDefinitions来载入BeanDefinition,这个过程和前面以编程式的方法来使用IoC容器(XmlBeanFactory)的过程非常类似。
从代码清单2-4中可以看到,在初始化FileSystmXmlApplicationContext的过程中,通过IoC容器的初始化的refresh来启动整个调用,使用的IoC容器是DefultListableBeanFactory。具体的资源载入在XmlBeanDefinitionReader读入BeanDefinition时完成,在XmlBeanDefinitionReader的基类AbstractBeanDefinitionReader中可以看到这个载入过程的具体实现。对载入过程的启动,可以在AbstractRefreshableApplicationContext的loadBeanDefinitions方法中看到,如代码清单2-5所示。
代码清单2-5 AbstractRefreshableApplicationContext对容器的初始化

protected final void refreshBeanFactory() throws BeansException {
    //这里判断,如果已经建立了BeanFactory,则销毁并关闭该BeanFactory
    if (hasBeanFactory()) {
        destroyBeans();
        closeBeanFactory();
    }
    //这里是创建并设置持有的DefaultListableBeanFactor的地方同时调用
    //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);
    }
}
//这就是在上下文中创建DefaultListableBeanFactory的地方,而getInternalParentBeanFactory()
//的具体实现可以
//参看AbstractApplicationContext中的实现,会根据容器已有的双亲IoC容器的信息来生成
// DefaultListableBeanFactory的双亲IoC容器
protected DefaultListableBeanFactory createBeanFactory() {
    return new DefaultListableBeanFactory(getInternalParentBeanFactory());
}
//这里是使用BeanDefinitionReader载入Bean定义的地方,因为允许有多种载入方式,虽然用得
//最多的是XML定义的形式,这里通过一个抽象函数把具体的实现委托给子类来完成
    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的路径模式进行解析,比如我们设定的各种Ant格式的路径定义,得到需要的
//Resource集合,这些Resource集合指向我们已经定义好的BeanDefinition信息,可以是多个文件
    if (resourceLoader instanceof ResourcePatternResolver) {
        try {
//调用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 {
        // 调用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方法,默认的实现是得到
    //一个ClassPathContextResource,这个方法常常会用子类来实现
    return getResourceByPath(location);
        }
    }
}

前面我们看到的getResourceByPath会被子类FileSystemXmlApplicationContext实现,这个方法返回的是一个 FileSystemResource对象,通过这个对象,Spring可以进行相关的I/O操作,完成BeanDefinition的定位。分析到这里已经一目了然,它实现的就是对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,那么会对应生成其他种类的Resource,比如ClassPathResource、ServletContextResource等。关于Spring中Resource的种类,可以在图2-9的Resource类的继承关系中了解。作为接口的Resource定义了许多与I/O相关的操作,这些操作也都可以从图2-9中的Resource的接口定义中看到。这些接口对不同的Resource实现代表着不同的意义,是Resource的实现需要考虑的。Resource接口的实现在Spring中的设计如图2-9所示。


9b85ae85e4f9f865eb53bca9bef605e04936cf08

从图2-9中我们可以看到Resource的定义和它的继承关系,通过对前面的实现原理的分析,我们以FileSystemXmlApplicationContext的实现原理为例子,了解了Resource定位问题的解决方案,即以FileSystem方式存在的Resource的定位实现。在BeanDefinition定位完成的基础上,就可以通过返回的Resource对象来进行BeanDefinition的载入了。在定位过程完成以后,为BeanDefinition的载入创造了I/O操作的条件,但是具体的数据还没有开始读入。这些数据的读入将在下面介绍的BeanDefinition的载入和解析中来完成。仍然以水桶为例子,这里就像用水桶去打水,要先找到水源。这里完成对Resource的定位,就类似于水源已经找到了,下面就是打水的过程了,类似于把找到的水装到水桶里的过程。找水不简单,但是与打水相比,我们发现打水更需要技巧。
2.3.2 BeanDefinition的载入和解析
在完成对代表BeanDefinition的Resource定位的分析后,下面来了解整个BeanDefinition信息的载入过程。对IoC容器来说,这个载入过程,相当于把定义的BeanDefinition在IoC容器中转化成一个Spring内部表示的数据结构的过程。IoC容器对Bean的管理和依赖注入功能的实现,是通过对其持有的BeanDefinition进行各种相关操作来完成的。这些BeanDefinition数据在IoC容器中通过一个HashMap来保持和维护。当然这只是一种比较简单的维护方式,如果需要提高IoC容器的性能和容量,完全可以自己做一些扩展。
下面,从DefaultListableBeanFactory的设计入手,看看IoC容器是怎样完成BeanDefinition载入的。这个DefaultListableBeanFactory在前面已经碰到过多次,相信大家对它一定不会感到陌生。在开始分析之前,先回到IoC容器的初始化入口,也就是看一下refresh方法。这个方法的最初是在FileSystemXmlApplicationContext的构造函数中被调用的,它的调用标志着容器初始化的开始,这些初始化对象就是BeanDefinition数据,初始化入口如代码清单2-7所示。
代码清单2-7 启动BeanDefinition的载入

1. public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh,
ApplicationContext parent) throws BeansException {

    super(parent);
    setConfigLocations(configLocations);
    //这里调用容器的refresh,是载入BeanDefinition的入口
    if (refresh) {
        refresh();
    }
}

对容器的启动来说,refresh是一个很重要的方法,下面介绍一下它的实现。该方法在AbstractApplicationContext类(它是FileSystemXmlApplicationContext的基类)中找到,它详细地描述了整个ApplicationContext的初始化过程,比如BeanFactory的更新,MessageSource和PostProcessor的注册,等等。这里看起来更像是对ApplicationContext进行初始化的模板或执行提纲,这个执行过程为 Bean的生命周期管理提供了条件。熟悉IoC容器使用的读者,从这一系列调用的名字就能大致了解应用上下文初始化的主要内容。这里就直接列出代码,不做太多的解释了。这个IoC容器的refresh过程如代码清单2-8所示。
代码清单2-8 对IoC容器执行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 {
            //设置BeanFactoy的后置处理
            postProcessBeanFactory(beanFactory);
            //调用BeanFactory的后处理器,这些后处理器是在Bean定义中向容器注册的
            invokeBeanFactoryPostProcessors(beanFactory);
            //注册Bean的后处理器,在Bean创建过程中调用。
            registerBeanPostProcessors(beanFactory);
            //对上下文中的消息源进行初始化
            initMessageSource();
            //初始化上下文中的事件机制
            initApplicationEventMulticaster();
            //初始化其他的特殊Bean
            onRefresh();
            //检查监听Bean并且将这些Bean向容器注册
            registerListeners();
            //实例化所有的(non-lazy-init)单件
            finishBeanFactoryInitialization(beanFactory);
            //发布容器事件,结束Refresh过程
            finishRefresh();
        }
        catch (BeansException ex) {
            //为防止Bean资源占用,在异常处理中,销毁已经在前面过程中生成的单件Bean
            destroyBeans();
            // 重置 'active'标志
            cancelRefresh(ex);
            throw ex;
        }
    }
}

进入到AbstractRefreshableApplicationContext的refreshBeanFactory()方法中,在这个方法中创建了BeanFactory。在创建IoC容器前,如果已经有容器存在,那么需要把已有的容器销毁和关闭,保证在refresh以后使用的是新建立起来的IoC容器。这么看来,这个refresh非常像重启动容器,就像重启动计算机那样。在建立好当前的IoC容器以后,开始了对容器的初始化过程,比如BeanDefinition的载入,具体的交互过程如图2-10所示。
可以从AbstractRefreshableApplicationContext的refreshBeanFactory方法开始,了解这个Bean定义信息载入的过程,具体实现如代码清单2-9所示。
代码清单2-9 AbstractRefreshableApplicationContext的refreshBeanFactory方法

protected final void refreshBeanFactory() throws BeansException {
    if (hasBeanFactory()) {
        destroyBeans();
        closeBeanFactory();
    }
    try {
        //创建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);
    }
}



这里调用的loadBeanDefinitions实际上是一个抽象方法,那么实际的载入过程发生在哪里呢?我们看看前面提到的loadBeanDefinitions在AbstractRefreshableApplicationContext的子类AbstractXmlApplicationContext中的实现,在这个loadBeanDefinitions中,初始化了读取器XmlBeanDefinitionReader,然后把这个读取器在IoC容器中设置好(过程和编程式使用XmlBeanFactory是类似的),最后是启动读取器来完成BeanDefinition在IoC容器中的载入,如代码清单2-10所示。
代码清单2-10 AbstractXmlApplicationContext中的loadBeanDefinitions

public abstract class AbstractXmlApplicationContext extends
AbstractRefreshableConfigApplicationContext {
    public AbstractXmlApplicationContext() {
    }
    public AbstractXmlApplicationContext(ApplicationContext parent) {
        super(parent);
}
//这里是实现loadBeanDefinitions的地方
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws IOException {
    //创建XmlBeanDefinitionReader,并通过回调设置到BeanFactory中去,创建BeanFactory
    //的过程可以参考上文对编程式使用IoC容器的相关分析,这里和前面一样,使用的也是
    DefaultListableBeanFactory
    XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinition
    Reader(beanFactory);
    //这里设置XmlBeanDefinitionReader,为XmlBeanDefinitionReader配
    //ResourceLoader,因为DefaultResourceLoader是父类,所以this可以直接被使用
    beanDefinitionReader.setResourceLoader(this);
    beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
    //这是启动Bean定义信息载入的过程
    initBeanDefinitionReader(beanDefinitionReader);
    loadBeanDefinitions(beanDefinitionReader);
}
protected void initBeanDefinitionReader(XmlBeanDefinitionReader beanDefinitionReader) {
}

接着就是loadBeanDefinitions调用的地方,首先得到BeanDefinition信息的Resource定位,然后直接调用 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;
}
}

通过以上对实现原理的分析,我们可以看到,在初始化FileSystmXmlApplicationContext的过程中是通过调用IoC容器的refresh来启动整个BeanDefinition的载入过程的,这个初始化是通过定义的XmlBeanDefinitionReader来完成的。同时,我们也知道实际使用的IoC容器是DefultListableBeanFactory,具体的Resource载入在XmlBeanDefinitionReader读入BeanDefinition时实现。因为Spring可以对应不同形式的BeanDefinition。由于这里使用的是XML方式的定义,所以需要使用XmlBeanDefinitionReader。如果使用了其他的BeanDefinition方式,就需要使用其他种类的BeanDefinitionReader来完成数据的载入工作。在XmlBeanDefinitionReader的实现中可以看到,是在reader.loadBeanDefinitions中开始进行BeanDefinition的载入的,而这时XmlBeanDefinitionReader的父类AbstractBean-Definition-Reader已经为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;
}

这里调用的是loadBeanDefinitions(Resource res)方法,但这个方法在AbstractBean-DefinitionReader类里是没有实现的,它是一个接口方法,具体的实现在XmlBean-DefinitionReader中。在读取器中,需要得到代表XML文件的Resource,因为这个Resource对象封装了对XML文件的I/O操作,所以读取器可以在打开I/O流后得到XML的文件对象。有了这个文件对象以后,就可以按照Spring的Bean定义规则来对这个XML的文档树进行解析了,这个解析是交给BeanDefinitionParserDelegate来完成的,看起来实现脉络很清楚。具体可以参考代码实现,如代码清单2-13所示。
代码清单2-13 对BeanDefinition的载入实现

//这里是调用的入口
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的地方创建
        Document doc = this.documentLoader.loadDocument(
                inputSource, getEntityResolver(), this.errorHandler,
                validationMode, isNamespaceAware());
        //这里启动的是对BeanDefinition解析的详细过程,这个解析会使用到Spring的Bean
        //配置规则,是我们下面需要详细讲解的内容
        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对象,这里就不详细分析了。我们关心的是Spring的BeanDefinion是怎样按照Spring的Bean语义要求进行解析并转化为容器内部数据结构的,这个过程是在registerBeanDefinitions(doc, resource)中完成的。具体的过程是由BeanDefinitionDocumentReader来完成的,这个registerBeanDefinition还对载入的Bean的数量进行了统计。具体过程如代码清单2-14所示。
代码清单2-14 registerBeanDefinition的代码实现

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的载入分成两部分,首先通过调用XML的解析器得到document对象,但这些document对象并没有按照Spring的Bean规则进行解析。在完成通用的XML解析以后,才是按照Spring的Bean规则进行解析的地方,这个按照Spring的Bean规则进行解析的过程是在 documentReader中实现的。这里使用的documentReader是默认设置好的DefaultBean-DefinitionDocumentReader。这个DefaultBeanDefinitionDocumentReader的创建是在后面的方法中完成的,然后再完成BeanDefinition的处理,处理的结果由BeanDefinitionHolder对象来持有。这个BeanDefinitionHolder除了持有BeanDefinition对象外,还持有其他与BeanDefinition的使用相关的信息,比如Bean的名字、别名集合等。这个BeanDefinition-Holder的生成是通过对Document文档树的内容进行解析来完成的,可以看到这个解析过程是由BeanDefinition-ParserDelegate来实现(具体在processBeanDefinition方法中实现)的,同时这个解析是与Spring对BeanDefinition的配置规则紧密相关的。具体的实现原理如代码清单2-15所示。
代码清单2-15 创建BeanDefinitionDocumentReader

protected BeanDefinitionDocumentReader createBeanDefinitionDocumentReader() {
    return BeanDefinitionDocumentReader.class.cast(BeanUtils.instantiateClass
    (this.documentReaderClass));
    }
    //这样,得到了 documentReader以后,为具体的Spring Bean的解析过程准备好了数据
    //这里是处理BeanDefinition的地方,具体的处理委托给 BeanDefinitionParserDelegate来
    //完成,ele对应在Spring BeanDefinition中定义的XML元素
    protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate 
    delegate) {
        /* BeanDefinitionHolder是BeanDefinition对象的封装类,封装了
        BeanDefinition,Bean的名字和别名。用它来完成向IoC容器注册。
        得到这个 BeanDefinitionHolder就意味着BeanDefinition是通过
    BeanDefinitionParserDelegate对XML元素的信息按照Spring的Bean规则进行解析得到的*/
    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容器注册完以后,发送消息
        getReaderContext().fireComponentRegistered(new
        BeanComponentDefinition(bdHolder));
    }
}

具体的Spring BeanDefinition的解析是在BeanDefinitionParserDelegate中完成的。这个类里包含了对各种Spring Bean定义规则的处理,感兴趣的读者可以仔细研究。比如我们最熟悉的对Bean元素的处理是怎样完成的,也就是怎样处理在XML定义文件中出现的这个最常见的元素信息。在这里会看到对那些熟悉的BeanDefinition定义的处理,比如id、name、aliase等属性元素。把这些元素的值从XML文件相应的元素的属性中读取出来以后,设置到生成的BeanDefinitionHolder中去。这些属性的解析还是比较简单的。对于其他元素配置的解析,比如各种Bean的属性配置,通过一个较为复杂的解析过程,这个过程是由parseBeanDefinitionElement来完成的。解析完成以后,会把解析结果放到BeanDefinition对象中并设置到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>();
    if (StringUtils.hasLength(nameAttr)) {
        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);
    }
    //这个方法会引发对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依据XML的定义被创建的过程。这个BeanDefinition可以看成是对定义的抽象,如图2-11所示。这个数据对象中封装的数据大多都是与定义相关的,也有很多就是我们在定义Bean时看到的那些Spring标记,比如常见的init-method、destroy-method、factory-method,等等,这个BeanDefinition数据类型是非常重要的,它封装了很多基本数据,这些基本数据都是IoC容器需要的。有了这些基本数据,IoC容器才能对Bean配置进行处理,才能实现相应的容器特性。


adb507bb61356ce2cf8c22478b8bda6aa3dbda07

beanClass、description、lazyInit这些属性都是在配置bean时经常碰到的,都集中在这里。这个BeanDefinition是IoC容器体系中非常重要的核心数据结构。通过解析以后,这些数据已经做好在IoC容器里大显身手的准备了。对BeanDefinition元素的处理如代码清单2-17所示,在这个过程中可以看到对Bean定义的相关处理,比如对元素attribute值的处理,对元素属性值的处理,对构造函数设置的处理,等等。
代码清单2-17 对BeanDefinition定义元素的处理

public AbstractBeanDefinition parseBeanDefinitionElement(
        Element ele, String beanName, BeanDefinition containingBean) {
    this.parseState.push(new BeanEntry(beanName));
    //这里只读取定义的<bean>中设置的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元素进行属性解析,并设置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>的构造函数设置
        parseConstructorArgElements(ele, bd);
        //解析<bean>的property设置
        parsePropertyElements(ele, bd);
        parseQualifierElements(ele, bd);
        bd.setResource(this.readerContext.getResource());
        bd.setSource(extractSource(ele));
        return bd;
    }
//下面这些异常是在配置Bean出现问题时经常会看到的,原来是在这里抛出的这些检查是在
//createBeanDefinition时进行的,会检查Bean的class设置是否正确,比如这个类是否能找到
    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中的定义进行解析,比如从属性元素集合到具体的每一个属性元素,然后才是对具体的属性值的处理。根据解析结果,对这些属性值的处理会被封装成PropertyValue对象并设置到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中已经有同名的property存在,则不进行解析,直接返回。也就是说,
        //如果在同一个Bean中有同名的property设置,那么起作用的只是第一个
        if (bd.getPropertyValues().contains(propertyName)) {
            error("Multiple 'property' definitions for property '"
            + propertyName + "'", ele);
            return;
        }
        //这里是解析property值的地方,返回的对象对应对Bean定义的property属性设置的
        //解析结果,这个解析结果会封装到PropertyValue对象中,然后设置
        到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);
        }
            else {
                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,创建一个ref的数据对象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,创建一个value的数据对象TypedStringValue ,这个对象封装了value的信息
    else if (hasValueAttribute) {
        TypedStringValue valueHolder = new TypedStringValue(ele.
        getAttribute(VALUE_ATTRIBUTE));
        valueHolder.setSource(extractSource(ele));
        return valueHolder;
    }
    //如果还有子元素,触发对子元素的解析
    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等各种元素都会在这里进行解析,生成对应的数据对象,比如ManagedList、ManagedArray、ManagedSet等。这些Managed类是Spring对具体的BeanDefinition的数据封装。具体的解析过程读者可以去查看自己感兴趣的部分,比如 parseArrayElement、parseListElement、parseSetElement、parseMapElement、parsePropElement对应着不同类型的数据解析,同时这些具体的解析方法在BeanDefinitionParserDelegate类中也都能够找到。因为方法命名很清晰,所以从方法名字上就能够很快地找到。下面以对Property的元素进行解析的过程为例,通过它的实现来说明具体的解析过程是怎样完成的,如代码清单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这类配置定义的数据封装,如代码清单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) {
    //遍历所有的元素节点,并判断其类型是否为Element
    for (int i = 0; i < elementNodes.getLength(); i++) {
        Node node = elementNodes.item(i);
        if (node instanceof Element && !DomUtils.nodeNameEquals(node, DESCRIPTION_ELEMENT)) {
    //加入到target中,target是一个ManagedList,同时触发对下一层子元素的解析过程,
    //这是一个递归的调用
            target.add(parsePropertySubElement((Element) node, bd, defaultElementType));
        }
    }
}

经过这样逐层地解析,我们在XML文件中定义的BeanDefinition就被整个载入到了IoC容器中,并在容器中建立了数据映射。在IoC容器中建立了对应的数据结构,或者说可以看成是POJO对象在IoC容器中的抽象,这些数据结构可以以AbstractBeanDefinition为入口,让IoC容器执行索引、查询和操作。简单的POJO操作背后其实蕴含着一个复杂的抽象过程,经过以上的载入过程,IoC容器大致完成了管理Bean对象的数据准备工作(或者说是初始化过程)。但是,重要的依赖注入实际上在这个时候还没有发生,现在,在IoC容器BeanDefinition中存在的还只是一些静态的配置信息。严格地说,这时候的容器还没有完全起作用,要完全发挥容器的作用,还需完成数据向容器的注册。
2.3.3 BeanDefinition在IoC容器中的注册
前面已经分析过BeanDefinition在IoC容器中载入和解析的过程。在这些动作完成以后,用户定义的BeanDefinition信息已经在IoC容器内建立起了自己的数据结构以及相应的数据表示,但此时这些数据还不能供IoC容器直接使用,需要在IoC容器中对这些BeanDefinition数据进行注册。这个注册为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完成后进行的,注册的调用过程如图2-12所示。


9ec93c077c96b9afda17cdcc7f91b4e3912b47d1

从源代码实现的角度,可以看到相关的调用关系如图2-13所示。
我们跟踪以上的代码调用去看一下具体的注册实现,在DefaultListableBeanFactory中实现了BeanDefinitionRegistry的接口,这个接口的实现完成BeanDefinition向容器的注册。这个注册过程不复杂,就是把解析得到的BeanDefinition设置到hashMap中去。需要注意的是,如果遇到同名的BeanDefinition,进行处理的时候需要依据allowBeanDefinitionOverriding的配置来完成。具体的实现如代码清单2-21所示。
图2-13 registerBeanDefinition的调用关系
代码清单2-21 BeanDefinition注册的实现

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,保证数据的一致性
    synchronized (this.beanDefinitionMap) {
    //这里检查是不是有相同名字的BeanDefinition已经在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中已经建立了整个Bean的配置信息,而且这些BeanDefinition已经可以被容器使用了,它们都在beanDefinitionMap里被检索和使用。容器的作用就是对这些信息进行处理和维护。这些信息是容器建立依赖反转的基础,有了这些基础数据,下面我们看一下在IoC容器中,依赖注入是怎样完成的。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: