Spring 系列教程之默认标签的解析

Spring 系列教程之默认标签的解析

之前提到过 Spring 中的标签包括默认标签和自定义标签两种，而两种标签的用法以及解析方式存在着很大的不同，本章节重点带领读者详细分析默认标签的解析过程。

默认标签的解析是在 parsedefaultelement(ele， delegate) 函数中进行的，函数中的功能逻辑一目了然，分别对4种不同标签(import、 alias、bean 和 beans)做了不同的处理。

private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {
    // 对 import 标签的处理
    if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) {
        importBeanDefinitionResource(ele);
    }
    // 对 alias 标签的处理
    else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) {
        processAliasRegistration(ele);
    }
    // 对 bean 标签的处理
    else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) {
        processBeanDefinition(ele, delegate);
    }
    // 对 beans 标签的处理
    else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) {
        doRegisterBeanDefinitions(ele);
    }
}

3.1 bean 标签的解析及注册

在4种标签的解析中，对 bean 标签的解析最为复杂也最为重要，所以我们从此标签开始深入分析，如果能理解此标的解析过程，其他他标签的解析自然会迎刃而解。首先我们进入函数 processBeanDefinition(ele， delegate)

protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
    //1. 委托给 delegate 解析 class、name、id、 alias 之类的属性
    BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
    if (bdHolder != null) {
        //2. 继续解析自定义属性
        bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
        try {
            //3. 对解析后的的 bdholder 进行注册
            BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
        }
        catch (BeanDefinitionStoreException ex) {
            getReaderContext().error("Failed to register bean definition with name '" +
                    bdHolder.getBeanName() + "'", ele, ex);
        }
        //4. 通知相关的监听器，这个 bean 已经加载完成了
        getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
    }
}

咋一看，似乎一头雾水，没有以前的函数那样清晰的逻辑。大致的逻辑总结如下：

(1) 首先委托 BeanDefinitionParserDelegate 类的 parseBeanDefinitionElement 方法进行元素解析，返回 Beandefinitionholder 类型的实例 beholder，经过这个方法后，bdholder 实例已经包含我们配置文件中配置的各种属性了，例如 class、name、id、 alias 之类的属性。

(2) 当返回的 bdholder 不为空的情况下若存在默认标签的子节点下再有自定义属性，还需要再次对自定义标签进行解析。

(3) 解析完成后，需要对解析后的的 bdholder 进行注册，同样，注册操作委托给了 BeanDefinitionReaderUtils 的 registerBeanDefinition 方法。

(4) 最后发出响应事件，通知相关的监听器，这个 bean 已经加载完成了。

3.1.1 解析 BeanDefinition

下面我们就针对各个操作做具体分析。首先我们从元素解析及信息提取开始，也就是 BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele)，进入 BeanDefinitionParserDelegate 类的 parseBeanDefinitionElement() 方法。

public BeanDefinitionHolder parseBeanDefinitionElement(Element ele) {
    return parseBeanDefinitionElement(ele, null);
}

