Spring源码深度解析容器的扩展功能(转载)

经过之前的分析，我们已经了解了Spring是如何解析和加载的bean的。但是在上一篇文章结束的时候说到，一般我们写程序是不会用到BeanFactory来当做Spring的容器的，一般使用的是ApplicationContext作为Spring的容器。这两者之间有什么区别呢？

ApplicationContext和BeanFactory在Spring中都是用于加载bean的，但是ApplicationContext提供了许多扩展功能，换句话说，BeanFactory有的功能ApplicationContext全都有，而Application有的功能，BeanFactory却不一定有，所有在一般情况下我们写程序用到的都是ApplicationContext作为Spring的容器。

那么，ApplicationContext比BeanFactory多出了哪些功能呢？这就是我们下面要关注的问题。

首先，我们首先来看一看这两个不同的类在加载配置文件上的写法的不同：

使用BeanFactory方式加载XML

BeanFactory bf = new XmlBeanFactory(new ClassPathResource("beanFactoryTest.xml"));

使用ApplicationContext方式加载XML

ApplicationContext bf = new ClassPathXmlApplicationContext("beanFactoryTest.xml");

与之前研究BeanFactory一样，我们这次还是从ClassPathXmlApplication作为切入点，开始对整体功能进行分析

package org.springframework.context.support;
 
public class ClassPathXmlApplicationContext extends AbstractXmlApplicationContext {
    public ClassPathXmlApplicationContext(String configLocation) throws BeansException {
        this(new String[] {configLocation}, true, null);
    }
 
    public ClassPathXmlApplicationContext(
            String[] configLocations, boolean refresh, @Nullable ApplicationContext parent)
            throws BeansException {
 
        super(parent);
        setConfigLocations(configLocations);
        if (refresh) {
            refresh();
        }
    }
}

设置路径是必不可少的步骤，ClassPathXmlApplicationContext中可以将配置文件路径以数组的方式传入，ClassPathXmlApplicationContext可以对数组进行解析并进行加载。而对于解析及功能的实现都在refresh()中实现。

设置配置路径

在ClassPathXmlApplicationContext中支持多个配置文件以数组方式同时传入：

    public void setConfigLocations(@Nullable String... locations) {
        if (locations != null) {
            Assert.noNullElements(locations, "Config locations must not be null");
            this.configLocations = new String[locations.length];
            for (int i = 0; i < locations.length; i++) {
                //解析给定路径
                this.configLocations[i] = resolvePath(locations[i]).trim();
            }
        }
        else {
            this.configLocations = null;
        }
    }

此函数主要用于解析给定的路径数组，当然，如果数组中包含特殊符号，如${var}，那么在resolvePath中会搜索匹配的系统变量并替换

扩展功能

设置了路径之后，便可以根据路径做配置文件的解析以及各种功能的实现了。可以说refresh函数中几乎包含了ApplicationContext中提供的全部功能，而且此函数中逻辑非常清楚明了，使我们很容易分析对应的层次及逻辑。

    public void refresh() throws BeansException, IllegalStateException {
        synchronized (this.startupShutdownMonitor) {
            //准备刷新的上下文环境
            prepareRefresh();
 
            //初始化BeanFactory，并进行XML文件读取
            ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
 
            //对BeanFactory进行各种 功能填充
            prepareBeanFactory(beanFactory);
 
            try {
                //子类覆盖方法做额外的处理
                postProcessBeanFactory(beanFactory);
 
                //激活各种BeanFactory处理器
                invokeBeanFactoryPostProcessors(beanFactory);
 
                //注册拦截Bean创建的Bean处理器，这里只是注册，真正的调用是在getBean的时候
                registerBeanPostProcessors(beanFactory);
 
                //为上下文初始化Message源，即不同语言的消息体，国际化处理
                initMessageSource();
 
                //初始化应用消息广播器，并放入"applicationEventMulticaster"bean中
                initApplicationEventMulticaster();
 
                //留给子类来初始化其他的bean
                onRefresh();
 
                //在所有注册的bean中查找Listener bean，注册到消息广播中
                registerListeners();
 
                //初始化剩下的单实例(非惰性的)
                finishBeanFactoryInitialization(beanFactory);
 
                //完成刷新过程，通知生命周期处理器lifecycleProcessor刷新过程，同时发出ContextRefreshEvent通知别人
                finishRefresh();
            }
 
            catch (BeansException ex) {
                if (logger.isWarnEnabled()) {
                    logger.warn("Exception encountered during context initialization - " +
                            "cancelling refresh attempt: " + ex);
                }
 
                // Destroy already created singletons to avoid dangling resources.
                destroyBeans();
 
                // Reset 'active' flag.
                cancelRefresh(ex);
 
                // Propagate exception to caller.
                throw ex;
            }
 
            finally {
                // Reset common introspection caches in Spring's core, since we
                // might not ever need metadata for singleton beans anymore...
                resetCommonCaches();
            }
        }
    }

