SpringIOC源码解析(8)—— 注解配置的资源定位、加载、解析、注册全链路概览

本文阅读 8 分钟
首页 代码,Java 正文

在DefaultListableBeanFactory的registerBeanDefinition方法中的打上断点,Entrance程序入口换成:

AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(Entrance.class);

源码:阅读Spring源码第一步:源码编译与创建调试入口

注解容器启动时会有一些系统自带的BeanDefinition注册到系统中。这次的调用栈比先前xml的调用栈要浅: img

入口是调用了AnnotationConfigApplicationContext的构造函数:

public AnnotationConfigApplicationContext(Class<?>... componentClasses) { 
   // 调用默认无参构造器,主要初始化AnnotatedBeanDefinitionReader以
   // 及路径扫描器ClassPathBeanDefinitionScanner
   this();
   // 把传入的Class进行注册,Class既可以有@Configuration注解,也可以没有@Configuration注解
   // 如何注册委托给了 org.springframework.context.annotation.AnnotatedBeanDefinitionReader.register方法
   // 包装传入的Class 生成 BeanDefinition,注册到BeanDefinitionRegistry
   register(componentClasses);
   refresh();
}

在this()的时候,系统自带的BeanDefinition实例已经开始往DefaultListableBeanFactory中注册了

前面xml方式是在refresh()的时候才会去做注册

进入到this()里:

public AnnotationConfigApplicationContext() { 
   this.reader = new AnnotatedBeanDefinitionReader(this);
   this.scanner = new ClassPathBeanDefinitionScanner(this);
}

  在真正执行的构造函数里,会初始化两个成员变量reader和scanner,reader和前面的 XMLBeanDefinition 一样就是用来解析相应的配置资源,并解析出相应的 BeanDefinition 实例,再最终将这些实例注册到 DefaultListableBeanFactory 的容器里面。构造方法传入的参数this是AnnotationConfigApplicationContext实例本身;scanner就是对package进行扫描的扫描器。

  小括号里的this展开之后会发现有一个内置的beanFactory,这时已经创建出来了,它是DefaultListableBeanFactory实例,前面xml方式中它是在refresh()方法中才创建出来的实例,所以注解的内置容器是先于xml创建出来的,之所以要提前创建出来是因为注解容器启动时会有一些系统自带的BeanDefinition注册到系统中,所以要先创建出来DefaultListableBeanFactory实例以提供对这些系统BeanDefinition的注册。

img

  由于会注册系统BeanDefinition,所以DefaultListableBeanFactory的registerBeanDefinition方法肯定会多次执行,多Resume Problem几次就会发现出现了熟悉的我们自定义的entrance实例了 img

  由于Entrance是被@Configuration标记的,所以在执行

AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(Entrance.class);

时也会被注册到容器里,再进一步会发现是通过register来将其注册到容器里 img register主要就是注册被@Configuration标记的业务类,再往上查看栈:

@Override
public void register(Class<?>... componentClasses) { 
   Assert.notEmpty(componentClasses, "At least one component class must be specified");
   this.reader.register(componentClasses);
}

这里的this.reader指的是AnnotationBeanDefinitionReader,进入这个类的源码会发现,它并不属于BeanDefinitionReader的体系,它是专门负责处理注解相关的BeanDefinition

img

  这样做是为了区分注解和其他配置的不同。它里面也有BeanDefinitionRegistry实例以委托其将AnnotationBeanDefinition实例给注册到容器里。

  继续通过调用栈前进,register方法在判空之后会去遍历被@Configuration标记的类,并一一去做注册处理

public void register(Class<?>... componentClasses) { 
   for (Class<?> componentClass : componentClasses) { 
      registerBean(componentClass);
   }
}

再往前一步就会发现do方法了:

public void registerBean(Class<?> beanClass) { 
   doRegisterBean(beanClass, null, null, null, null);
}

进入到do方法里:   首先就是用AnnotatedGenericBeanDefinition将对应的class对象给包装起来,之后就是处理定义在类上的其他注解,这些注解就和 bean 标签定义的属性一样 img 处理完注解之后:

// 用 BeanDefinitionHolder 包装 BeanDefinition
BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(abd, beanName);
// 此行代码与动态代理和scope注解有关,主要看看是否依照Spring的scope生成动态代理对象
// 但是在本案例中没有做任何操作,只是返回了传入的 definitionHolder
definitionHolder = AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
// 向容器注册扫描到的Bean
BeanDefinitionReaderUtils.registerBeanDefinition(definitionHolder, this.registry);

之后就和xml一样,来到BeanDefinitionReaderUtils里面去调用registerBeanDefinition方法进行注册: img

接下来看一下不是被@Configuration标记的类,比如WelcomeController就是被@Controller修饰的 img 此时的调用栈也更深,说明做了更多的处理: img 这一类的bean是在AnnotationConfigApplicationContext构造方法的refresh()方法调用时才被注册进来: img 和xml一样,调用的是AbstractApplicationContext中的refresh()方法,只不过xml调用的是

ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