//
public BeanDefinitionHolder parseBeanDefinitionElement(Element ele, BeanDefinition containingBean) {
    // 解析 id 属性
    String id = ele.getAttribute(ID_ATTRIBUTE);
    // 解析 name 属性
    String nameAttr = ele.getAttribute(NAME_ATTRIBUTE);

    // 分割 name 属性
    List<String> aliases = new ArrayList<String>();
    if (StringUtils.hasLength(nameAttr)) {
        String[] nameArr = StringUtils.tokenizeToStringArray(nameAttr, MULTI_VALUE_ATTRIBUTE_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);
    }

    AbstractBeanDefinition beanDefinition = parseBeanDefinitionElement(ele, beanName, containingBean);
    if (beanDefinition != null) {
        if (!StringUtils.hasText(beanName)) {
            try {
                if (containingBean != null) {
                    // 如果不存在 beanName 那么根据 Spring 中提供的命名规则为当前 bean 生成对应 beanName
                    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;
}

以上便是对默认标签解析的全过程了。当然，对 Spring 的解析犹如洋葱剩皮一样，一层层地进行，尽管现在只能看到对属性 id 以及 name 的解析，但是很庆幸，思路我们已经了解了。在开始对属性展开全面解析前， Spring 在外层又做了一个当前层的功能架构，在当前层完成的主要工作包括如下内容：

(1) 提取元素中的 id 以及 name 属性。

(2) 进一步解析其他所有属性并统一封装至 GenericBeanDefinition 类型的实例中。

(3) 如果检测到 bean 没有指定 beanname，那么使用默认规则为此 Bean 生成 beanname

(4) 将获取到的信息封装到 BeanDefinitionHolder 的实例中。

我们进一步地查看步骤(2)中ヌ对标签其他属性的解析过程。

// 进一步解析其它属性，若抛出异常则返回null
public AbstractBeanDefinition parseBeanDefinitionElement(
            Element ele, String beanName, BeanDefinition containingBean) {

    this.parseState.push(new BeanEntry(beanName));

    // 解析 class 属性
    String className = null;
    if (ele.hasAttribute(CLASS_ATTRIBUTE)) { //CLASS_ATTRIBUTE="class"
        className = ele.getAttribute(CLASS_ATTRIBUTE).trim();
    }

    try {
        // 解析 parent 属性
        String parent = null;
        if (ele.hasAttribute(PARENT_ATTRIBUTE)) {
            parent = ele.getAttribute(PARENT_ATTRIBUTE);
        }
        // 创建用于承载属性的 AbstractBeanDefinition 类型的 GenericBeanDefinition
        AbstractBeanDefinition bd = createBeanDefinition(className, parent);

        // 硬编码解析默认 bean 的各种属性
        parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);
        bd.setDescription(DomUtils.getChildElementValueByTagName(ele, DESCRIPTION_ELEMENT));

        // 解析元属性
        parseMetaElements(ele, bd);
        // 解析 lookup-method 属性
        parseLookupOverrideSubElements(ele, bd.getMethodOverrides());
        // 解析 replaced-method 属性
        parseReplacedMethodSubElements(ele, bd.getMethodOverrides());

        // 解析构造函数参数
        parseConstructorArgElements(ele, bd);
        // 解析 property 子元素
        parsePropertyElements(ele, bd);
        // 解析 qualifier 子元素
        parseQualifierElements(ele, bd);

        bd.setResource(this.readerContext.getResource());
        bd.setSource(extractSource(ele));

        return bd;
    }
    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;
}

终于，bean 标签的所有属性，不论常用的还是不常用的我们都看到了，尽管有些复杂的属性还需要进一步的解析，不过丝毫不会影响我们兴奋的心情。接下来，我们继续一些复杂标签属性的解析。

1. 创建用于属性承载的 BeanDefinition

BeanDefinition 是一个接口，在 Spring 中存在三种实现: RootBeanDefinition、ChildBeanDefinition 以及 GenericBeanDefinition。三种实现均继承了 AbstractBeanDefiniton，其中 BeanDefinition 是配置文件 元素标签在容器中的内部表示形式。元素标签拥有 class、 scope、lazy-innt 等配置属性，BeanDefinition 则提供了相应的 bean Class、 scope、 lazylnit 属性， BeanDefinition 和 中的属性是一一对应的。其中 RootBeanDefinition 是最常用的实现类，它对应一般性的 元素标签， GenericBeanDefinition 是自2.5版本以后新加入的 bean 文件配置属性定义类，是一站式服务类。

在配置文件中可以定义父 和子 ，父 用 RootBeanDefinition 表示，而子 用 ChildBeanDefinition 表示，而没有父 的 就使用 RootBeanDefinition 表示。AbstractBeanDefinition 对两者共同的类信息进行抽象。

Spring 通过 BeanDefinition 将配置文件中的 配置信息转换为容器的内部表示，并将这些 BeanDefiniton 注册到 BeanDefinitonRegistry 中。 Spring 容器的 BeanRegistry 就像是 Spring 配置信息的内存数据库，主要是以 map 的形式保存，后续操作直接从 BeanDefinitionRegistry 中读取配置信息。它们之间的关系如图3-2所示。

由此可知,要解析属性首先要创建用于承载属性的实例，也就是创建 GenericBeanDefinition 类型的实例。而代码 createBeanDefinition(className, parent) 的作用就是实现此功能。

protected AbstractBeanDefinition createBeanDefinition(String className, String parentName)
            throws ClassNotFoundException {
    return BeanDefinitionReaderUtils.createBeanDefinition(
            parentName, className, this.readerContext.getBeanClassLoader());
}

org.springframework.beans.factory.support.BeanDefinitionReaderUtils

public static AbstractBeanDefinition createBeanDefinition(
            String parentName, String className, ClassLoader classLoader) throws ClassNotFoundException {

    GenericBeanDefinition bd = new GenericBeanDefinition();
    // parentName 可能为空
    bd.setParentName(parentName);
    if (className != null) {
        // 如果 className 不为空，则使用以传入的 classLoader 加载类对象，否则只记录 className
        if (classLoader != null) {
            bd.setBeanClass(ClassUtils.forName(className, classLoader));
        }
        else {
            bd.setBeanClassName(className);
        }
    }
    return bd;
}

2. 解析各种属性

当我们创建了 bean 信息的承载实例后，便可以进行 bean 信息的各种属性解析了，首先我们进入 parseBeanDefinitionAttributes(ele, beanName, containingBean, bd) 方法。 parseBeanDefinitionAttributes() 方法是对 element 所有元素属性进行解析:

public AbstractBeanDefinition parseBeanDefinitionAttributes(Element ele, String beanName,
            BeanDefinition containingBean, AbstractBeanDefinition bd) {

    // 解析 singleton 属性，废弃了
    if (ele.hasAttribute(SINGLETON_ATTRIBUTE)) {
        error("Old 1.x 'singleton' attribute in use - upgrade to 'scope' declaration", ele);
    }
    // 解析 scope 属性
    else if (ele.hasAttribute(SCOPE_ATTRIBUTE)) {
        bd.setScope(ele.getAttribute(SCOPE_ATTRIBUTE));
    }
    // 在嵌入 beanDifinition 情况下且没有单独指定 scope 属性则使用父类默认的属性
    else if (containingBean != null) {
        bd.setScope(containingBean.getScope());
    }

    // 解析 abstract 属性
    if (ele.hasAttribute(ABSTRACT_ATTRIBUTE)) {
        bd.setAbstract(TRUE_VALUE.equals(ele.getAttribute(ABSTRACT_ATTRIBUTE)));
    }

    // 解析 lazy-init 属性
    String lazyInit = ele.getAttribute(LAZY_INIT_ATTRIBUTE);
    if (DEFAULT_VALUE.equals(lazyInit)) {
        lazyInit = this.defaults.getLazyInit();
    }
    bd.setLazyInit(TRUE_VALUE.equals(lazyInit));

    // 解析 autowire 属性
    String autowire = ele.getAttribute(AUTOWIRE_ATTRIBUTE);
    bd.setAutowireMode(getAutowireMode(autowire));

    // 解析 dependency-check 属性
    String dependencyCheck = ele.getAttribute(DEPENDENCY_CHECK_ATTRIBUTE);
    bd.setDependencyCheck(getDependencyCheck(dependencyCheck));

    // 解析 dependency-on 属性
    if (ele.hasAttribute(DEPENDS_ON_ATTRIBUTE)) {
        String dependsOn = ele.getAttribute(DEPENDS_ON_ATTRIBUTE);
        bd.setDependsOn(StringUtils.tokenizeToStringArray(dependsOn, MULTI_VALUE_ATTRIBUTE_DELIMITERS));
    }

    // 解析 dependency-candidate 属性
    String autowireCandidate = ele.getAttribute(AUTOWIRE_CANDIDATE_ATTRIBUTE);
    if ("".equals(autowireCandidate) || DEFAULT_VALUE.equals(autowireCandidate)) {
        String candidatePattern = this.defaults.getAutowireCandidates();
        if (candidatePattern != null) {
            String[] patterns = StringUtils.commaDelimitedListToStringArray(candidatePattern);
            bd.setAutowireCandidate(PatternMatchUtils.simpleMatch(patterns, beanName));
        }
    }
    else {
        bd.setAutowireCandidate(TRUE_VALUE.equals(autowireCandidate));
    }

    // 解析 primary 属性
    if (ele.hasAttribute(PRIMARY_ATTRIBUTE)) {
        bd.setPrimary(TRUE_VALUE.equals(ele.getAttribute(PRIMARY_ATTRIBUTE)));
    }

    // 解析 init-method 属性
    if (ele.hasAttribute(INIT_METHOD_ATTRIBUTE)) {
        String initMethodName = ele.getAttribute(INIT_METHOD_ATTRIBUTE);
        if (!"".equals(initMethodName)) {
            bd.setInitMethodName(initMethodName);
        }
    }
    else {
        if (this.defaults.getInitMethod() != null) {
            bd.setInitMethodName(this.defaults.getInitMethod());
            bd.setEnforceInitMethod(false);
        }
    }

    // 解析 destory-method 属性
    if (ele.hasAttribute(DESTROY_METHOD_ATTRIBUTE)) {
        String destroyMethodName = ele.getAttribute(DESTROY_METHOD_ATTRIBUTE);
        bd.setDestroyMethodName(destroyMethodName);
    }
    else {
        if (this.defaults.getDestroyMethod() != null) {
            bd.setDestroyMethodName(this.defaults.getDestroyMethod());
            bd.setEnforceDestroyMethod(false);
        }
    }

    // 解析 factory-method 属性
    if (ele.hasAttribute(FACTORY_METHOD_ATTRIBUTE)) {
        bd.setFactoryMethodName(ele.getAttribute(FACTORY_METHOD_ATTRIBUTE));
    }   

    // 解析 factory-bean 属性
    if (ele.hasAttribute(FACTORY_BEAN_ATTRIBUTE)) {
        bd.setFactoryBeanName(ele.getAttribute(FACTORY_BEAN_ATTRIBUTE));
    }

    return bd;
}

我们可以清楚地看到 Spring 完成了对所有 bean 属性的解析，这些属性中有很多是我们经常使用的，同日时我相信也一定会有或多或少的属性是读者不熟悉或者是没有使用过的，有兴趣的读者可以查阅相关资料进一步了解每个属性。

3. 解析子元素 meta

在开始解析元数据的分析前,我们先回顾下元数据 meta 属性的使用。

<bean id="myTestBean" class="MyTestBean">
    <meta key="key" value="value"/>
</bean>

这段代码并不会体现在 MyTestBean 的属性当中，而是一个额外的声明，当需要使用里面的信息的时候可以通过 BeanDefinition 的 getAttribute(key) 方法进行获取。

对 meta 属性的解解析代码如下：

public void parseMetaElements(Element ele, BeanMetadataAttributeAccessor attributeAccessor) {
    // 获取当前节点的所有子元素
    NodeList nl = ele.getChildNodes();
    for (int i = 0; i < nl.getLength(); i++) {
        Node node = nl.item(i);
        // 提取 meta
        if (isCandidateElement(node) && nodeNameEquals(node, META_ELEMENT)) {
            Element metaElement = (Element) node;
            String key = metaElement.getAttribute(KEY_ATTRIBUTE);
            String value = metaElement.getAttribute(VALUE_ATTRIBUTE);
            // 使用 key/value 构建 BeanMetadataAttribute
            BeanMetadataAttribute attribute = new BeanMetadataAttribute(key, value);
            attribute.setSource(extractSource(metaElement));
            // 记录信息
            attributeAccessor.addMetadataAttribute(attribute);
        }
    }
}

4. 解析子元素 lookup-method

同样，子元素 lookup-method 似乎并不是很常用，但是在某些时候它的确是非常有用的属性，通常我们称它为获取器注入。引用《Spring in Action》中的一句话：获取器注入是种特殊的方法注入，它是把一个方法声明为返回某种类型的 bean，但实际要返回的 bean 是在配置文件里面配置的，此方法可用在设计有些可插拔的功能上，解除程序依赖。我们看看具体的应用。

(1) 首先我们创建一个父类

public class User {
    public void showMe() {
        System.out.println("i am a user");
    }
}

(2) 创建子类并覆盖 showMe()

public class Teacher extends User {
    public void showMe() {
        System.out.println("i am a teacher");
    }
}

(3) 创建调用方法

public abstract class GetBeanTest {

    public abstract User getBean();

    public void showMe() {
        getBean().showMe();
    }
}

(4) 创建测试方法

public class Main {

    public static void main(String[] args) {
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
                "spring/lookup/lookup-test.xml");
        GetBeanTest test = (GetBeanTest) context.getBean("getBeanTest");
        test.showMe();
    }
}

到现在为止，除了配置文件外，整个测测试方法就完成了，如果之前没有接触过获取器注入的读者们可能会有疑问：抽象方法还没有被实现，怎么可以直接调用呢？答案就在 Spring 为我们提供的获取器中，我们看看配置文件是怎么配置的。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="getBeanTest" class="spring.lookup.GetBeanTest">
        <lookup-method name="getBean" bean="student"/>
    </bean>

    <bean id="teacher" class="spring.lookup.bean.Teacher"/>
    <bean id="student" class="spring.lookup.bean.Student"/>
</beans>

在配置文件中，我们看到了源码解析中提到的 lookup-method 子元素，这个配置完成的功能是动态地将 teacher 所代表的 bean 作为 getbean 的返回值,运行测试方法我们会看到控制台上的输出：i am Teacher

当我们的业务变更或者在其他情况下, teacher 里面的业务逻辑已经不再符合我们的业务要求，需要进行替换怎么办呢？这是我们需要增加新的逻辑类：

public class Student extends User {

    public void showMe() {
        System.out.println("i am a student");
    }
}

同时修改配制文件：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="getBeanTest" class="spring.lookup.GetBeanTest">
        <lookup-method name="getBean" bean="student"/>
    </bean>

    <bean id="teacher" class="spring.lookup.bean.Teacher"/>
    <bean id="student" class="spring.lookup.bean.Student"/>
</beans>

再次运行测试类,你会发现不一样的结果：

i am Student

至此，我们已经初步了解了 lookup-method 子元素所提供的大致功能，相信这时再次去看它的属性提取源码会觉得更有针对性。

public void parseLookupOverrideSubElements(Element beanEle, MethodOverrides overrides) {
    NodeList nl = beanEle.getChildNodes();
    for (int i = 0; i < nl.getLength(); i++) {
        Node node = nl.item(i);
        if (isCandidateElement(node) && nodeNameEquals(node, LOOKUP_METHOD_ELEMENT)) {
            Element ele = (Element) node;
            String methodName = ele.getAttribute(NAME_ATTRIBUTE);
            String beanRef = ele.getAttribute(BEAN_ELEMENT);
            LookupOverride override = new LookupOverride(methodName, beanRef);
            override.setSource(extractSource(ele));
            overrides.addOverride(override);
        }
    }
}

上面的代码很眼熟,似乎与 parseMetaElements() 的代码大同小异，最大的区别就是在 if 判断中的节点名称在这里被修改为 LOOKUP_METHOD_ELEMENT。还有，在数据存储上面通过使用 LookupOverride 类型的实体类来进行数据承载并记录在 AbstractBeanDefinition 中的 methodOverrides 属性中。

5. 解析子元素 replaced-method

这个方法主要是对 bean中 replaced-method 子元素的提取，在开始提取分析之前我们还是预先介绍下这个元素的用法。方法替换：可以在运行时用新的方法替换现有的方法。与之前的 look-up 不同的是，replaced-method 不但可以动态地替换返回实体 bean，而且还能动态地更改原有方法的逻辑。我们来看看使用示例。

(1) 在 changeMe() 中完成某个业务逻辑

public class TestChangeMethod {
    public void changeMe() {
        System.out.println("changeMe");
    }
}

(2) 在运营一段时间后需要改变原有的业务逻辑

public class TestMethodReplacer implements MethodReplacer {

    @Override
    public Object reimplement(Object obj, Method method, Object[] args) throws Throwable {
        System.out.println("我替换了原有的方法");
        return null;
    }
}

(3) 使替换后的类生效

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="testChangeMethod" class="spring.replaced_method.TestChangeMethod">
        <replaced-method name="changeMe" replacer="replacer"/>
    </bean>

    <bean id="replacer" class="spring.replaced_method.TestMethodReplacer"/>
</beans>

(4) 测试

public static void main(String[] args) {
    ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
            "spring/replaced_method/replaced-method-test.xml");
    TestChangeMethod test = (TestChangeMethod) context.getBean("testChangeMethod");
    test.changeMe();
}

好了，运行测试类就可以看到预期的结果了，控制台成功打印出 "我替换了原有的方法"，也就是说我们做到了动态替换原有方法，知道了这个元素的用法，我们再次来看元素的提取过程：

public void parseReplacedMethodSubElements(Element beanEle, MethodOverrides overrides) {
    NodeList nl = beanEle.getChildNodes();
    for (int i = 0; i < nl.getLength(); i++) {
        Node node = nl.item(i);
        // 仅当在 Spring 默认 bean 的子元素下且为 <replaced-method/> 时有效
        if (isCandidateElement(node) && nodeNameEquals(node, REPLACED_METHOD_ELEMENT)) {
            Element replacedMethodEle = (Element) node;
            // 提取要替换的旧方法
            String name = replacedMethodEle.getAttribute(NAME_ATTRIBUTE);
            // 提取新的替换方法
            String callback = replacedMethodEle.getAttribute(REPLACER_ATTRIBUTE);
            ReplaceOverride replaceOverride = new ReplaceOverride(name, callback);

            List<Element> argTypeEles = DomUtils.getChildElementsByTagName(replacedMethodEle, ARG_TYPE_ELEMENT);
            for (Element argTypeEle : argTypeEles) {
                String match = argTypeEle.getAttribute(ARG_TYPE_MATCH_ATTRIBUTE);
                // 记录参数
                match = (StringUtils.hasText(match) ? match : DomUtils.getTextValue(argTypeEle));
                if (StringUtils.hasText(match)) {
                    replaceOverride.addTypeIdentifier(match);
                }
            }
            replaceOverride.setSource(extractSource(replacedMethodEle));
            overrides.addOverride(replaceOverride);
        }
    }
}

我们可以看到无论是 1ook-up 还是 replaced-method 都是构造了一个 MethodOverride，并最终记录在了 AbstractBeanDefinition 中的 methodOverrides 属性中。而这个属性如何使用以完成它所提供的功能我们会在后续的章节进行详细地介绍。

6. 解析子元素 constructor-arg

对构造函数的解析是非常常用的，同日时也是非常复杂的，也相信大家对构造函数的配置都不陌生，举个简单的小例子

上面的配置是 Spring 构造函数配置中最基础的配置，实现的功能就是对 Hellobean 自动寻找对应的构造函数，并在初始化的日时候将设置的参数传入进去。那么让我们来看看具体的XML解析过程。

对于 constructor-arg 子元素的解析，Spring 是通过 parseConstructorArgElements 函数来实现的，具体的代码如下：

public void parseConstructorArgElements(Element beanEle, BeanDefinition bd) {
    NodeList nl = beanEle.getChildNodes();
    for (int i = 0; i < nl.getLength(); i++) {
        Node node = nl.item(i);
        if (isCandidateElement(node) && nodeNameEquals(node, CONSTRUCTOR_ARG_ELEMENT)) {
            parseConstructorArgElement((Element) node, bd);
        }
    }
}

这个结构似乎我们可以想象得到，遍遍历所有子元素，也就是提取所有 constructor-arg，然后进行解析，但是具体的解析却被放置在了另个函数 parseConstructorArgElement 中，具体代码如下：

public void parseConstructorArgElement(Element ele, BeanDefinition bd) {
    // 提取 index 属性
    String indexAttr = ele.getAttribute(INDEX_ATTRIBUTE);
    // 提取 type 属性
    String typeAttr = ele.getAttribute(TYPE_ATTRIBUTE);
    // 提取 name 属性
    String nameAttr = ele.getAttribute(NAME_ATTRIBUTE);
    if (StringUtils.hasLength(indexAttr)) {
        try {
            int index = Integer.parseInt(indexAttr);
            if (index < 0) {
                error("'index' cannot be lower than 0", ele);
            }
            else {
                try {
                    this.parseState.push(new ConstructorArgumentEntry(index));
                    // 解析 ele 对应的属性元素
                    Object value = parsePropertyValue(ele, bd, null);
                    ConstructorArgumentValues.ValueHolder valueHolder = new ConstructorArgumentValues.ValueHolder(value);
                    if (StringUtils.hasLength(typeAttr)) {
                        valueHolder.setType(typeAttr);
                    }
                    if (StringUtils.hasLength(nameAttr)) {
                        valueHolder.setName(nameAttr);
                    }
                    valueHolder.setSource(extractSource(ele));
                    if (bd.getConstructorArgumentValues().hasIndexedArgumentValue(index)) {
                        error("Ambiguous constructor-arg entries for index " + index, ele);
                    }
                    else {
                        // 不允许重复指定相同参数
                        bd.getConstructorArgumentValues().addIndexedArgumentValue(index, valueHolder);
                    }
                }
                finally {
                    this.parseState.pop();
                }
            }
        }
        catch (NumberFormatException ex) {
            error("Attribute 'index' of tag 'constructor-arg' must be an integer", ele);
        }
    }
    else {
        // 没有 index 属性，自动寻找
        try {
            this.parseState.push(new ConstructorArgumentEntry());
            Object value = parsePropertyValue(ele, bd, null);
            ConstructorArgumentValues.ValueHolder valueHolder = new ConstructorArgumentValues.ValueHolder(value);
            if (StringUtils.hasLength(typeAttr)) {
                valueHolder.setType(typeAttr);
            }
            if (StringUtils.hasLength(nameAttr)) {
                valueHolder.setName(nameAttr);
            }
            valueHolder.setSource(extractSource(ele));
            bd.getConstructorArgumentValues().addGenericArgumentValue(valueHolder);
        }
        finally {
            this.parseState.pop();
        }
    }
}

上面一段看似复杂的代码让很多人失去了耐心，但是，涉及的逻辑其实并不复杂，首先是提取 constructor-arg 上必要要的属性(index、type、name)

1. 如果配置中指定了 index属性，那么操作步如下

   (1) 解析 constructor-arg 的子元素。

   (2) 使用 ConstructorArgumentValues.ValueHolder 类型来封装解析出来的元素。

   (3) 将 type、name 和 index 属性一并封装在 ConstructorArgumentValues.ValueHolder 类型中并添加至当前 BeanDefinition 的 constructorArgumentValues 的 indexdArgumentValues 属性中。

2. 如如果没有指定 index属性，那么操作步聚如下

   (1) 解析 constructor-arg 的子元素。

   (2) 使用 ConstructorArgumentValues.ValueHolder 类型来封装解析出来的元素。

   (3) 将 type、name和 index 属性一并封装在 ConstructorArgumentValues.ValueHolder 类型中并添加至当前 BeanDefinition 的 constructorArgumentValues 的 genericArgumentValues 属性中。可以看到，对于是否制定 index 属性来讲，Spring的处理流程是不同的，关键在于属性信息被保存的位置。

可以看到，对于是否制定 index 属性来讲，Spring的处理流程是不同的，关键在于属性信息被保存的位置。

那么了解了整个流程后，我们尝试着进一步了解解析构造函数配置中子元素的过程，进入 parsePropertyValue() 方法：

public Object parsePropertyValue(Element ele, BeanDefinition bd, String propertyName) {
    String elementName = (propertyName != null) ?
                    "<property> element for property '" + propertyName + "'" :
                    "<constructor-arg> element";

    // 一个属性只能对应一种类型：ref, value, list, etc.
    NodeList nl = ele.getChildNodes();
    Element subElement = null;
    for (int i = 0; i < nl.getLength(); i++) {
        Node node = nl.item(i);
        // 对应 description 或者 meta 不处理
        if (node instanceof Element && !nodeNameEquals(node, DESCRIPTION_ELEMENT) &&
                !nodeNameEquals(node, META_ELEMENT)) {
            if (subElement != null) {
                error(elementName + " must not contain more than one sub-element", ele);
            }
            else {
                subElement = (Element) node;
            }
        }
    }

    // 解析 constructor-arg 上的 ref 属性
    boolean hasRefAttribute = ele.hasAttribute(REF_ATTRIBUTE);
    // 解析 constructor-arg 上的 value 属性
    boolean hasValueAttribute = ele.hasAttribute(VALUE_ATTRIBUTE);
    if ((hasRefAttribute && hasValueAttribute) ||
            ((hasRefAttribute || hasValueAttribute) && subElement != null)) {
        /**
         * 在 constructor-arg 上不存在：
         *  1. 同时既有 ref 属性又有 value 属性
         *  2. 存在 ref 属性或者 value 属性且有子元素
         */
        error(elementName +
                " is only allowed to contain either 'ref' attribute OR 'value' attribute OR sub-element", ele);
    }

    if (hasRefAttribute) {
        // ref 属性的处理，使用 RuntimeBeanReference 封装对应的 ref 名称
        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;
    }
    else if (hasValueAttribute) {
        // value 属性的处理，使用 TypedStringValue 封装
        TypedStringValue valueHolder = new TypedStringValue(ele.getAttribute(VALUE_ATTRIBUTE));
        valueHolder.setSource(extractSource(ele));
        return valueHolder;
    }
    else if (subElement != null) {
        // 解析子元素
        return parsePropertySubElement(subElement, bd);
    }
    else {
        // 既没有 ref 也没有 value 也没有子元素， spring 蒙圈了
        error(elementName + " must specify a ref or value", ele);
        return null;
    }
}

从代码上来看，对构造函数中属性元素的解析，经历了以下几个过程。

(1) 略过 description或者meta

(2) 提取 constructor-arg 上的 ref 和 value 属性，以便于根据规则验证正确性，其规则为在 constructor-arg 上不存在以下情况。

* 同时既有 ref 属性又有 value 属性
* 存在 ref 属性或者 value 属性且又有子元素

(3) ref 属性的处理。使用 RuntimeBeanReference 封装对应的 ref 名称，如

<constructor-arg ref="a"/>

(4) value 属性的处理。使用 TypedStringValue 封装，如

<constructor-arg value="a"/>

(5) 子元素的处理，如

<constructor-arg>
    <map>
        <entry key="key" value="value"/>
    </map>
</constructor-arg>

而对于子元素的处理，例如这里提到的在构造函数中又嵌人了子元素 map 是怎么实现的呢? parsePropertySubElement() 中实现了对各种子元素的分类处理：

public Object parsePropertySubElement(Element ele, BeanDefinition bd) {
    return parsePropertySubElement(ele, bd, null);
}

public Object parsePropertySubElement(Element ele, BeanDefinition bd, String defaultValueType) {
    if (!isDefaultNamespace(ele)) {
        return parseNestedCustomElement(ele, bd);
    }
    else if (nodeNameEquals(ele, BEAN_ELEMENT)) {
        BeanDefinitionHolder nestedBd = parseBeanDefinitionElement(ele, bd);
        if (nestedBd != null) {
            nestedBd = decorateBeanDefinitionIfRequired(ele, nestedBd, bd);
        }
        return nestedBd;
    }
    else if (nodeNameEquals(ele, REF_ELEMENT)) {
        // A generic reference to any name of any bean.
        String refName = ele.getAttribute(BEAN_REF_ATTRIBUTE);
        boolean toParent = false;
        if (!StringUtils.hasLength(refName)) {
            // 解析 local
            refName = ele.getAttribute(LOCAL_REF_ATTRIBUTE);
            if (!StringUtils.hasLength(refName)) {
                // 解析 parent
                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;
    }
    // 对 idref 元素的解析
    else if (nodeNameEquals(ele, IDREF_ELEMENT)) {
        return parseIdRefElement(ele);
    }
    // 对 value 元素的解析
    else if (nodeNameEquals(ele, VALUE_ELEMENT)) {
        return parseValueElement(ele, defaultValueType);
    }
    // 对 null 元素的解析
    else if (nodeNameEquals(ele, NULL_ELEMENT)) {
        // It's a distinguished null value. Let's wrap it in a TypedStringValue
        // object in order to preserve the source location.
        TypedStringValue nullHolder = new TypedStringValue(null);
        nullHolder.setSource(extractSource(ele));
        return nullHolder;
    }
    // 解析 array 子元素
    else if (nodeNameEquals(ele, ARRAY_ELEMENT)) {
        return parseArrayElement(ele, bd);
    }
    // 解析 list 子元素
    else if (nodeNameEquals(ele, LIST_ELEMENT)) {
        return parseListElement(ele, bd);
    }
    // 解析 set 子元素
    else if (nodeNameEquals(ele, SET_ELEMENT)) {
        return parseSetElement(ele, bd);
    }
    // 解析 map 子元素
    else if (nodeNameEquals(ele, MAP_ELEMENT)) {
        return parseMapElement(ele, bd);
    }
    // 解析 props 子元素
    else if (nodeNameEquals(ele, PROPS_ELEMENT)) {
        return parsePropsElement(ele);
    }
    else {
        error("Unknown property sub-element: [" + ele.getNodeName() + "]", ele);
        return null;
    }
}

可以看到，在上面的函数中实现了所有可支持的子类的分类处理，到这里，我们已经大致理清构造函数的解析流程，至于再深入的解析读者有兴趣可以自己去探索。

7. 解析子元素 property

parsePropertyElement() 函数完成了对 property 属性的提取, property使用方式如下：

<bean id="myTestBean" class="spring.MyTestBean">
    <property name="str" value="value"/>
</bean>

或

<bean id="myTestBean" class="spring.MyTestBean">
    <property name="list">
        <list>
            <value>aa</value>
            <value>bb</value>
        </list>
    </property>
</bean>

而具体的解析过程如下:

public void parsePropertyElements(Element beanEle, BeanDefinition bd) {
    NodeList nl = beanEle.getChildNodes();
    for (int i = 0; i < nl.getLength(); i++) {
        Node node = nl.item(i);
        if (isCandidateElement(node) && nodeNameEquals(node, PROPERTY_ELEMENT)) {
            parsePropertyElement((Element) node, bd);
        }
    }
}

有了之前分析构造函数的经验，这个函数我们并不难理解,无非是提取所有 property 的子元素，然后调用 parsePropertyElement() 处理，parsePropertyElement() 代码如下：

public void parsePropertyElement(Element ele, BeanDefinition bd) {
    // 获取配置元素中 name 的值
    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 {
        // 不允许多次以同一属性配置
        if (bd.getPropertyValues().contains(propertyName)) {
            error("Multiple 'property' definitions for property '" + propertyName + "'", ele);
            return;
        }
        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();
    }
}

可以看到上面函数与构造函数注入方式不同的是将返回值使用 PropertyValue 进行行封装，并记录在了 BeanDefinition 中的 propertyValues 属性中。

8. 解析子元素 qualifier

对于 qualifier 元素的获取，我们接触更多的是注解的形式，在使用 Spring 框架中进行自动注人时，Spring 容器中匹配的候选 Bean 数目必须有且仅有一个。当找不到一个匹配的 Bean 时，Spring 容器将抛出 BeanCreationException 异常，并指出必须至少拥有一个匹配的 Bean。

Spring 允许我们通过 Qualifier 指定注入 Bean 的名称，这样歧义就消除了，而对于配置方式使用如：

<bean id="myTestBean" class="spring.MyTestBean">
    <qualifier type="org.springframework.beans.factory.annotation.Qualifier"
        value="test"/>
</bean>

其解析过程与之前大同小异，这里不再重复叙述。

3.1.2 AbstractBeanDefiniton 属性

至此我们便完成了对 XML文档到 GenericBeanDefinition 的转换，也就是说到这里，XML 中所有的配置都可以在 GenericBeanDefinition 的实例类中找到对应的配置。GenericBeanDefinition 只是子类实现，而大部分的通用属性都保存在了 AbstractBeanDefiniton 中，那么我们再次通过 AbstractBeanDefiniton 的属性来回顾一下我们都解析了哪些对应的配置。

public abstract class AbstractBeanDefinition extends BeanMetadataAttributeAccessor
        implements BeanDefinition, Cloneable {

    /**
     * 自动装配常亮
     */
    private int autowireMode = AUTOWIRE_NO;
    public static final int AUTOWIRE_NO = AutowireCapableBeanFactory.AUTOWIRE_NO;
    public static final int AUTOWIRE_BY_NAME = AutowireCapableBeanFactory.AUTOWIRE_BY_NAME;
    public static final int AUTOWIRE_BY_TYPE = AutowireCapableBeanFactory.AUTOWIRE_BY_TYPE;
    public static final int AUTOWIRE_CONSTRUCTOR = AutowireCapableBeanFactory.AUTOWIRE_CONSTRUCTOR;
    public static final int AUTOWIRE_AUTODETECT = AutowireCapableBeanFactory.AUTOWIRE_AUTODETECT;

    /**
     * 依赖检查常亮
     */
    private int dependencyCheck = DEPENDENCY_CHECK_NONE;
    public static final int DEPENDENCY_CHECK_NONE = 0;
    public static final int DEPENDENCY_CHECK_OBJECTS = 1;
    public static final int DEPENDENCY_CHECK_SIMPLE = 2;
    public static final int DEPENDENCY_CHECK_ALL = 3;

    /**
     * 基础配置变量
     */
    // Bean对应的实现类
    private volatile Object beanClass;

    // bean 的作用域，对应 bean 属性 scope
    private String scope = SCOPE_DEFAULT;

    // 是否为抽象，对应 bean 属性 abstract
    private boolean abstractFlag = false;

    // 是否延迟初始化，对应 bean 属性 lazy-init
    private boolean lazyInit = false;

    // 自动注入模式，对应 bean 属性 autowire
    private int autowireMode = AUTOWIRE_NO;

    // 依赖检查，Spring 3.0 后弃用这个属性
    private int dependencyCheck = DEPENDENCY_CHECK_NONE;

    // 用来表示一个 bean 的实例化依靠另一个 bean 先实例化，对应 bean 属性 depend-on
    private String[] dependsOn;

    // autowire-candidate 属性设置为 false，这样容器在查找自动装配对象时，
    // 将不考虑该 bean，即它不会被考虑作为其它 bean 自动装配的修行者，但是该 bean
    // 本身还是可以使用自动装配来注入其他 bean 的。
    private boolean autowireCandidate = true;

    // 自动装配时当出现多个 bean 候选者时，将作为首先者，对应 bean 属性 primary
    private boolean primary = false;

    // 用于记录 Qualifier，对应 bean 属性 qualifier
    private final Map<String, AutowireCandidateQualifier> Qualifier，对应 =
            new LinkedHashMap<String, AutowireCandidateQualifier>(0);

    // 允许访问非公开的构造器和方法，程序设置
    private boolean nonPublicAccessAllowed = true;

    private boolean lenientConstructorResolution = true;

    // 记录构造器注入属性，对应 bean 属性 constructor-arg
    private ConstructorArgumentValues constructorArgumentValues;

    // 普通属性集合
    private MutablePropertyValues propertyValues;

    // 方法重写持有者，记录 lookup-method、replaced-method元素
    private MethodOverrides methodOverrides = new MethodOverrides();

    // 对应 bean 属性 factory-bean
    // <bean id="test" factory-bean="factory" factory-method="init"/>
    private String factoryBeanName;

    // 对应 bean 属性 factory-method
    private String factoryMethodName;

    // 初始化方法，对应 bean 属性 init-method
    private String initMethodName;

    // 销毁方法，对应 bean 属性 destory-method
    private String destroyMethodName;

    // 是否执行 init-method，程序设置
    private boolean enforceInitMethod = true;

    // 是否执行 destory-method，程序设置
    private boolean enforceDestroyMethod = true;

    // 是否是用户定义的而还是应用程序本身定义的，创建 AOP 时候为 true，程序设置
    private boolean synthetic = false;

    /**
     * 定义这个 bean 的应用，程序设置：
     *  1. APPLICATION(用户)
     *  2. INFRASTRUCTURE(完全内部使用，与用户无关)
     *  3. SUPPORT(某些复杂配置的一部分)
     */
    private int role = BeanDefinition.ROLE_APPLICATION;

    // bean 的描述信息
    private String description;
}

3.1.3 解析默认标签中的自定义标签元素

到这里我们已经完成了分析默认标签的解析与提取过程，或许涉及的内容太多，我们已经忘了我们从哪个函数开始的了，我们再次回顾下默认标签解析函数的起始函数：

protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
    //1. 委托给 delegate 解析 class、name、id、 alias 之类的属性
    BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
    if (bdHolder != null) {
        //2. 继续解析自定义属性
        bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
        try {
            //3. 对解析后的的 bdholder 进行注册
            BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
        }
        catch (BeanDefinitionStoreException ex) {
            getReaderContext().error("Failed to register bean definition with name '" +
                    bdHolder.getBeanName() + "'", ele, ex);
        }
        //4. 通知相关的监听器，这个 bean 已经加载完成了
        getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
    }
}

我们已经用了大量的篇幅分析了 BeanDefinitionHolder bdholder= delegate.parseBeanDefinitionElement(ele)这句代码，接接下来，我们要进行 bdholder= delegate.decorateBeanDefinitionIfRequired(ele, bdholder) 代码的分析，首先大致了解下这句代码的作用，其实我们可以从语义上分析：如果需要的话就对 beanDefinition 进行装饰，那这句代码到底是什么功能呢？其实这句代码适用于这样的场景，如：

<bean id="myTestBean" class="spring.MyTestBean">
    <mybean:user uername="a"/>
</bean>

当 Spring 中的 bean 使用的是默认的标签配置，但是其中的子元素却使用了自定义的配置时，这句代码便会起作用了。可能有人会有疑问，之前讲过，对 bean 的解析分为两种类型，一种是默认类型的解析，另一种是自定义类型的解析，这不正是自定义类型的解析吗？为什么会在默认类型解析中单独添加一个方法处理呢？确实，这个问题很让人迷惑，但是，不知道聪明的读者是否有发现，这个自定义类型并不是以 Bean 的形式出现的呢？我们之前讲过的两种类型的不同处理只是针对 Bean 的，这里我们看到，这个自定义类型其实是属性。好了，我们继续分析下这段代码的逻辑。

public BeanDefinitionHolder decorateBeanDefinitionIfRequired(
        Element ele, BeanDefinitionHolder definitionHolder) {
    return decorateBeanDefinitionIfRequired(ele, definitionHolder, null);
}

这里将函数中第三个参数设置为空，那么第三个参数是做什么用的呢？什么情况下不为空呢？其实这第三个参数是父类 bean，当对某个嵌套配置进行分析时，这里需要传递父类 beanDefinition。分析源码得知这里传递的参数其实是为了使用父类的 scope 属性，以备子类若没有设置 scope 时默认使用父类的属性，这里分析的是顶层配置，所以传递 null 将第三个参数设置为空后进一步跟踪函数：

public BeanDefinitionHolder decorateBeanDefinitionIfRequired(
            Element ele, BeanDefinitionHolder definitionHolder, BeanDefinition containingBd) {

    BeanDefinitionHolder finalDefinition = definitionHolder;

    NamedNodeMap attributes = ele.getAttributes();
    // 遍历所有的属性，看看是否有适用于修饰的属性
    for (int i = 0; i < attributes.getLength(); i++) {
        Node node = attributes.item(i);
        finalDefinition = decorateIfRequired(node, finalDefinition, containingBd);
    }

    NodeList children = ele.getChildNodes();
    // 遍历所有的子节点，看看是否有适用于修饰的子元素
    for (int i = 0; i < children.getLength(); i++) {
        Node node = children.item(i);
        if (node.getNodeType() == Node.ELEMENT_NODE) {
            finalDefinition = decorateIfRequired(node, finalDefinition, containingBd);
        }
    }
    return finalDefinition;
}

上面的代码，我们看到函数分别对元素的所有属性以及子节点进行了 decorateIfRequired() 函数的调用，我们继续跟踪代码：

public BeanDefinitionHolder decorateIfRequired(
        Node node, BeanDefinitionHolder originalDef, BeanDefinition containingBd) {

    // 获取自定义标签的命名空间
    String namespaceUri = getNamespaceURI(node);
    // 获取非默认标签的修饰
    if (!isDefaultNamespace(namespaceUri)) {
        // 获取命名空间找到的对应处理器
        NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri);
        if (handler != null) {
            // 进行修饰
            return handler.decorate(node, originalDef, new ParserContext(this.readerContext, this, containingBd));
        }
        else if (namespaceUri != null && namespaceUri.startsWith("http://www.springframework.org/")) {
            error("Unable to locate Spring NamespaceHandler for XML schema namespace [" + namespaceUri + "]", node);
        }
        else {
            // A custom namespace, not to be handled by Spring - maybe "xml:...".
            if (logger.isDebugEnabled()) {
                logger.debug("No Spring NamespaceHandler found for XML schema namespace [" + namespaceUri + "]");
            }
        }
    }
    return originalDef;
}

程序走到这里，条理其实已经非常清楚了，首先获取属性或者元素的命名空间，以此来判断该元素或者属性是否适用于自定义标签的解析条件，找出自定义类型所对应的 NamespaceHandler 并进行进一步解析。在自定义标签解析的章节我们会重点讲解，这里暂时先略过。

我们总结下 decorate.decorateBeanDefinitionIfRequired() 方法的作用，在 decorate.decorateBeanDefinitionIfRequired() 中，我们可以看到对于程序默认的标签的处理其实是直接略过的，因为默认的标签到这里已经被处理完了，这里只对自定义的标签或者说对 bean 的自定义属性感兴趣。在方法中实现了寻找自定义标签并根据自定义标签寻找命名空间处理器，并进行进一步的解析。

3.1.4 注册解析的 BeanDefinition

对于配置文件，解析也解析完了，装饰也装饰完了，对于得到的 beanDefinition 已经可以满足后续的使用要求了，唯一还剩下的工作就是注册了，也就是 processBeanDefinition() 函数中的 BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry()) 代码的解析了。

