Spring proporciona una serie de puntos de extensión, este artículo registra principalmente cómo BeanDefinitionRegistryPostProcessor puede extenderse para implementar su propia lógica;
¿Qué puede hacer este punto de extensión?
Antes de extender, primero debemos entender para qué es esta clase.
public interface BeanDefinitionRegistryPostProcessor extends BeanFactoryPostProcessor {
/**
* Modify the application context's internal bean definition registry after its
* standard initialization. All regular bean definitions will have been loaded,
* but no beans will have been instantiated yet. This allows for adding further
* bean definitions before the next post-processing phase kicks in.
* @param registry the bean definition registry used by the application context
* @throws org.springframework.beans.BeansException in case of errors
*/
void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException;
}
@FunctionalInterface
public interface BeanFactoryPostProcessor {
/**
* Modify the application context's internal bean factory after its standard
* initialization. All bean definitions will have been loaded, but no beans
* will have been instantiated yet. This allows for overriding or adding
* properties even to eager-initializing beans.
* @param beanFactory the bean factory used by the application context
* @throws org.springframework.beans.BeansException in case of errors
*/
void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;
}
En el método proporcionado, puede ver que el parámetro de entrada es un objeto BeanDefinitionRegistry. ¿Qué hace este objeto? Cuando Spring agrega beanDefinition a beanDefinitionMap, llama al método registerBeanDefinition de la clase de implementación BeanDefinitionRegistry. Por lo tanto, si abrimos esta interfaz para ver, básicamente operamos en beanDefinition, como agregar un beanDefinition a beanDefinitionMap; O eliminar un beanDefinition; o modificar el propiedades de un beanDefinition en beanDefinitionMap, etc.
Entonces, podemos saber que en esta clase extendida, el beanDefinition en el beanDefinitionMap se puede modificar, se puede inyectar un beanDefinition, se puede eliminar un beanDefinition, etc.
El método de inyección de la clase de extensión.
Este punto de extensión de BeanDefinitionRegistryPostProcessor es sin duda el más avanzado en todo el proceso de inicio de primavera. Básicamente, en algunos marcos subyacentes, a excepción del escaneo de clases a través de la interfaz de extensión, no he visto otros puntos de extensión. Creo que la razón es: este punto de extensión es demasiado alta, la clase de implementación de esta interfaz, podemos hacer nuestra propia lógica de negocios antes de los escaneos de primavera @ComponentScan, o podemos hacer nuestra propia lógica de negocios después de los escaneos de primavera
La primera clase de implementación
@Component
public class MyBeanFactoryPostProcessor implements BeanDefinitionRegistryPostProcessor {
@Override
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry beanDefinitionRegistry) throws BeansException {
System.out.println("测试自己的beanDefinitionRegistry，通过@Component注解注入");
String[] beanDefinitionNames = beanDefinitionRegistry.getBeanDefinitionNames();
for (String name : beanDefinitionNames) {
System.out.println("Component注解注入方式，打印此时的beanDefinition有：" + name);
}
GenericBeanDefinition beanDefinition = (GenericBeanDefinition) beanDefinitionRegistry.getBeanDefinition("testUpdateAutowireMode");
beanDefinition.setAutowireMode(2);
}
@Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory configurableListableBeanFactory) throws BeansException {
System.out.println("测试自己的beanFactory");
}
}
La segunda clase de implementación
public class MyBeanFactoryPostProcessor01 implements BeanDefinitionRegistryPostProcessor {
@Override
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry beanDefinitionRegistry) throws BeansException {
String[] beanDefinitionNames = beanDefinitionRegistry.getBeanDefinitionNames();
for (String name : beanDefinitionNames) {
System.out.println("通过addBeanFactoryPostProcessor注入，打印此时的beanDefinition有：" + name);
}
System.out.println("测试自己的beanDefinitionRegistry01，通过addBeanFactoryPostProcessor注入");
}
@Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory configurableListableBeanFactory)
throws BeansException {
System.out.println("测试自己的beanFactory01");
}
}
configuración clase de configuración
@Configuration
@ComponentScan("com.spring.study.beandefinitionregistrypostprocessor")
@Import(MyImportBeanDefinitionRegistrar.class)
public class BeanFactoryConfig {
}
Comenzar la clase
public class TestBDRPP {
public static void main(String[] args) {
AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext();
ac.register(BeanFactoryConfig.class);
ac.addBeanFactoryPostProcessor(new MyBeanFactoryPostProcessor01());
ac.refresh();
}
}
El código anterior, lo escribí yo mismo como demostración; puede ver, escribí dos clases de implementación, respectivamente,
una a través de la anotación @Component, por lo tanto, cuando escanee, escanee para generar la clase de implementación,
dos Se inyecta a través de AnnotationConfigApplicationContext.addBeanFactoryPostProcessor ()
El momento de ejecución de estos dos métodos de inyección es completamente diferente
Para el segundo método de inyección, se ejecutará primero. Antes de que Spring comience a escanear el paquete correspondiente a @ComponentScan, se ejecutará primero.
Para el primer método de inyección, se basa en el escaneo de Spring de @ComponentScan, por lo que es después de esto. ejecutado
Se puede ver en el resultado de la impresión:
通过addBeanFactoryPostProcessor注入，打印此时的beanDefinition有：org.springframework.context.annotation.internalConfigurationAnnotationProcessor
通过addBeanFactoryPostProcessor注入，打印此时的beanDefinition有：org.springframework.context.annotation.internalAutowiredAnnotationProcessor
通过addBeanFactoryPostProcessor注入，打印此时的beanDefinition有：org.springframework.context.annotation.internalCommonAnnotationProcessor
通过addBeanFactoryPostProcessor注入，打印此时的beanDefinition有：org.springframework.context.event.internalEventListenerProcessor
通过addBeanFactoryPostProcessor注入，打印此时的beanDefinition有：org.springframework.context.event.internalEventListenerFactory
通过addBeanFactoryPostProcessor注入，打印此时的beanDefinition有：beanFactoryConfig
测试自己的beanDefinitionRegistry01，通过addBeanFactoryPostProcessor注入
09:16:15.632 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'org.springframework.context.annotation.internalConfigurationAnnotationProcessor'
09:16:15.724 [main] DEBUG org.springframework.context.annotation.ClassPathBeanDefinitionScanner - Identified candidate component class: file [D:\mpy\devWorkspace\spring-studycode\target\classes\com\spring\study\beandefinitionregistrypostprocessor\MyBeanFactoryPostProcessor.class]
09:16:15.724 [main] DEBUG org.springframework.context.annotation.ClassPathBeanDefinitionScanner - Identified candidate component class: file [D:\mpy\devWorkspace\spring-studycode\target\classes\com\spring\study\beandefinitionregistrypostprocessor\TestUpdateAutowireMode.class]
importbeanDefinitionRegistrar执行
09:16:15.755 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'myBeanFactoryPostProcessor'
测试自己的beanDefinitionRegistry，通过@Component注解注入
Component注解注入方式，打印此时的beanDefinition有：org.springframework.context.annotation.internalConfigurationAnnotationProcessor
Component注解注入方式，打印此时的beanDefinition有：org.springframework.context.annotation.internalAutowiredAnnotationProcessor
Component注解注入方式，打印此时的beanDefinition有：org.springframework.context.annotation.internalCommonAnnotationProcessor
Component注解注入方式，打印此时的beanDefinition有：org.springframework.context.event.internalEventListenerProcessor
Component注解注入方式，打印此时的beanDefinition有：org.springframework.context.event.internalEventListenerFactory
Component注解注入方式，打印此时的beanDefinition有：beanFactoryConfig
Component注解注入方式，打印此时的beanDefinition有：myBeanFactoryPostProcessor
Component注解注入方式，打印此时的beanDefinition有：testUpdateAutowireMode
测试自己的beanFactory01
测试自己的beanFactory
Cuando se ejecuta la clase de implementación inyectada a través de addBeanFactoryPostProcessor (), no hay un bean comercial propio en beanDefinitionMap. Cuando se ejecuta la clase de implementación beanDefinitionRegistryPostProcessor inyectada por @Component, Spring ha completado el escaneo, y en este momento nos tenemos en beanDefinitionMap El frijol de negocios inyectado por mi mismo
Código fuente
A continuación, analicemos por qué el tiempo de ejecución de estos dos métodos de inyección es diferente. Esto está relacionado con el orden de implementación del código fuente de Spring.
org.springframework.context.support.AbstractApplicationContext#refresh
org.springframework.context.support.AbstractApplicationContext#invokeBeanFactoryPostProcessors
El escaneo de beans se realiza con este método, así que comencemos con este código.
AbstractApplicationContext # invokeBeanFactoryPostProcessors
protected void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory) {
/**
* getBeanFactoryPostProcessors 是获取手动给spring的beanFactoryPostProcessor，
* 自定义并不仅仅是程序员自己写的
* 自己写的可以加@Component，也可以不加
* 如果加了注解，getBeanFactoryPostProcessors()这里是获取不到的，加了注解的beanFactoryPostProcessor是spring自己扫描的
*
* 这里为什么得不到@Component注解修饰的BeanFactoryPostProcessor的实现类？因为这个方法是直接获取一个list,这个list是在AnnotationConfigApplicationContext中被定义的,只有在调用ac.addBeanFactoryPostProcessor();的时候，才会给list赋值
*
* 简单而言，这里说的自定义是指：程序员自己的bean，并且没有加@Component注解的类；（手动添加到spring容器中的）如果没有加注解，怎么交给spring呢？
* 在调用annotationConfigApplicationContext的refresh()方法之前 将自定义的beanFactoryPostProcessor添加到容器ac中
*
*
* 总结而言：
* 我们自己实现一个beanFactoryPostProcessor的实现类，交给spring有两种方式
* 1.通过api的方式：ac.addBeanFactoryPostProcessor();
* 但是这种方式，需要在refresh()方法之前执行，否则是没有意义的
* 这种方式注入的实现类如果是BeanDefinitionRegistrarPostProcessor的实现类，是在spring自动扫描之前就执行的，
* 如果是BeanFactoryPostProcessor的实现类，则是在spring自动扫描之后执行的；
* 2.通过添加@Component注解，这种方式是spring在扫描配置类的时候，会对@Component的实现类进行处理
*
* 而这里的getBeanFactoryPostProcessors(); 就是获取通过api的形式注入的beanFactoryPostProcessor实现类
*
*
*/
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()));
}
}
El comentario también lo explica más claramente. En el método, hay un código clave: getBeanFactoryPostProcessors ()
getBeanFactoryPostProcessors
// 在调用ac.addBeanFactoryPostProcessor(new MyBeanFactoryPostProcessor01());的时候，会赋值给这个list集合
@Override
public void addBeanFactoryPostProcessor(BeanFactoryPostProcessor postProcessor) {
Assert.notNull(postProcessor, "BeanFactoryPostProcessor must not be null");
this.beanFactoryPostProcessors.add(postProcessor);
}
/**
* Return the list of BeanFactoryPostProcessors that will get applied
* to the internal BeanFactory. 在初始化流程中，会先调用这个list集合，获取到通过add方法添加的实现类
*/
public List<BeanFactoryPostProcessor> getBeanFactoryPostProcessors() {
return this.beanFactoryPostProcessors;
}
Veamos el proceso de implementación específico
PostProcessorRegistrationDelegate # invokeBeanFactoryPostProcessors ()
Cuando se ejecuta el código fuente, llamará aquí para ejecutar el método de la clase de implementación de acuerdo con la prioridad
/**
* @param beanFactory
* @param beanFactoryPostProcessors
*
* 这里是对beanDefinitionRegistryPostProcessor和beanFactoryPostProcessor实现类的处理
* 1.先执行程序员通过API提供的beanDefinitionRegistryPostProcessor的实现类
* 2.执行spring中，实现了PriorityOrdered接口且实现了beanDefinitionRegistryPostProcessor接口的实现类
* 3.执行spring中，实现了Ordered接口且实现了beanDefinitionRegistryPostProcessor接口的实现类
* 4.执行spring中，只实现了beanDefinitionRegistryPostProcessor接口的实现类
* 5.执行实现了beanFactoryPostProcessor接口的实现类
*/
public static void invokeBeanFactoryPostProcessors(
ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) {
// Invoke BeanDefinitionRegistryPostProcessors first, if any.
//这个set集合可以理解为存储的是已经执行过的beanDefinitionRegistryPostProcessor
Set<String> processedBeans = new HashSet<>();
/**
* 这里之所以要判断beanFactory是哪种类型的，应该和org.springframework.beans.factory.support.BeanDefinitionRegistryPostProcessor#postProcessBeanDefinitionRegistry(org.springframework.beans.factory.support.BeanDefinitionRegistry)
* 的入参有关系
*/
if (beanFactory instanceof BeanDefinitionRegistry) {
BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory;
//regularPostProcessors这个list存储的是beanFactoryPostProcessor接口的实现类
List<BeanFactoryPostProcessor> regularPostProcessors = new ArrayList<>();
//registryProcessors 这个list存储的是beanDefinitionRegistryPostProcessor接口的实现类
List<BeanDefinitionRegistryPostProcessor> registryProcessors = new ArrayList<>();
/**
* 序号1
* 这里的beanFactoryPostProcessors是程序员自己提供的BeanFactoryPostProcessor的实现类
*/
for (BeanFactoryPostProcessor postProcessor : beanFactoryPostProcessors) {
/**
* 区分当前bean是BeanDefinitionRegistryPostProcessor还是 beanFactoryPostProcessor
* 因为前者是后者的子类，所以在获取beanFactoryPostprocessor的时候 也可以获取到
*
* 在本方法中 是先执行实现了BeanDefinitionRegistryPostProcessor的类
* 再执行beanFactoryPostProcessor的类
* 序号1.1
*/
if (postProcessor instanceof BeanDefinitionRegistryPostProcessor) {
// 这里会进行一个强转，因为有可能这里的postProcessor是BeanDefinitionRegistryPostProcessor的子接口的实现类，所以向上转型
BeanDefinitionRegistryPostProcessor registryProcessor =
(BeanDefinitionRegistryPostProcessor) postProcessor;
//这里直接执行程序员通过API注入的beanDefinitionRegistryPostProcessor的实现类
registryProcessor.postProcessBeanDefinitionRegistry(registry);
registryProcessors.add(registryProcessor);
}
else {
// 序号1.2 将beanFactoryPostProcessor添加到regularPostProcessors;执行到这里，说明postProcessor是BeanFactoryPostProcessor的实现类
regularPostProcessors.add(postProcessor);
}
}
// Do not initialize FactoryBeans here: We need to leave all regular beans
// uninitialized to let the bean factory post-processors apply to them!
// Separate between BeanDefinitionRegistryPostProcessors that implement
// PriorityOrdered, Ordered, and the rest.
//这里的这个list是用来存放spring中实现了beanFactoryRegistryPostProcessor接口的实现类
List<BeanDefinitionRegistryPostProcessor> currentRegistryProcessors = new ArrayList<>();
// First, invoke the BeanDefinitionRegistryPostProcessors that implement PriorityOrdered.
/**
* 序号2
*获取到了一个BeanDefinitionRegistryPostProcessor的实现类 -- ConfigurationClassPostprocessor
* 并且这里也只会获取到一个，因为截止到目前，spring容器中还没有我们自己写的业务类，只有spring自己注入的集合bean；
* 而这几个bean中，只有ConfigurationClassPostProcessor是BeanDefinitionRegistryPostProcessor的实现类
*
* 需要注意的是：
* 这个类在spring解析扫描初始化的时候用到了，ConfigurationClassPostProcessor是最重要的一个
*
* 所谓的合并bean，就是判断当前bean是否有父beanDefinition，如果有父beanDefinition,就把父beanDefinition和子beanDefinition合并到一起
* 在这里获取beanDefinitionRegistryPostProcessor类型的bean的时候，会对bean一个合并，也就是所谓的mergeBean
* 在后面finishBeanFactoryInitialization方法中，对bean进行实例化的时候，会再判断一次
*/
String[] postProcessorNames =
beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
/**
* 序号3
* spring内部在执行BeanDefinitionRegistryPostProcessor的实现类的时候，是由顺序的
* 实现了PriorityOrdered接口的类 --> 实现了Ordered接口的类 --> other
*
*/
for (String ppName : postProcessorNames) {
if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
processedBeans.add(ppName);
}
}
//排序，合并spring自己的和程序员自定义的beanFactoryRegistryPostProcessor
sortPostProcessors(currentRegistryProcessors, beanFactory);
registryProcessors.addAll(currentRegistryProcessors);
/**
* 序号3.1
* invokeBeanDefinitionRegistryPostProcessors这行代码，在本方法中调用了三次
* 这里是第一次调用，这是，理论上只有一个，就是ConfigurationClassPostProcessor
*
*/
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
currentRegistryProcessors.clear();
// Next, invoke the BeanDefinitionRegistryPostProcessors that implement Ordered.
postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
for (String ppName : postProcessorNames) {
/**
* 可以看到，在第二次和第三次从容器中获取实现类的时候，会先从已经执行过的集合中进行过滤(processedBeans)过滤
* 下面这个判断的意思是：ppName没有在processedBeans中，也就是没有执行过；且实现了Ordered接口；
*/
if (!processedBeans.contains(ppName) && beanFactory.isTypeMatch(ppName, Ordered.class)) {
currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
processedBeans.add(ppName);
}
}
/**
* 序号3.2
* 这里是第二次调用，执行实现了Ordered接口的类
*/
sortPostProcessors(currentRegistryProcessors, beanFactory);
registryProcessors.addAll(currentRegistryProcessors);
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
currentRegistryProcessors.clear();
// Finally, invoke all other BeanDefinitionRegistryPostProcessors until no further ones appear.
/**
* 序号3.3
* 这里执行的是所有实现了beanDefinitionRegistryPostProcessor且无实现其他接口的类
*
* 这里为什么要用while(true)？
* 因为有可能beanDefinitionRegistryPostProcessor的实现类中有可能会又注入了一个beanDefinitionRegistryPostProcessor的实现类，所以这里要循环查找并执行;
* 如果第二次从beanFactory中没有找到beanDefinitionRegistryPostProcessor的实现类，那么，这里reiterate就是false，就不会再执行了
* 如果第二次从beanFactory中找到了未执行的实现类，那么就会继续执行，同时，reiterate变为true；然后进行下一轮的循环
*/
boolean reiterate = true;
while (reiterate) {
reiterate = false;
postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
for (String ppName : postProcessorNames) {
if (!processedBeans.contains(ppName)) {
currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
processedBeans.add(ppName);
reiterate = true;
}
}
sortPostProcessors(currentRegistryProcessors, beanFactory);
registryProcessors.addAll(currentRegistryProcessors);
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
currentRegistryProcessors.clear();
}
// Now, invoke the postProcessBeanFactory callback of all processors handled so far.
/**
* 序号4
* 前面说了，registryProcessors是保存beanDefinitionRegistryPostProcessor接口的实现类
* regularPostProcessors保存的是程序员提供的beanFactoryPostProcessor接口的实现类，
* 那为什么这里还会有 invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);这行代码？
* 原因很简单，一个接口在实现beanDefinitionRegistryPostProcessor接口的同时，必然会实现beanFactoryPostProcessor接口
* 所以，这里要执行
* registryProcessors中是spring内置的beanFactoryPostProcessor
* regularPostProcessors是程序员提供的beanFactoryPostProcessor
*
* 所以，spring源码中，
* 1.会先执行程序员提供的BeanDefinitionRegistryPostProcessor接口的实现类，
* 2.会执行spring自带的 BeanDefinitionRegistryPostProcessor接口的实现类
* 3.然后执行spring自带的 BeanDefinitionRegistryPostProcessor接口的实现类中的postProcessBeanFactory方法
* 4.最后执行程序员提供的 BeanDefinitionRegistryPostProcessor接口的实现类中的postProcessBeanFactory方法
*/
invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);
invokeBeanFactoryPostProcessors(regularPostProcessors, beanFactory);
}
else {
// Invoke factory processors registered with the context instance.
/**
* 如果beanFactory不是BeanDefinitionRegistry类型，就执行BeanFactoryPostProcessor的实现类
*/
invokeBeanFactoryPostProcessors(beanFactoryPostProcessors, beanFactory);
}
}
He eliminado parte del código de este método. Como puede ver en lo anterior, la Lista beanFactoryPostProcessors ingresada son las clases de implementación que agregamos a través del método add.
1. Como puede ver en el número de serie 1, las clases de implementación agregadas a través de add será primero Realizar recorrido
2. Como se ve aquí en el número de serie 1.1, se llamará y procesará la clase de implementación de BeanDefinitionRegistryPostProcessor. La premisa aquí es agregar a través del método add
Como mínimo, la ejecución del código termina aquí, vemos que el método de la clase de implementación agregado por add se ha ejecutado aquí en el número de serie 1.1.
¿Cuándo se inyecta la clase de implementación a través de la anotación @Component ejecutada?
En el número de serie 3.2 o en el número de serie 3.3, ¿por qué podría estar en dos lugares? Porque depende de si la clase de implementación declarada por nosotros implementa la interfaz Ordered, si está implementada está en 3.2, y si no está implementada está en 3.3.
Premisa mayor
La clase de implementación inyectada a través de la anotación @Component se ejecuta en 3.2 o 3.3. Existe una premisa principal de que este método depende del número de serie 3.1. Aquí, aquí, es la ubicación donde spring resuelve la anotación @ComponentScan, y spring realiza escaneo automático, dependiendo de Is ConfigurationClassPostProcessor
De acuerdo con la relación de herencia e implementación de la interfaz, se puede encontrar que su PriorityOrdered implementa esta interfaz, por lo que se ejecutará en la posición del número de serie 3.1.
Lo anterior es un análisis de cómo se extiende el mecanismo de extensión de BeanDefinitionRegistryPostProcessor y el principio correspondiente.