下面概括一下ClassPathXmlApplicationContext初始化的步骤，并从中解释一下它为我们提供的功能。

（1）初始化前的准备工作，例如对系统属性或者环境变量进行准备及验证：在某种情况下项目的使用需要读取某些系统变量，而这个变量的设置很可能会影响着系统的正确性，那么ClassPathXmlApplicationContext为我们提供的这个准备函数就显得非常必要，它可以在Spring启动的时候提前对必须的变量进行存在性验证。

（2）初始化BeanFactory，并进行XML文件读取：之前提到过ClassPathXmlApplicationContext包含着BeanFactory所提供的一切特征，那么在这一步骤中将会复用BeanFactory中的配置文件读取解析及其他功能，这一步之后，ClassPathXmlApplicationContext实际上就已经包含了BeanFactory所提供的功能，也就是可以进行Bean的提取等基础操作了。

（3）对BeanFatory进行各种功能填充：@Qualifer与@Autowired应该是大家非常熟悉的注解，这两个注解正是在这一步骤中增加的支持

（4）子类覆盖方法做额外的处理：Spring之所以强大，为世人所推崇，除了它功能上为大家提供了便利外，还有一方面就是它的完美架构，开放式的架构让使用它的程序员很容易根据业务需要扩展已经存在的功能。这种开放式的设计在Spring中随处可见，例如在本例中就提供了一个空的函数实现postProcessBeanFactory来方便程序员在业务上做进一步扩展。

（5）激活各种BeanFatory处理器

（6）注册拦截bean创建的bean处理器，这里只是注册，真正的调用是在getBean的时候

（7）为上下文初始化Message源，即对不同语言的消息体进行国际化处理

（8）初始化应用消息广播器，并放入"applicationEventMulticaster"bean中

（9）留给子类来初始化其他的bean

（10）在所有注册的bean中查找listener bean，注册到消息广播器中

（11）初始化剩下的单实例（非惰性的）

（12）完成刷新过程，通知声明周期处理器lifecycleProcessor刷新过程，同时发出ContextRefreshEven通知别人

环境准备

protected void prepareRefresh() {
    this.startupDate = System.currentTimeMillis();
    this.closed.set(false);
    this.active.set(true);

    if (logger.isInfoEnabled()) {
        logger.info("Refreshing " + this);
    }

    //留给子类覆盖
    initPropertySources();

    //验证需要的属性文件是否都已经放入环境中
    getEnvironment().validateRequiredProperties();

    // Allow for the collection of early ApplicationEvents,
    // to be published once the multicaster is available...
    this.earlyApplicationEvents = new LinkedHashSet<>();
}

有人说其实这个函数没什么用，因为最后两句代码才是最为关键的，但是却没有什么逻辑处理，initPropertySources是空的，没有任何逻辑，而getEnvironment().validateRequiredProperties也因为没有需要验证的属性而没有做任何处理。其实这都是因为没有彻底理解才会这么说，这个函数用好了作用还是很大的。那么，该怎么用呢？我们先探索下各个函数的作用。

（1）initPropertySources：正符合Spring的开放式结构设计，给用户最大扩展Spring的能力。用户可以根据自身的需要重写initPropertySources方法，并在方法中进行个性化的属性处理及设置。

（2）validateRequiredProperties：则是对属性进行验证，那么如何验证呢？我们举个融合两句代码的小例子来帮助大家理解。

假如现在有这样一个需求，工程在运行过程中用到的摸个设置（例如VAR）是从系统环境变量中取得的，而如果用户没有在系统环境变量中配置这个参数，那么工程可能不会工作，这一要求可能会有各种各样的解决办法，当然，在Spring中可以这样做，你可以直接修改Spring的源码，例如修改ClassPathXmlApplicationContext。不过最好的办法还是对源码进行扩展，我们可以自定义类：