public static void registerBeanDefinition(
        BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry)
        throws BeanDefinitionStoreException {

    // 使用 beanName 做唯一标识注册
    String beanName = definitionHolder.getBeanName();
    registry.registerBeanDefinition(beanName, definitionHolder.getBeanDefinition());

    // 注册所有的别名
    String[] aliases = definitionHolder.getAliases();
    if (aliases != null) {
        for (String alias : aliases) {
            registry.registerAlias(beanName, alias);
        }
    }
}

从上面的代码可以看出，解析的 beanDefinition 都会被注册到 BeanDefinitionRegistry 类型的实例 registry 中，而对于 beanDefinition 的注册分成了两部分：通过 beanName 的注册以及通过别名的注册。

1.通过 beanName 注册 BeanDefinition

对于 beanDefinition 的注册，或许很多人认为的方式就是将 beanDefinition 直接放入 map 中就好了，使用 beanName 作为 key。确实，Spring 就是这么做的，只不过除此之外，它还做了点别的事情。

org.springframework.beans.factory.support.DefaultListableBeanFactory

public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
        throws BeanDefinitionStoreException {

    Assert.hasText(beanName, "Bean name must not be empty");
    Assert.notNull(beanDefinition, "BeanDefinition must not be null");

    if (beanDefinition instanceof AbstractBeanDefinition) {
        try {
            /**
             * 注册前后最后一次校验，这里的校验不同于之前的 XML 文件校验
             * 主要是对于 AbstractBeanDefiniton 属性中的 methodOverrides 校验
             * 校验 methodOverrides 是否与工厂方法并存或者 methodOverrides 对应的方法根本不存在
             */
            ((AbstractBeanDefinition) beanDefinition).validate();
        }
        catch (BeanDefinitionValidationException ex) {
            throw new BeanDefinitionStoreException(beanDefinition.getResourceDescription(), beanName,
                    "Validation of bean definition failed", ex);
        }
    }

    // 因为 beanDefinitionMap 是全局变量，这里定会存在并发访问的情况
    BeanDefinition oldBeanDefinition;

    oldBeanDefinition = this.beanDefinitionMap.get(beanName);
    // 处理注册已经注册的 beanName 情况
    if (oldBeanDefinition != null) {
        // 如果对应的 beanName 已经注册且在配置中配置了 bean 不允许覆盖，则抛出异常
        if (!isAllowBeanDefinitionOverriding()) {
            throw new BeanDefinitionStoreException(beanDefinition.getResourceDescription(), beanName,
                    "Cannot register bean definition [" + beanDefinition + "] for bean '" + beanName +
                    "': There is already [" + oldBeanDefinition + "] bound.");
        }
        else if (oldBeanDefinition.getRole() < beanDefinition.getRole()) {
            // e.g. was ROLE_APPLICATION, now overriding with ROLE_SUPPORT or ROLE_INFRASTRUCTURE
            if (this.logger.isWarnEnabled()) {
                this.logger.warn("Overriding user-defined bean definition for bean '" + beanName +
                        "' with a framework-generated bean definition: replacing [" +
                        oldBeanDefinition + "] with [" + beanDefinition + "]");
            }
        }
        else if (!beanDefinition.equals(oldBeanDefinition)) {
            if (this.logger.isInfoEnabled()) {
                this.logger.info("Overriding bean definition for bean '" + beanName +
                        "' with a different definition: replacing [" + oldBeanDefinition +
                        "] with [" + beanDefinition + "]");
            }
        }
        else {
            if (this.logger.isDebugEnabled()) {
                this.logger.debug("Overriding bean definition for bean '" + beanName +
                        "' with an equivalent definition: replacing [" + oldBeanDefinition +
                        "] with [" + beanDefinition + "]");
            }
        }
        this.beanDefinitionMap.put(beanName, beanDefinition);
    }
    else {
        if (hasBeanCreationStarted()) {
            // 程序已经启动，不能再修改集合元素(用于稳定迭代)
            synchronized (this.beanDefinitionMap) {
                this.beanDefinitionMap.put(beanName, beanDefinition);
                List<String> updatedDefinitions = new ArrayList<String>(this.beanDefinitionNames.size() + 1);
                updatedDefinitions.addAll(this.beanDefinitionNames);
                updatedDefinitions.add(beanName);
                this.beanDefinitionNames = updatedDefinitions;
                if (this.manualSingletonNames.contains(beanName)) {
                    Set<String> updatedSingletons = new LinkedHashSet<String>(this.manualSingletonNames);
                    updatedSingletons.remove(beanName);
                    this.manualSingletonNames = updatedSingletons;
                }
            }
        }
        else {
            // 仍处于启动注册阶段
            // 注册 beanDefinition，并记录 beanName
            this.beanDefinitionMap.put(beanName, beanDefinition);
            this.beanDefinitionNames.add(beanName);
            this.manualSingletonNames.remove(beanName);
        }
        this.frozenBeanDefinitionNames = null;
    }

    if (oldBeanDefinition != null || containsSingleton(beanName)) {
        // 重置所有 beanName 对应的缓存
        resetBeanDefinition(beanName);
    }
}