这里调用的是

invokeBeanFactoryPostProcessors(beanFactory);

img也就是容器调用其后置处理器时触发对普通的BeanDefinition的注册。

再进一步:

protected void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory) { 
   PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory, getBeanFactoryPostProcessors());

   // Detect a LoadTimeWeaver and prepare for weaving, if found in the meantime
   // (e.g. through an @Bean method registered by ConfigurationClassPostProcessor)
   if (beanFactory.getTempClassLoader() == null && beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) { 
      beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));
      beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));
   }
}

  发现注册源自于PostProcessorRegistrationDelegate调用其静态方法invokeBeanFactoryPostProcessors,同时传入的参数beanFactory是DefaultListableBeanFactory实例,这个实例在上面AnnotationConfigApplicationContext的构造函数中调用this()时就创建了,PostProcessorRegistrationDelegate会对BeanFactoryPostProcessor这些容器级别的后置处理器进行调用。

进一步进入到invokeBeanFactoryPostProcessors方法中,发现该方法非常长,除了处理参数中传入的容器级别的后置处理器列表之外,还会尝试从beanFactory中获取已经注册的后置处理器,然后将他们merge到一起并做统一的处理:

String[] postProcessorNames =
      beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
for (String ppName : postProcessorNames) { 
   if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) { 
      currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
      processedBeans.add(ppName);
   }
}
sortPostProcessors(currentRegistryProcessors, beanFactory);
registryProcessors.addAll(currentRegistryProcessors);

并且容器级别的BeanFactoryPostProcessor分为两类:BeanDefinitionRegistryPostProcessor和BeanFactoryPostProcessor,前者是继承自后者的并且会被优先处理。

  对于同一个类型的BeanDefinitionRegistryPostProcessor,会优先执行实现了PriorityOrdered接口的,将这些实现了该接口的PostProcessor按照优先级依次进行调用;之后再针对实现了Ordered接口的,也是按照Order的优先级进行调用;最后才是去调用没有实现接口的PostProcessor。

  执行BeanDefinitionRegistryPostProcessor时, 会调用

invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);

之后才会调用

invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);

img

根据调用栈,这里主要是调用了: img 再往前深入一层:

private static void invokeBeanDefinitionRegistryPostProcessors(
      Collection<? extends BeanDefinitionRegistryPostProcessor> postProcessors, BeanDefinitionRegistry registry) { 

   for (BeanDefinitionRegistryPostProcessor postProcessor : postProcessors) { 
      postProcessor.postProcessBeanDefinitionRegistry(registry);
   }
}

这里会调用每一个BeanDefinitionRegistryPostProcessor 的 postProcessBeanDefinitionRegistry 方法:

@Override
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) { 
   int registryId = System.identityHashCode(registry);
   if (this.registriesPostProcessed.contains(registryId)) { 
      throw new IllegalStateException(
            "postProcessBeanDefinitionRegistry already called on this post-processor against " + registry);
   }
   if (this.factoriesPostProcessed.contains(registryId)) { 
      throw new IllegalStateException(
            "postProcessBeanFactory already called on this post-processor against " + registry);
   }
   this.registriesPostProcessed.add(registryId);

   processConfigBeanDefinitions(registry);
}

首先为每一个registry对象生成一个id,和内存中的id进行比对,避免同一个后置处理器调用了两次同样的registry实例里面的注册方法。

再往前一层,这里执行到ConfigurationClassPostProcessor的processConfigBeanDefinitions方法: img 方法主要是生成parser类来解析BeanDefinition,并且它解析的是被@Configure标记的entrance类 img

进入到下一个方法里,此时调用的是ConfigurationClassParser的parse方法: img img 解析的正是被@Configure标记的Eentrance类

再往前进几步,会调用到ConfigurationClassParser的doProcessConfigurationClass方法 img 这个方法会轮询AnnotationAttributes实例componentScan,componentScan中存储的正是我们要扫描的package img   这个方法会去解析Entrance的注解标签属性,这里主要就是解析Entrance的@ComponentScan("com.wjw"),然后根据basepackage去扫描package路径里被Controller、Service、Repository、Component等修饰的类,然后解析这些类注解里的属性。

  ClassPathBeanDefinitionScanner的doScan就是去扫描的,将class对象都扫描出来以后就会解析出一个个的BeanDefinition,并最终调用DefaultListableBeanFactory的registerBeanDefinition方法,注册BeanDefinition到容器里。

本文为互联网自动采集或经作者授权后发布,本文观点不代表立场,若侵权下架请联系我们删帖处理!文章出自:https://wangjiawei.blog.csdn.net/article/details/120960438
-- 展开阅读全文 --
安全面试之XSS(跨站脚本攻击)
« 上一篇 07-24

发表评论

成为第一个评论的人

热门文章

标签TAG

最近回复