public class MyClassPathXmlApplicationContext extends ClassPathXmlApplicationContext{
    public MyClassPathXmlApplicationContext(String... configLocation){
        super(configLocation);
    }
 
    protected void initPropertySources(){
        getEnvironment().setRequiredProperties("VAR");
    }
}

我们自定义了继承自ClassPathXmlApplicationContext的MyClassPathXmlApplicationContext，并重写了initPropertySources方法，在方法中添加了我们的个性化需求，那么在验证的时候也就是程序走到getEnvironment().validateRequiredProperties()代码的时候，如果系统并没有检测到对应VAR的环境变量，那么将抛出异常。当然我们还需要在使用的时候替换掉原有的ClassPathXmlApplicationContext：

public static void main(String[] args){
    ApplicationContext bf = new ClassPathXmlApplicationContext("test/customag/test.xml");
    User user = (User)bf.getBean("user");
}

加载BeanFactory

obtainFreshBeanFactory方法从字面理解是获取BeanFactory。之前说过，ApplicationContext是对BeanFactory在功能上的扩展，不但包含了BeanFactory的全部功能更在其基础上添加了大量的扩展应用，那么obtainFreshBeanFactory正是实现BeanFactory的地方，也就是经过这个函数后，ApplicationContext正式拥有了BeanFactory的全部功能。

protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
    refreshBeanFactory();
    ConfigurableListableBeanFactory beanFactory = getBeanFactory();
    if (logger.isDebugEnabled()) {
        logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory);
    }
    return beanFactory;
}

protected final void refreshBeanFactory() throws BeansException {
    if (hasBeanFactory()) {
        destroyBeans();
        closeBeanFactory();
    }
    try {
        //创建DefualtListableBeanFactory
        DefaultListableBeanFactory beanFactory = createBeanFactory();
        //为了序列化指定id，如果需要的话，让这个BeanFactory从id反序列化到BeanFactory对象
        beanFactory.setSerializationId(getId());
        //定制beanFactory相关属性，包括是否允许覆盖同名称的不同定义的对象以及
        //设置@Autowired和@Qualifier注解解析器QualifierAnnotationAutowiredCandidateResolver
        customizeBeanFactory(beanFactory);
        //初始化DocumentReader，并进行XML文件读取及解析
        loadBeanDefinitions(beanFactory);
        synchronized (this.beanFactoryMonitor) {
            this.beanFactory = beanFactory;
        }
    }
    catch (IOException ex) {
        throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex);
    }
}

我们详细分析上面的每个步骤

（1）创建DefaultListableBeanFactory。

在介绍BeanFactory的时候，不知道大家有没有印象，声明方式为：BeanFactory bf = new XmlBeanFactory("test.xml")，其中的XmlBeanFactory继承自DefaultListableBeanFactory,并提供了XmlBeanDefinitionReader类型的reader属性，也就是说DefaultListableBeanFactory是容器的基础。必须首先实例化，那么在这里就是实例化DefaultListableBeanFactory的步骤。

（2）指定序列化ID

（3）定制BeanFactory

（4）加载BeanDefinition

（5）使用全局变量BeanFactory类实例

因为DefaultListableBeanFactory类型的变量beanFactory是函数内的局部变量，所以要使用全局变量来记录结果。

定制BeanFactory

这里已经开始了对BeanFactory功能的扩展，在基本容器的基础上，增加了是否允许覆盖是否允许循环依赖。

    protected void customizeBeanFactory(DefaultListableBeanFactory beanFactory) {
        //如果属性allowBeanDefinitionOverriding不为空，设置给beanFactory对象相应属性，
        //此属性含义：是否允许覆盖同名称的不同定义的对象
        if (this.allowBeanDefinitionOverriding != null) {
            beanFactory.setAllowBeanDefinitionOverriding(this.allowBeanDefinitionOverriding);
        }
        //如果属性allowCircularReferences不为空，设置给beanFactory对象相应属性，
        //此属性含义：是否允许bean之间循环依赖
        if (this.allowCircularReferences != null) {
            beanFactory.setAllowCircularReferences(this.allowCircularReferences);
        }
    }