上面的代码中我们看到，在对于 bean 的注册处理方式上，主要进行了几个步骤。

(1) 对 AbstractDefinition 的校验。在解析 XML 文件的时候我们提过校验，但是此校验非彼校验，之前的校验时针对于 XML 格式的校验，而此日时的校验时针是对于 AbstractBeanDefinition 的的 methodoverrides 属性的。

(2) 对 beanName 已经注册的情况的处理。如果设置了不允许 bean 的覆盖，则需要抛出异常，否则直接覆盖。

(3) 加入 map 缓存。

(4) 清除解析之前留下的对应 beanName 的缓存。

2.通过别名注册 BeanDefinition

在理解了注册 bean 的原理后，理解注册别名的原理就容易多了。

public void registerAlias(String name, String alias) {
    Assert.hasText(name, "'name' must not be empty");
    Assert.hasText(alias, "'alias' must not be empty");
    // 如果 beanName 与 alias 相同的话不记录 alias，并删除对应的 alias
    if (alias.equals(name)) {
        this.aliasMap.remove(alias);
    }
    else {
        String registeredName = this.aliasMap.get(alias);
        if (registeredName != null) {
            // 已经注册别名
            if (registeredName.equals(name)) {
                return;
            }
            // 如果 alias 不允许被覆盖则抛出异常
            if (!allowAliasOverriding()) {
                throw new IllegalStateException("Cannot register alias '" + alias + "' for name '" +
                        name + "': It is already registered for name '" + registeredName + "'.");
            }
        }
        // 当 A->B 存在时，若再次出现 A->C->B 时则会抛出异常
        checkForAliasCircle(name, alias);
        this.aliasMap.put(alias, name);
    }
}

