# 1.解析BeanDefinition

1

BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);

作用就是将element封装进bdHolder里面.

其源码很长,不贴了,但功能流程还很清晰

1. 处理id,name,aliases. 关键是需要beanName ,

   name分隔开做aliases的list.

   beanName优先用id,没id的话就从aliases里remove(0)出来一个,

   如果有beanName了,校验beanName和aliases唯一性

​ 如果还是没beanName,等会再给它用方法生成个

2. 将element解析,放入GenericBeanDefinition里面
3. 把上一步拿到的bd连带着aliases转String[], beanName一起封装一下成为BeanDefinitionHolder返回;如果上一步返回null,就直接返回null

这里的关键步骤显然是第二步,element转beanDefinition

1

        AbstractBeanDefinition beanDefinition = this.parseBeanDefinitionElement(ele, beanName, containingBean);

这个方法也很长,大概步骤是

1. this.parseState.push(new BeanEntry(beanName)) 开头push,结尾pop,不明白是做什么???
2. 获取下className和parent
3. 拿着className和parent去创建个GenericBeanDefinition bd
4. 拿着bd和element进行一系列的解析步骤,把各种值塞入bd
5. 返回bd
6. this.parseState.pop();

# 解析各种属性

1

this.parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);

这个方法的代码丧心病狂地达到了70行,相比于目前读到的其它源码,确实是最长的一个.

但是里面的内容其实并不复杂,就是一个个地从element拿属性,塞属性进bd, 各种 get & set .感觉确实不太好重构.

解析了很多属性,包括scope,abstract,lazy-init,autowire…

# 解析子元素meta

# 解析子元素lookup-method

解析方法和meta差别很小,这里主要是去了解下lookup-method的功能

1
2
3

<bean class="beanClass">
    <lookup-method name="method" bean="non-singleton-bean"/>
</bean>

method是beanClass中的一个方法，beanClass和method是不是抽象都无所谓，不会影响CGLIB的动态代理，根据项目实际需求去定义。non-singleton-bean指的是lookup-method中bean属性指向的必须是一个非单例模式的bean，当然如果不是也不会报错，只是每次得到的都是相同引用的bean（同一个实例），这样用lookup-method就没有意义了。

参考: Spring - lookup-method方式实现依赖注入

# 解析子元素replaced-method

这个不仅可以动态地替换返回实体bean,而且还能动态地更改原有方法的逻辑!!!

# 解析子元素constructor-arg

这里提取构造参数的一些属性值就相比之前复杂多了.

1. 提取index,type,name,判断是否有index属性值
2. 如果有index:
   1. 构造Entry压入parseState栈
   2. 解析constructor-arg的子元素
   3. 使用ConstructorArgumentValues.ValueHolder类型来封装解析出来的元素
   4. 将index,type,name属性一并封装在ValueHolder中,
   5. 验证index是否用过了,用过则抛错,跳过此条参数
   6. ValueHolder添加至当前BeanDefinition的construArgumentValues的indexedArgurmentValues属性中.
   7. 弹出栈
3. 如果没有index:
   1. 同上压入栈
   2. 解析constructor-arg的子元素
   3. 使用ConstructorArgumentValues.ValueHolder类型来封装解析出来的元素
   4. 将index,type,name属性一并封装在ValueHolder中,并且添加至当前BeanDefinition的construArgumentValues的genericArgurmentValues属性中.
   5. 弹出栈

可以看出,有没有index其实流程没区别,主要在于在bd中保存的位置不同,另外有index的需要验证下index的唯一

# parsePropertyValue

解析constructor-arg的子元素

1

Object value = this.parsePropertyValue(ele, bd, (String)null);

这个方法也很长,里面的关键在于此处解析constructor-arg下面的子元素时,下面三种情况必须且只能占一种

• 有ref属性
• 有value属性
• 有子元素(description和meta除外,这两种不用处理),子元素只能列一个

上面三种情况对应不同的处理方法:

1. ref:

   校验下ref的值不能为空,然后

   1 2 3

   RuntimeBeanReference ref = new RuntimeBeanReference(refName); ref.setSource(this.extractSource(ele)); return ref;

   用RuntimeBeanReference封装下这个要引用的bean的beanName,塞下resource,返回

   查看BeanReference源码时注意到有RuntimeBeanReference和RuntimeBeanNameReference两种实现,貌似区别不大,RuntimeBeanReference多个toParent的boolean属性,此处给的也是false值.

2. value:

   1 2 3

   TypedStringValue valueHolder = new TypedStringValue(ele.getAttribute("value")); valueHolder.setSource(this.extractSource(ele)); return valueHolder;

   用TypedStringValue封装下value的值 返回

   TypedStringValue和BeanReference都是实现BeanMetadataElement的,实现了Object getSource();方法

3. 子元素parsePropertySubElement: 这个又复杂了,判断10+种情况

   • 如果不是默认命名空间,则按其自定义的方式去解析

   • bean元素,按照本文的方式解析,拿到一个BeanDefinitionHolder bdHolder,bdHolder不为空的话,可能还要装饰一下(在这个元素的属性或子元素节点命名空间不为默认情况下, 用自定义方式解析后去装饰),返回最终解析+装饰的结果 bdHolder

   • ref: 主要还是拿要引用的beanName, 取值顺序为其属性 bean–local–parent,和之前的ref一样,用RuntimeBeanReference封装下这个要引用的bean的beanName,塞下resource,返回

   • idref:和ref差不多,取值顺序为bean–local

   • value: 拿文本值,拿type值,没type就用传来的默认typeName,此处为null,然后根据value,typeName和BeanClassLoader来构造一个TypedStringValue,返回

   • null:用null来new一个TypedStringValue,返回

   • array:

     1. 拿value-type和子节点list

     2. 用type和子节点size构建个ManagedArray

        ManagedArray继承ManagedList