对于允许覆盖和允许循环依赖的设置这里只是判断了是否为空，如果不为空要进行设置，但是并没有看到在哪里进行设置，究竟这个设置是在哪里进行设置的呢？还是那句话，使用子类覆盖方法，例如：

public class MyClassPathXmlApplicationContext extends ClassPathXmlApplicationContext{
    protected void customizeBeanFactory(DefaultListableBeanFactory beanFactory){
        super.setAllowBeanDefinitionOverriding(false);
        super.setAllowCircularReferences(false);
        super.customizeBeanFactory(this.beanFactory);
    }
}

设置完后相信大家已经对于这两个属性的使用有所了解，或者可以看前面的文章进行了解。

加载BeanDefinition

在第一步中提到了将ClassPathXmlApplicationContext与XmlBeanFactory创建的对比，在实现配置文件的加载功能中除了我们在第一步已经初始化的DefaultListableBeanFactory外，还需要XmlBeanDefinitionReader来读取XML，那么在这个步骤中首先要做的就是初始化XmlBeanDefinitionReader。

    protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
        //为给定的beanFactory创建一个XmlBeanDefinitionReader
        XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
 
        //对beanDefinitionReader进行环境变量的设置
        beanDefinitionReader.setEnvironment(this.getEnvironment());
        beanDefinitionReader.setResourceLoader(this);
        beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
 
        //对BeanDefinitionReader进行设置，可以覆盖
        initBeanDefinitionReader(beanDefinitionReader);
        loadBeanDefinitions(beanDefinitionReader);
    }

在初始化了DefaultListableBeanFactory和XmlBeanDefinitionReader后就可以配置文件的读取了。

    protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
        Resource[] configResources = getConfigResources();
        if (configResources != null) {
            reader.loadBeanDefinitions(configResources);
        }
        String[] configLocations = getConfigLocations();
        if (configLocations != null) {
            reader.loadBeanDefinitions(configLocations);
        }
    }

使用XmlBeanDefinitionReader的loadBeanDefinitions方法进行配置文件的加载机制注册，后面的代码就又回到了前两篇文章中所分析的流程了，所以这里就不再赘述了。同时，经过此步骤之后，XmlBeanDefinitionReader所读取的BeanDefinitionHolder就都注册到了DefaultListableBeanFactory中了，此时的DefaultListableBeanFactory已经包含了所有解析好的配置了。

功能扩展

进入函数prepareBeanFactory之前，Spring已经完成了对配置的解析，而ApplicationContext在功能上的扩展也由此展开

protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {
    //设置beanFactory的classLoader为当前context的classLoader
    beanFactory.setBeanClassLoader(getClassLoader());
    //设置beanFactory的表达式语言处理器，Spring3增加了表达式语言的支持，
    //默认可以使用#{bean.xxx}的形式来调用相关属性值
    beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));
    //为beanFactory增加一个默认的propertyEditor，这个主要是对bean的属性等设置管理的一个工具
    beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));

    //添加BeanPostProcessor
    beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this));
    //设置几个忽略自动装配的接口
    beanFactory.ignoreDependencyInterface(EnvironmentAware.class);
    beanFactory.ignoreDependencyInterface(EmbeddedValueResolverAware.class);
    beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class);
    beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware.class);
    beanFactory.ignoreDependencyInterface(MessageSourceAware.class);
    beanFactory.ignoreDependencyInterface(ApplicationContextAware.class);

    //设置几个自动装配的特殊规则
    beanFactory.registerResolvableDependency(BeanFactory.class, beanFactory);
    beanFactory.registerResolvableDependency(ResourceLoader.class, this);
    beanFactory.registerResolvableDependency(ApplicationEventPublisher.class, this);
    beanFactory.registerResolvableDependency(ApplicationContext.class, this);

    //添加一个ApplicationListenerDetector类型的BeanPostProcessor
    beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(this));

    //增加对AspectJ的支持
    if (beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {
        beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));
        // Set a temporary ClassLoader for type matching.
        beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));
    }

    //添加默认的系统环境bean
    if (!beanFactory.containsLocalBean(ENVIRONMENT_BEAN_NAME)) {
        beanFactory.registerSingleton(ENVIRONMENT_BEAN_NAME, getEnvironment());
    }
    if (!beanFactory.containsLocalBean(SYSTEM_PROPERTIES_BEAN_NAME)) {
        beanFactory.registerSingleton(SYSTEM_PROPERTIES_BEAN_NAME, getEnvironment().getSystemProperties());
    }
    if (!beanFactory.containsLocalBean(SYSTEM_ENVIRONMENT_BEAN_NAME)) {
        beanFactory.registerSingleton(SYSTEM_ENVIRONMENT_BEAN_NAME, getEnvironment().getSystemEnvironment());
    }
}