由以上代码中可以得知注册 alias 的步骤如下：

(1) alias 与 beanName 相同情况处理。若 alias与 beanName 并名称相同则不需要处理并删除掉原有 alias

(2) alias 覆盖处理。若 aliasName 已经使用并已经指向了另一 beanName 则需要用户的设置进行处理。

(3) alias循环检查。当 A->B 存在时，若再次出现 A->C->B 时候则会抛出异常。

(4) 注册 alias

3.1.5 通知监听器解析及注册完成

通过代码 getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder)) 完成此工作，这里的实现只为扩展，当程序开发人员需要对注册 BeanDefinition 事件进行监听时可以通过注册监听器的方式并将处理逻辑写入监听器中，目前在 Spring 中并没有对此事件做任何逻辑处理。

3.2 alias 标签的解析

通过上面较长的篇幅我们终于分析完了默认标签中对 bean 标签的处理，那么我们之前提到过，对配置文件的解析包括对 import标签、 alias标签、bean标签、 beans标签的处理，现在我们已经完成了最重要也是最核心的功能，其他的解析步骤也都是围绕第3个解析而进行的。在分析了第3个解析步骤后，再回过头来看看对 alias 标签的解析。

在对 bean 进行定义时，除了使用 id 属性来指定名称之外，为了提供多个名称，可以使用 alias 标签来指定。而所有的这些名称都指向同一个 bean，在某些情况下提供别名非常有用，比如为了让应用的每一个组件能更容易地对公共组件进行引用。

