菜鸟的spring 3.0源码学习之旅（4）

终于接触到spring的核心了，心情有点激动，但是呢，又很纠结，纠结的在于源码的复杂性可能要超出我的预料，而我知识的短板也将更集中的展现出来

不过呢，有一句话叫良药苦口利于病，还有一句话叫难者不会会者不难，这两个对于我来说，都是合适的，因为它对我实实在在有利，所以才有必要去看，因为难所以要下更大的努力去做，对于我来说，这个仿佛就是一个宝库，里面有很多的宝藏等待发掘，而我就是那个盗墓贼（说的似乎不怎么好听呀），当我把这个宝库全部都发掘出来的时候，那么成功离我还会远吗

好了，言归正传

大家先看看XmlBeanFactory的实现源码吧

org.springframework.beans.factory.xml.XmlBeanFactory

public class XmlBeanFactory extends DefaultListableBeanFactory {

       private final XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(this);

       public XmlBeanFactory(Resource resource) throws BeansException {

              this(resource, null);

       }

       public XmlBeanFactory(Resource resource, BeanFactory parentBeanFactory) throws BeansException {

              super(parentBeanFactory);

              this.reader.loadBeanDefinitions(resource);  //加载BeanDefinitions信息

       }

}

这个方法定义的很简单，我想大家仅仅通过这个，是无法了解这么庞大复杂多样的功能难道就仅仅是通过这么简单的语句定义的？要我说，这个类更重要的目的就是“牵一发而动全身”

当实例化这个类以后呢，字段首先进行实例化，然后紧接着调用其构造器，那么我们先看看字段实例化以后都引发了什么样的效果

org.springframework.beans.factory.xml. XmlBeanDefinitionReader  

public XmlBeanDefinitionReader(BeanDefinitionRegistry registry) {

       super(registry);

}

这个是我们实例化以后的这个类的构造器，或许大家要有疑问了，入参应该为XmlBeanFactory或者其子类呀，为何是这个？

我通过查看源码发现，XmlBeanFactory的父类实现了它的接口，所以可以转换成这个类型

言归正传，我们还是先看看它父类的构造器吧

org.springframework.beans.factory.support. AbstractBeanDefinitionReader

protected AbstractBeanDefinitionReader(BeanDefinitionRegistry registry) {

              Assert.notNull(registry, "BeanDefinitionRegistry must not be null");

              this.registry = registry;

 

              // Determine ResourceLoader to use.

              if (this.registry instanceof ResourceLoader) {

                     this.resourceLoader = (ResourceLoader) this.registry;

              }

              else {

                     this.resourceLoader = new PathMatchingResourcePatternResolver();

              }

       }

在这个构造器里，它做了两个方面的事情，第一个就是实例化了BeanDefinitionRegistry（BeanDefinition的注册表）,另一个就是实例化了ResourceLoader(资源加载器),