上面函数中主要进行了几个方面的扩展。

1.增加对SpEL语言的支持

2.增加对属性编辑器的支持

3.增加对一些内置类，比如EnvironmentAware、MessageSourceAware的信息注入。

4.设置了依赖功能可忽略的接口。

5.注册一些固定依赖的属性

6.增加AspectJ的支持

7.将相关环境变量及属性注册以单利模式注册。

下面我们来一一的看一下每个步骤的流程

增加SPEL语言的支持

Spring表达式语言全称为"Spring Expression Language"，缩写为"SpEL"，类似于Struts2x中使用的OGNL表达式语言，能在运行时构建复杂表达式、存取对象图属性、对象方法调用等，并且能与Spring功能完美整合，比如能用来配置bean定义。SpEL是单独模块，只依赖与core模块，不依赖与其他模块，可以单独使用。

SpEL使用#{...}作为定界符，所有在大括号中的字符都将被认为是SpEL，使用格式如下：

相当于：

当然，上面只是列举了其中最简单的使用方式，SpEL功能非常强大，使用好可以大大提高开发效率，这里只是为了帮助我们理解源码，所以不做过多的研究。
在源码中通过代码beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver())注册语言解析器，就可以对SpEL进行解析了，那么在注册解析器后Spring又是在什么时候调用这个解析器进行解析呢？

之前我们说过Spring在bean进行初始化的时候会有属性填充这一步，而在这步中Spring会调用AbstractAutowireCapableBeanFactory类applyPropertyValues函数来完成功能。就在这个函数中，会通过构造BeanDefinitionValueResolver类型实例valueResolver来进行属性值的解析。同时，也是在这个步骤中一般通过AbstractBeanFactory中的evaluateBeanDefinitionString方法去完成SpEL解析。

    protected Object evaluateBeanDefinitionString(@Nullable String value, @Nullable BeanDefinition beanDefinition) {
        if (this.beanExpressionResolver == null) {
            return value;
        }
 
        Scope scope = null;
        if (beanDefinition != null) {
            String scopeName = beanDefinition.getScope();
            if (scopeName != null) {
                scope = getRegisteredScope(scopeName);
            }
        }
        return this.beanExpressionResolver.evaluate(value, new BeanExpressionContext(this, scope));
    }

当调用这个方法时会判断是否存在语言解析器，如果存在则调用语言解析器的方法进行解析，解析的过程是在Spring的expression的包内，这里不做过多解释。我们通过查看对evaluateBeanDefinitionString方法的调用层次可以看出，应用语言解析器的调用主要是在解析依赖注入bean的时候，以及在完成bean的初始化和属性获取后进行属性填充的时候。

增加属性注册编辑器

在Spring依赖注入的时候可以把普通属性注入进来，但是像Date类型就无法被识别，例如：

public class UserManager{
    private Date dataValue;
 
    public Date getDataValue(){
        return dataValue;
    }
 
    public void setDataValue(Date dataValue){
        this.dataValue = dataValue;
    }
 
    public String toString(){
        return "dataValue = " + dataValue;
    }
}

上面代码中，需要对日期型属性进行注入：

    
        2018-06-30
    

测试代码：

@Test 
public void testDate(){
    ApplicationContext ctx = new ClassPathXmlApplicationContext("beans.xml");
    UserManager userManager = (UserManager)ctx.getBean("userManager");
    System.out.println(userManager);
}

如果直接这样使用，程序则会报异常，类型转换不成功。因为在UserManager中的dataValue属性是Date类型的，而在XML中配置的则是String类型的，所以会报异常。

Spring针对这个问题提供了两种解决方法：

1.使用自定义属性编辑器