然而，在定义 bean 时就指定所有的别名并不是总是恰当的。有时我们期望能在当前位置为那些在别处定义的 bean 引入别名。在 XML 配置文件中，可用单独的 元素来完成 bean 别名的定义。如配置文件中定义了一个 JavaBean：

<bean id="testBean" class="test.TestBean"/>

要给这个 JavaBean 增加别名，以方便不同对象来调用。我们就可以直接使用 bean 标签中的 name 属性：

<bean id="testBean" name="testBean,testBean2" class="test.TestBean"/>

同样，Spring 还有另外一种声明别名的方式：

<bean id="testBean" class="test.TestBean"/>
<alias name="testBean" name="testBean2"/>

考虑一个更为具体的例子，组件A在 XML 配置文件中定义了一个名为 componentA 的 Datasource 类型的 bean，但组件B却想在其 XML 文件中以 componentB 命名来引用此 bean 而且在主程序 Myapp 的 XML 配置文件中，希望以 myapp 的名字来引用此 bean。最后容器加载3个 XML 文件来生成最终的 Applicationcontext 在此情形下，可通过在配置文件中添加下列 alias 元素来实现：

<alias name="componentA" name="componentB"/>
<alias name="componentA" name="myapp"/>

这样一来，每个组件及主程序就可通过唯一名字来引用同一个数据源而互不干扰。在之前的章节已经讲过了对于 bean 中 name 元素的解析，那么我们现在再来深入分析下对于 alias 标签的解析过程。