使用自定义属性编辑器，通过继承PropertyEditorSupport，重写setAsText方法，具体步骤如下：

（1）编写自定义的属性编辑器：

public class DatePropertyEditor extends PropertyEditorSupport{
    private String format = "yyyy-MM-dd";
    public void setFormat(String format){
        this.format = format;
    }

    public void setAsText(String arg0) throws IllegalArgumentException{
        System.out.println("arg0: " + arg0);
        SimpleDateFormat sdf = new SimpleDateFormat(format);
        try{
            Date d = sdf.parse(arg0);
            this.setValue(d);
        }catch(ParseException e){
            e.printStackTrace();
        }
    }
}

（2）将自定义属性编辑器注册到Spring中：

在配置文件中引入类型为org.Springframework.beans.factory.config.CustomEditorConfigurer的bean，并在属性customEditors中加入自定义的属性编辑器，其中key为属性编辑器所对应的类型。通过这样的配置，当Spring注入bean的属性时一旦遇到了java.util.Date类型的属性会自动调用自定义的DatePropertyEditor解析器进行解析，并用解析结果代替配置属性进行注入。

2.注册Spring自带的属性编辑器CustomDateEditor

通过注册Spring自带的属性编辑器CustomDateEditor，具体步骤如下：

（1）定义属性编辑器

public class DatePropertyEditorRegistrar implements PropertyEditorRegistrar{
   public void registerCustomEditors(PropertyEditorRegistry registry){
       registry.registerCustomEditors(Date.class, new CustomDateEditor(
           new SimpleDateFormat("yyyy-MM-dd"), true)
       );
   }
}

（2）注册到Spring中

通过在配置文件中将自定义的DatePropertyEditorRegistrar注册进入org.Springframework.beans.factory.config. CustomEditorConfigurer的propertyEditorRegistrars属性中，可以具有与方法1同样的效果。

我们了解了自定义属性编辑器的使用，但是，这似乎与本篇文章中围绕的核心代码beanFactory.addPropertyEditorRegistrar( newResourceEditorRegistrar(this, getEnvironment()))并无联系，因为在注册自定义属性编辑器的时候使用的是PropertyEditor Registry的registerCustomEditor方法，我们不妨深入探索一下ResourceEditorRegistrar的内部实现，在ResourceEditorRegistrar中，我们最关心的方法是registerCustomEditors。

   public void registerCustomEditors(PropertyEditorRegistry registry) {
       ResourceEditor baseEditor = new ResourceEditor(this.resourceLoader, this.propertyResolver);
       doRegisterEditor(registry, Resource.class, baseEditor);
       doRegisterEditor(registry, ContextResource.class, baseEditor);
       doRegisterEditor(registry, InputStream.class, new InputStreamEditor(baseEditor));
       doRegisterEditor(registry, InputSource.class, new InputSourceEditor(baseEditor));
       doRegisterEditor(registry, File.class, new FileEditor(baseEditor));
       doRegisterEditor(registry, Path.class, new PathEditor(baseEditor));
       doRegisterEditor(registry, Reader.class, new ReaderEditor(baseEditor));
       doRegisterEditor(registry, URL.class, new URLEditor(baseEditor));

       ClassLoader classLoader = this.resourceLoader.getClassLoader();
       doRegisterEditor(registry, URI.class, new URIEditor(classLoader));
       doRegisterEditor(registry, Class.class, new ClassEditor(classLoader));
       doRegisterEditor(registry, Class[].class, new ClassArrayEditor(classLoader));

       if (this.resourceLoader instanceof ResourcePatternResolver) {
           doRegisterEditor(registry, Resource[].class,
                   new ResourceArrayPropertyEditor((ResourcePatternResolver) this.resourceLoader, this.propertyResolver));
       }
   }

   private void doRegisterEditor(PropertyEditorRegistry registry, Class requiredType, PropertyEditor editor) {
       if (registry instanceof PropertyEditorRegistrySupport) {
           ((PropertyEditorRegistrySupport) registry).overrideDefaultEditor(requiredType, editor);
       }
       else {
           registry.registerCustomEditor(requiredType, editor);
       }
   }

在doRegisterEditor函数中，可以看到在之前提到的自定义属性中使用的关键代码：registry.registerCustomEditor(requiredType, editor)，回过头来看ResourceEditorRegistrar类的registerCustomEditors方法的核心功能，其实无非是注册了一系列的常用类型的属性编辑器，例如，代码doRegisterEditor(registry, Class.class, new ClassEditor(classLoader))实现的功能就是注册Class类对应的属性编辑器。那么注册后，一旦某个实体bean中存在一些Class类型的属性，那么Spring会调用ClassEditor将配置中定义的String类型转换为Class类型并进行赋值。

分析到这里，我们不禁有个疑问，虽说ResourceEditorRegistrar类的registerCustomEditors方法实现了批量注册的功能，但是bean Factroy.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()))仅仅是注册了ResourceEditor Registrar实例，却并没有调用ResourceEditorRegistrar的registerCustomEditors方法进行注册，那么到底是什么时候进行注册的呢，进一步查看ResourceEditorRegistrar的registerCustomEditors方法的调用层次结构，如图：

image.png

发现在AbstractBeanFactory中的registerCustomEditors方法中被调用过，继续查看AbstractBeanFactory中的register CustomEditors方法的调用层次结构，如图：

image.png

其中我们看到了一个熟悉的方法，就是initBeanWrapper方法，这是在bean初始化时使用的一个方法，之前已经使用过大量的篇幅进行讲解，主要是将BeanDefinition转换为BeanWrapper后用于对属性的填充。至此，逻辑已经明了，在bean的初始化后悔调用ResourceEditorRegistrar的registerCustomEditors方法进行批量的通用属性编辑器注册。注册后，在属性填充的环节便可以直接让Spring使用这些编辑器进行属性的解析了。

既然提到了BeanWrapper，这里有必要强调下，Spring用于封装bean的是BeanWrapper类型，而它又间接继承了Property EditorRegistry类型，也就是我们之间反复看到的方法参数PropertyEditorRegistry，其实大部分情况下都是BeanWrapper，对于BeanWrapper在Spring中默认实现是BeanWrapperImpl，而BeanWrapperImpl除了实现BeanWrapper接口外还继承了PropertyEditorRegistrySupport，在PropertyEditorRegistrySupport中有这样一个方法：

    private void createDefaultEditors() {
        this.defaultEditors = new HashMap<>(64);
 
        // Simple editors, without parameterization capabilities.
        // The JDK does not contain a default editor for any of these target types.
        this.defaultEditors.put(Charset.class, new CharsetEditor());
        this.defaultEditors.put(Class.class, new ClassEditor());
        this.defaultEditors.put(Class[].class, new ClassArrayEditor());
        this.defaultEditors.put(Currency.class, new CurrencyEditor());
        this.defaultEditors.put(File.class, new FileEditor());
        this.defaultEditors.put(InputStream.class, new InputStreamEditor());
        this.defaultEditors.put(InputSource.class, new InputSourceEditor());
        this.defaultEditors.put(Locale.class, new LocaleEditor());
        this.defaultEditors.put(Path.class, new PathEditor());
        this.defaultEditors.put(Pattern.class, new PatternEditor());
        this.defaultEditors.put(Properties.class, new PropertiesEditor());
        this.defaultEditors.put(Reader.class, new ReaderEditor());
        this.defaultEditors.put(Resource[].class, new ResourceArrayPropertyEditor());
        this.defaultEditors.put(TimeZone.class, new TimeZoneEditor());
        this.defaultEditors.put(URI.class, new URIEditor());
        this.defaultEditors.put(URL.class, new URLEditor());
        this.defaultEditors.put(UUID.class, new UUIDEditor());
        this.defaultEditors.put(ZoneId.class, new ZoneIdEditor());
 
        // Default instances of collection editors.
        // Can be overridden by registering custom instances of those as custom editors.
        this.defaultEditors.put(Collection.class, new CustomCollectionEditor(Collection.class));
        this.defaultEditors.put(Set.class, new CustomCollectionEditor(Set.class));
        this.defaultEditors.put(SortedSet.class, new CustomCollectionEditor(SortedSet.class));
        this.defaultEditors.put(List.class, new CustomCollectionEditor(List.class));
        this.defaultEditors.put(SortedMap.class, new CustomMapEditor(SortedMap.class));
 
        // Default editors for primitive arrays.
        this.defaultEditors.put(byte[].class, new ByteArrayPropertyEditor());
        this.defaultEditors.put(char[].class, new CharArrayPropertyEditor());
 
        // The JDK does not contain a default editor for char!
        this.defaultEditors.put(char.class, new CharacterEditor(false));
        this.defaultEditors.put(Character.class, new CharacterEditor(true));
 
        // Spring's CustomBooleanEditor accepts more flag values than the JDK's default editor.
        this.defaultEditors.put(boolean.class, new CustomBooleanEditor(false));
        this.defaultEditors.put(Boolean.class, new CustomBooleanEditor(true));
 
        // The JDK does not contain default editors for number wrapper types!
        // Override JDK primitive number editors with our own CustomNumberEditor.
        this.defaultEditors.put(byte.class, new CustomNumberEditor(Byte.class, false));
        this.defaultEditors.put(Byte.class, new CustomNumberEditor(Byte.class, true));
        this.defaultEditors.put(short.class, new CustomNumberEditor(Short.class, false));
        this.defaultEditors.put(Short.class, new CustomNumberEditor(Short.class, true));
        this.defaultEditors.put(int.class, new CustomNumberEditor(Integer.class, false));
        this.defaultEditors.put(Integer.class, new CustomNumberEditor(Integer.class, true));
        this.defaultEditors.put(long.class, new CustomNumberEditor(Long.class, false));
        this.defaultEditors.put(Long.class, new CustomNumberEditor(Long.class, true));
        this.defaultEditors.put(float.class, new CustomNumberEditor(Float.class, false));
        this.defaultEditors.put(Float.class, new CustomNumberEditor(Float.class, true));
        this.defaultEditors.put(double.class, new CustomNumberEditor(Double.class, false));
        this.defaultEditors.put(Double.class, new CustomNumberEditor(Double.class, true));
        this.defaultEditors.put(BigDecimal.class, new CustomNumberEditor(BigDecimal.class, true));
        this.defaultEditors.put(BigInteger.class, new CustomNumberEditor(BigInteger.class, true));
 
        // Only register config value editors if explicitly requested.
        if (this.configValueEditorsActive) {
            StringArrayPropertyEditor sae = new StringArrayPropertyEditor();
            this.defaultEditors.put(String[].class, sae);
            this.defaultEditors.put(short[].class, sae);
            this.defaultEditors.put(int[].class, sae);
            this.defaultEditors.put(long[].class, sae);
        }
    }