protected void processAliasRegistration(Element ele) {
    // 获取 beanName
    String name = ele.getAttribute(NAME_ATTRIBUTE);
    // 获取 alias
    String alias = ele.getAttribute(ALIAS_ATTRIBUTE);
    boolean valid = true;
    if (!StringUtils.hasText(name)) {
        getReaderContext().error("Name must not be empty", ele);
        valid = false;
    }
    if (!StringUtils.hasText(alias)) {
        getReaderContext().error("Alias must not be empty", ele);
        valid = false;
    }
    if (valid) {
        try {
            // 注册 alias
            getReaderContext().getRegistry().registerAlias(name, alias);
        }
        catch (Exception ex) {
            getReaderContext().error("Failed to register alias '" + alias +
                    "' for bean with name '" + name + "'", ele, ex);
        }
        // 别名注册后通行监听器做相应处理
        getReaderContext().fireAliasRegistered(name, alias, extractSource(ele));
    }
}

可以发现，跟之前讲过的 bean 中的 alias 解析大同小异，都是将别名与 beanName 组成一对注册至 registry 中。这里不再述。

3.3 import 标签的解析

对于 Spring 配置文件的编写，我想，经历过庞大项目的人，都有那种恐惧的心理,太多的配置文件了。不过，分模块是大多数人能想到的方法，但是，怎么分模块，那就仁者见仁，智者见智了。使用 import 是个好办法，例如我们可以构造这样的 Spring 配置文件：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <import resource="classpath:spring-context-mybatis.xml"/>
</beans>