具体的调用方法我们就不去深究了，但是至少通过这个方法我们已经知道了在Spring中定义了上面一系列常用的属性编辑器使我们可以方便地进行配置。如果我们定义的bean的某个属性的类型不在上面的常用配置中的话，才需要我们进行个性化属性编辑器的注册。

3.添加ApplicationContextAwareProcessor处理器

了解了属性编辑器的使用后，接下来我们继续回到AbstractApplicationContext的prepareBeanFactory方法的主线来进行函数追踪。对于beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this))其实主要目的就是注册BeanPost Processor，而真正的逻辑还是在ApplicationContextAwareProcessor中。

ApplicationContextAwareProcessor实现了BeanPostProcessor接口，我们回顾一下之前的内容，在bean实例化的时候，也就是Spring激活bean的init-method的前后，会调用BeanPostProcessor的postProcessorBeforeInitialization方法和postProcessorAfterInitialization方法，同样，对于ApplicationContextAwareProcessor我们也关心这两个方法。

对于postProcessAfterInitialization方法，在ApplicationContextAwareProcessor中并没有做过多逻辑处理

    public Object postProcessAfterInitialization(Object bean, String beanName) {
        return bean;
    }

那么我们重点看一下postProcessBeforeInitialization方法

    public Object postProcessBeforeInitialization(final Object bean, String beanName) throws BeansException {
        AccessControlContext acc = null;
 
        if (System.getSecurityManager() != null &&
                (bean instanceof EnvironmentAware || bean instanceof EmbeddedValueResolverAware ||
                        bean instanceof ResourceLoaderAware || bean instanceof ApplicationEventPublisherAware ||
                        bean instanceof MessageSourceAware || bean instanceof ApplicationContextAware)) {
            acc = this.applicationContext.getBeanFactory().getAccessControlContext();
        }
 
        if (acc != null) {
            AccessController.doPrivileged((PrivilegedAction