上面的文件中使用 import 的方式导人有模块配置文件，以后若有新模块的加人，那就可以简单修改这个文件了。这样大大简化了配置后期维护的复杂度，并使配置模块化，易于管理。我们来看看 Spring 是如何解析 import 配置文件的呢？

protected void importBeanDefinitionResource(Element ele) {
    //1. 获取 resource 属性
    String location = ele.getAttribute(RESOURCE_ATTRIBUTE);
    // 如果不存在 resource 属性则不做任何处理
    if (!StringUtils.hasText(location)) {
        getReaderContext().error("Resource location must not be empty", ele);
        return;
    }

    //2. 解析系统属性，格式如 "${user.dir}"
    location = getReaderContext().getEnvironment().resolveRequiredPlaceholders(location);

    Set<Resource> actualResources = new LinkedHashSet<Resource>(4);

    //3. 判定 location 是绝对路径还是相对路径
    boolean absoluteLocation = false;
    try {
        absoluteLocation = ResourcePatternUtils.isUrl(location) || ResourceUtils.toURI(location).isAbsolute();
    }
    catch (URISyntaxException ex) {
        // cannot convert to an URI, considering the location relative
        // unless it is the well-known Spring prefix "classpath*:"
    }

    //4. 如果是绝对 URI 则直接根据地址加载对应的配置文件
    if (absoluteLocation) {
        try {
            int importCount = getReaderContext().getReader().loadBeanDefinitions(location, actualResources);
            if (logger.isDebugEnabled()) {
                logger.debug("Imported " + importCount + " bean definitions from URL location [" + location + "]");
            }
        }
        catch (BeanDefinitionStoreException ex) {
            getReaderContext().error(
                    "Failed to import bean definitions from URL location [" + location + "]", ele, ex);
        }
    }
    else {
        //5. 如果是相对路径则根据相对地址计算出绝对地址
        try {
            int importCount;
            Resource relativeResource = getReaderContext().getResource().createRelative(location);
            if (relativeResource.exists()) {
                importCount = getReaderContext().getReader().loadBeanDefinitions(relativeResource);
                actualResources.add(relativeResource);
            }
            else {
                // 如果解析不成功，则使用默认的解析器 ResourcePatternResolver 进行解析
                String baseLocation = getReaderContext().getResource().getURL().toString();
                importCount = getReaderContext().getReader().loadBeanDefinitions(
                        StringUtils.applyRelativePath(baseLocation, location), actualResources);
            }
            if (logger.isDebugEnabled()) {
                logger.debug("Imported " + importCount + " bean definitions from relative location [" + location + "]");
            }
        }
        catch (IOException ex) {
            getReaderContext().error("Failed to resolve current resource location", ele, ex);
        }
        catch (BeanDefinitionStoreException ex) {
            getReaderContext().error("Failed to import bean definitions from relative location [" + location + "]",
                    ele, ex);
        }
    }
    //6. 解析后进行监听器激活处理
    Resource[] actResArray = actualResources.toArray(new Resource[actualResources.size()]);
    getReaderContext().fireImportProcessed(location, actResArray, extractSource(ele));
}

上面的代码不难，相信配合注释会很好理解，我们总结一下大致流程便于读者更好地梳理，在解析 import 标签时， Spring 进行解析的步骤大致如下：

(1) 获取 resource 属性所表示的路径。

(2) 解析路径中的系统属性，格式如 "${user:dir}"

(3) 判定 location 是绝对路径还是相对路径。

(4) 如果是绝对路径则递归调用 bean 的解析过程，进行另一次的解析。

(5) 如果是相对路径则计算出绝对路径并进行解析。

(6) 通知监听器，解析完成。

3.4 beans 标签的解析

对于嵌人式的 beans 标签，相信大家使用过或者至少接触过，非常类似于 import 标签所提供的功能，使用用如下：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <beans>

    </beans>
</beans>

对于嵌入式 beans 标签来讲，并没有太多可讲，与单独的配置文件并没有太大的差别，无非是递归调用 beans 的解析过程，相信读者根据之前讲解过的内容已经有能力理解其中的奥秘了。