1、现象一：实现了BeanFactoryPostProcessor的类无法解析@Autowired、@PostConstruct，但可以执行InitializingBean接口的实现方法afterPropertiesSet。
@Component
public class TestBeanFactoryPostProcessor implements BeanFactoryPostProcessor, InitializingBean {
//无法注入
@Autowired
BeanPostProcessorService beanPostProcessorService;
//无法执行
@PostConstruct
public void postConstruct(){
log.debug("TestBeanFactoryPostProcessor PostConstruct init");
}
//可以执行
@Override
public void afterPropertiesSet() throws Exception {
log.debug("TestBeanFactoryPostProcessor InitializingBean init");
}
//可以执行
@Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
log.debug("TestBeanFactoryPostProcessor beanPostProcessorService[{}]",beanPostProcessorService);
}
}
2、现象二：两个类都实现了BeanPostProcessor，一个在其中注入一个普通bean，一个在后置处理器中获取该bean并修改其属性值，此时后者的后置方法无法获取到这个bean。（@Autowired、@PostConstruct可以生效，且可以执行InitializingBean接口的实现方法afterPropertiesSet）
普通bean：
@Component("a")
public class BeanPostProcessorService {
String str;
Integer i;
public BeanPostProcessorService(){
log.debug("==BeanPostProcessorService create");
}
public Integer getI() {
return i;
}
public String getStr() {
return str;
}
public void testAop(){
log.debug("--------BeanPostProcessorService logic-----");
}
}第一个实现了BeanPostProcessor的类，注入了这个bean（能够成功注入进来），且 @PostConstruct可以生效,InitializingBean 的after方法也可以生效
@Component
public class TestBeanPostProcessorNormal implements BeanPostProcessor, InitializingBean {
@PostConstruct
public void postConstruct(){
log.debug("TestBeanPostProcessorNormal PostConstruct init");
}
@Autowired
BeanPostProcessorService beanPostProcessorService;
public TestBeanPostProcessorNormal(){
log.debug("==TestBeanPostProcessorNormal create");
}
public void printfInfo(){
log.debug("TestBeanPostProcessorNormal beanPostProcessorService[{}]",beanPostProcessorService);
}
@Override
public void afterPropertiesSet() throws Exception {
log.debug("TestBeanPostProcessorNormal InitializingBean init");
}
}第二个类实现了BeanPostProcessor，并在后置方法中获取该bean，此时后置方法无法执行
@Component
public class TestBeanPostProcessorNormalUpdatePorperties implements BeanPostProcessor {
public TestBeanPostProcessorNormalUpdatePorperties(){
log.debug("==TestBeanPostProcessorNormalUpdatePorperties create");
}
@SneakyThrows
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException{
if(beanName.equals("a")) {
Class<?> aClass = bean.getClass();
Field[] fs = aClass.getDeclaredFields();
for (Field f : fs) {
if(f.getName().equals("str")){
f.setAccessible(true);
f.set(bean,"spring");
}
}
return bean;
}
return null;
}
}此时发现第二个类的后置方法无法执行
3、现象三：在现象二的基础上，将类一的注入注释掉，此时第二个类的后置方法则可以获取到该bean。
@Component
public class TestBeanPostProcessorNormal implements BeanPostProcessor, InitializingBean {
@PostConstruct
public void postConstruct(){
log.debug("TestBeanPostProcessorNormal PostConstruct init");
}
//@Autowired
//BeanPostProcessorService beanPostProcessorService;
public TestBeanPostProcessorNormal(){
log.debug("==TestBeanPostProcessorNormal create");
}
public void printfInfo(){
log.debug("TestBeanPostProcessorNormal beanPostProcessorService[{}]",beanPostProcessorService);
}
@Override
public void afterPropertiesSet() throws Exception {
log.debug("TestBeanPostProcessorNormal InitializingBean init");
}
}4、现象四：一个类实现了BeanPostProcessor和Ordered接口，此时@Autowired、@PostConstruct，InitializingBean都可以生效
但如果实现了BeanPostProcessor和PriorityOrdered，此时@Autowired、@PostConstruct无法生效，InitializingBean可以生效
5、现象5：一个类实现了BeanPostProcessor，或者实现了BeanPostProcessor+Ordered，
此时如果注入了一个bean，该bean是需要进行aop代理，此时会打印一个警告信息-------该bean是一个校验不合格的bean，也就是该bean没有执行完所有的BeanPostProcessor。
（我们知道bena的生命周期初始化前后会执行自己实现的BeanPostProcessor接口的前后置方法，而每个bean的生命周期可以执行多个BeanPostProcessor（spring容器中会有一个List存放所有BeanPostProcessor））
具体看：Bean生命周期和九次调用BeanPostProcessor都做了什么事情_bean的生命周期每个阶段都可以调用beanpostprocessor吗_小小程序猿ccc的博客-CSDN博客
我们自己实现了的BeanPostProcessor只是在bean初始化前后调用，而其他spring中存在的BeanPostProcessor会在不同时期进行调用。
这里的警告就是该bean没有执行完所有的BeanPostProcessor，可能不是一个程序员想要的bean。
6、现象6：在现象5的基础上，实现了BeanPostProcessor+Ordered的类注入一个需要被aop代理的bean，此时不仅会打印警告信息，这个bean的aop还会失效
7、现象7：实现了BeanPostProcessor的类中注入需要aop代理的bean，此时该bean的aop不会失效
8：现象8：实现了BeanPostProcessor+PriorityOrdered的类注入需要aop代理的bean，此时该bean的aop不会失效。
==============================================
一、
registerBeanPostProcessors方法
refresh方法中，我们讲了invokeBeanFactoryPostProcessors方法（具体什么作用看前面的文章），现在我们要解释上面说得的哪些现象，需要看refresh方法里面的registerBeanPostProcessors方法：
顾名思义，这个方法的大概作用是注册BeanPostProcessors。
其实早在invokeBeanFactoryPostProcessors方法之前，
prepareBeanFactory就先添加了一个BeanPostProcessor：
protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {
// Tell the internal bean factory to use the context's class loader etc.
beanFactory.setBeanClassLoader(getClassLoader());
beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));
beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));
//忽略掉部分类的注入
// Configure the bean factory with context callbacks.
//添加一个回调实现了ApplicationContextAwareaware的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);
//省略部分代码。。。。。。。。。。。。
//添加一个处理事件的BeanPostProcessor
beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(this));
}在bean生命周期的某步，就会去调用这个BeanPostProcessor进行回调aware接口：
而spring用一个List来存储这些BeanPostProcessor。（spring自身或第三方的BeanPostProcessor都会放到这个list中）
在执行invokeBeanFactoryPostProcessors方法时，在执行ConfigurationClassPostProcessor的方法postProcessBeanFactory时，也添加了一个：
这个BeanPostProcessor为了在加了@Confuration注解时，cglib会进行代理时使用的（可以去看前面的文章，这个就是给cglib代理时的创建的BeanFactory赋值的）
容器实例化时也会注册一些BeanPostProcessor：
容器构造方法--》AnnotatedBeanDefinitionReader构造方法--》
AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry);
//注册AutowiredAnnotationBeanPostProcessor，用来处理@Autowired注解
if (!registry.containsBeanDefinition(AUTOWIRED_ANNOTATION_PROCESSOR_BEAN_NAME)) {
//将BeanPostProcessor转为BeanDefinition，然后put到BeanDefinitionMap中
RootBeanDefinition def = new RootBeanDefinition(AutowiredAnnotationBeanPostProcessor.class);
def.setSource(source);
beanDefs.add(registerPostProcessor(registry, def, AUTOWIRED_ANNOTATION_PROCESSOR_BEAN_NAME));
}
//注册CommonAnnotationBeanPostProcessor，用来处理@Resource注解+@Postcustrud注解
// Check for JSR-250 support, and if present add the CommonAnnotationBeanPostProcessor.
if (jsr250Present && !registry.containsBeanDefinition(COMMON_ANNOTATION_PROCESSOR_BEAN_NAME)) {
RootBeanDefinition def = new RootBeanDefinition(CommonAnnotationBeanPostProcessor.class);
def.setSource(source);
beanDefs.add(registerPostProcessor(registry, def, COMMON_ANNOTATION_PROCESSOR_BEAN_NAME));
}
//注册了一个用来处理JPA的
// Check for JPA support, and if present add the PersistenceAnnotationBeanPostProcessor.
if (jpaPresent && !registry.containsBeanDefinition(PERSISTENCE_ANNOTATION_PROCESSOR_BEAN_NAME)) {
RootBeanDefinition def = new RootBeanDefinition();
try {
def.setBeanClass(ClassUtils.forName(PERSISTENCE_ANNOTATION_PROCESSOR_CLASS_NAME,
AnnotationConfigUtils.class.getClassLoader()));
}
catch (ClassNotFoundException ex) {
throw new IllegalStateException(
"Cannot load optional framework class: " + PERSISTENCE_ANNOTATION_PROCESSOR_CLASS_NAME, ex);
}
def.setSource(source);
beanDefs.add(registerPostProcessor(registry, def, PERSISTENCE_ANNOTATION_PROCESSOR_BEAN_NAME));
}这里又注册了三个。
我们可以看看这个registerPostProcessor方法怎么注册的：
private static BeanDefinitionHolder registerPostProcessor(
BeanDefinitionRegistry registry, RootBeanDefinition definition, String beanName) {
definition.setRole(BeanDefinition.ROLE_INFRASTRUCTURE);
//注册这个BeanPostProcessor到BeanDefinitionMap中
registry.registerBeanDefinition(beanName, definition);
return new BeanDefinitionHolder(definition, beanName);
}（注意：注册和add不一样，注册是将BeanPostProcessor转化为BeanDefinition然后put到BeanDefinitionMap中，而我们上面讲的add是直接实例化后放进容器的List中）
注意：这个List<BeanPostProcessor> 的BeanPostProcessor对象来源主要有两个：
1）、spring中自己将BeanPostProcessor add进行（就是我们上面说的）
2）、通过getBean方法，将BeanDefinitionMap中的BeanPostProcessor类型的BeanDefinition实例化为Bean放进来（就是讲上面注册的BeanPostProcessor实例化为bean后放进来）
最后bean的生命周期中会去调用这个list中的BeanPostProcessor。
由于我们要演示上面的aop失效问题，所以会使用到@EnableAspectJAutoProxy开启aop
这里也会注册一个BeanPostProcessor
其他我们先不看了，这里的7个有3个进行了add到list中，却没有调用去调registerBeanPostProcessor方法进行注册。
此时的BeanDefinitionMap大概是由这么几个BeanPostProcessor（我们只讨论这7个，其他都不讨论）（由于我们这里没有JPA环境，所以第三个JPA相关的BeanPostProcessor也不存在,所以就只讨论6个）
所以在refresh-》 registerBeanPostProcessors(beanFactory);则是将容器中还没注册的BeanPostProcessor进行注册（即将List中的BeanPostProcessor进行注册）
此时我们开始进入registerBeanPostProcessors方法看是怎么进行注册的，注册流程是怎么样的？
入口：refresh--》registerBeanPostProcessors--》
PostProcessorRegistrationDelegate.registerBeanPostProcessors()
（注意：这个方法是将BeanDefinitionMap中的BeanPostProcessor实例化为bean并放进List<BeanPostProcessor>中去）
public static void registerBeanPostProcessors(
ConfigurableListableBeanFactory beanFactory, AbstractApplicationContext applicationContext) {
//从BeanDefinitionMap中获取所有的BeanPostProcessor
String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanPostProcessor.class, true, false);
// Register BeanPostProcessorChecker that logs an info message when
// a bean is created during BeanPostProcessor instantiation, i.e. when
// a bean is not eligible for getting processed by all BeanPostProcessors.
//beanProcessorTargetCount--->spring期望一个bean要执行几个BeanPostProcessor
//beanFactory.getBeanPostProcessorCount()--->获取容器中List<BeanPostProcessor>的元素个数
//beanProcessorTargetCount = list.size() + 1 + map.size()
int beanProcessorTargetCount = beanFactory.getBeanPostProcessorCount() + 1 + postProcessorNames.length;
//又往list中放进一个BeanPostProcessor（检查list中BeanPostProcessor的个数和预期的是否相等，上面的1就是指这个BeanPostProcessorChecker）
beanFactory.addBeanPostProcessor(new BeanPostProcessorChecker(beanFactory, beanProcessorTargetCount));
//省略部分代码。。。。。
}这里可以看到，又往List中加入一个BeanPostProcessor，这个BeanPostProcessor很重要，可以解释我们，之前的一些现象。
我们进入这个BeanPostProcessorChecker：
public BeanPostProcessorChecker(ConfigurableListableBeanFactory beanFactory, int beanPostProcessorTargetCount) {
this.beanFactory = beanFactory;
this.beanPostProcessorTargetCount = beanPostProcessorTargetCount;
}
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) {
return bean;
}
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) {
//如果预期值和真实在List中的数量不一致则打印这个警告信息
if (!(bean instanceof BeanPostProcessor) && !isInfrastructureBean(beanName) &&
this.beanFactory.getBeanPostProcessorCount() < this.beanPostProcessorTargetCount) {
if (logger.isInfoEnabled()) {
logger.info("Bean '" + beanName + "' of type [" + bean.getClass().getName() +
"] is not eligible for getting processed by all BeanPostProcessors " +
"(for example: not eligible for auto-proxying)");
}
}
return bean;
}可以看到这里在被调用时，会对预期值与真实的List中的进行对比，如果不同则打印警告信息。
我们现在开始解释下现象二：
第一个类中注入了一个普通bean，第二个类则无法调用到后置方法。
我们知道spring扫描的时候会将这两个类先放到BeanDefinitionMap中，所以在执行registerBeanPostProcessors方法时预期值为2+1（我们此时假设只有这两个类+List中的BeanPostProcessorChecker），我们知道refresh---》finishBeanFactoryInitialization中每个bean的生命周期都会去调用所有List中的BeanPostProcessor。
1）、此时第一个类的因为注入了一个普通bean-》BeanPostProcessorService ，bean的生命周期中需要先进行属性注入后才会初始化为bean，这样才能将其放进List<BeanPostProcessor>中，而此时因为注入了一个普通bean，所以需要先让BeanPostProcessorService 走完生命周期。
2）、BeanPostProcessorService 开始走他自己的生命周期，走到finishBeanFactoryInitialization中会去调用所有List中的BeanPostProcessor，此时就会调用到BeanPostProcessorChecker的后置方法，这是就开始检查预期值2+1是不是等于List中的数量，因为此时第一个类还在BeanDefinitionMap中，还卡在属性注入的过程，所以还没实例化成bean放进List中（此时的List中只有BeanPostProcessorChecker），所以导致打印警告信息+后续的BeanPostProcess的后置处方法不会执行。
总结下就是，本来普通bean BeanPostProcessorService的生命周期应该refresh-》finishBeanFactoryInitialization方法中完成的，可是因为被实现了BeanPostProcessor的类依赖（需要注入），导致其生命周期提前需要完成（在没完全完执行registerBeanPostProcessors方法（有些BeanPostProcessor还在Map中，还没被实例化为bean放进list中）就开始执行list中的所有BeanPostProcessor），所以会打印警告+有些BeanPostProcessor的后置方法无法执行
这里有个疑问，这里的第二个类TestBeanPostProcessorNormalUpdatePorperties，为什么不能先于第一个类实例化为bean，先放进list中？这样第一个类卡住的时候，BeanPostProcessorService走生命周期虽然还会打印警告，但不是还可以执行第二个类的后置处理方法？
---------------------------------------
第一现象：实现了BeanFactoryPostProcessor的类无法解析@Autowired、@PostConstruct，但可以执行InitializingBean接口的实现方法afterPropertiesSet。
我们在前面就提及，在执行registerBeanPostProcessors方法前（也是invokeBeanFactoryPostProcessors方法之前），解析@Autowired、@Postconstrct的BeanPostProcessor就已经被放到BeanDefinitionMap中了，但还没有实例化为Bean放进List中。而BeanFactoryPostProcessor被实例化为bean是在invokeBeanFactoryPostProcessors方法中就执行的，此时在走实现了BeanFactoryPostProcessor生命周期的时候，就不会执行到解析@Autowired、@Postconstrct的BeanPostProcessor，所以就导致了无法注入的效果（也就是实例化的时候解析@Autowired、@Postconstrct的BeanPostProcessor还没实例化为bean放进list中）
这里提个问题，为什么上面现象二的第一个类在实例化的时候就具备有了@Autowired的能力？
（因为解析@Autowired的BeanPostProcessor先于我们自定义的BeanPostProcessor被实例化，所以就有了@Autowired的能力）
--------------------------------------------------------
第三现象：即第二种现象不注入普通bean了，此时后置处理方法可以生效了
普通bean-》BeanPostProcessorService不被BeanPostProcessor依赖注入了，此时就会等到所以BeanPostProcessor都实例化完放进list才会进行自己的生命周期，所以就不会部分后置处理器无法执行的情况了。
--------------------------------------------------------------
现象四：一个类实现了BeanPostProcessor和Ordered接口，此时@Autowired、@PostConstruct，InitializingBean都可以生效
---因为解析@Autowired等的BeanPostProcessor先于我们自定义的BeanPostProcessor+实现了Ordered接口被实例化，所以就有了@Autowired等的能力
但如果实现了BeanPostProcessor和PriorityOrdered，此时@Autowired、@PostConstruct无法生效，InitializingBean可以生效
---因为解析@Autowired等的BeanPostProcessor慢于我们自定义的BeanPostProcessor+实现了PriorityOrdered接口被实例化，所以就无法具备@Autowired等的能力
现象四基本就是BeanPostProcessor实例化优先级的问题
-----------------------------------------------------------
现象五：一个类实现了BeanPostProcessor，或者实现了BeanPostProcessor+Ordered，
此时如果注入了一个bean，该bean是需要进行aop代理，此时会打印一个警告信息-------该bean是一个校验不合格的bean，也就是该bean没有执行完所有的BeanPostProcessor。
------aop对应的BeanPostProcessor实例化优先级低于实现了BeanPostProcessor+Ordered，所以就会打印警告
----------------------------------------------------------
6、现象6：实现了BeanPostProcessor+Ordered的类注入一个需要被aop代理的bean，此时不仅会打印警告信息，这个bean的aop还会失效
-----------原因和现象五一样，aop对应的BeanPostProcessor实例化优先级低于实现了BeanPostProcessor+Ordered，所以被注入的bean（进行了aop代理）就会出现在aop对应的beanPostProcessor没实例化时就执行生命周期的回调BeanPostProcessor流程，所以最好导致bean的aop失效的情况
------------------------------
7、现象7：实现了BeanPostProcessor的类中注入需要aop代理的bean，此时该bean的aop不会失效
-----aop对应的BeanPostProcessor实例化优先级快于没有实现Ordered的
-------------------------------
8：现象8：实现了BeanPostProcessor+PriorityOrdered的类注入需要aop代理的bean，此时该bean的aop不会失效。
-----aop对应的BeanPostProcessor实例化优先级快于实现PriorityOrdered的
所以我们可以总结下各个种类的BeanPostProcessor的实例化时机：
spring内置添加的》自定义的BeanPostProcessor+实现了PriorityOrdered接口》解析@Autowired等的BeanPostProcessor》自定义的BeanPostProcessor+实现了Ordered接口》aop对应的BeanPostProcessor》自定义的BeanPostProcessor
（其中解析@Autowired的又优先于解析@Resource、@Postconstrct的）
所以可以知道PriorityOrdered、Ordered可以提升BeanPostProcessor被实例化的优先级。我们从源码也可以看到：
public static void registerBeanPostProcessors(
ConfigurableListableBeanFactory beanFactory, AbstractApplicationContext applicationContext) {
//从BeanDefinitionMap中获取所有的BeanPostProcessor
String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanPostProcessor.class, true, false);
// Register BeanPostProcessorChecker that logs an info message when
// a bean is created during BeanPostProcessor instantiation, i.e. when
// a bean is not eligible for getting processed by all BeanPostProcessors.
//beanProcessorTargetCount--->spring期望一个bean要执行几个BeanPostProcessor
//beanFactory.getBeanPostProcessorCount()--->获取容器中List<BeanPostProcessor>的元素个数
//beanProcessorTargetCount = list.size() + 1 + map.size()
int beanProcessorTargetCount = beanFactory.getBeanPostProcessorCount() + 1 + postProcessorNames.length;
//又往list中放进一个BeanPostProcessor（检查list中BeanPostProcessor的个数和预期的是否相等，上面的1就是指这个BeanPostProcessorChecker）
beanFactory.addBeanPostProcessor(new BeanPostProcessorChecker(beanFactory, beanProcessorTargetCount));
// Separate between BeanPostProcessors that implement PriorityOrdered,
// Ordered, and the rest.
//存放实现了priorityOrdered接口的BeanPostProcessor
List<BeanPostProcessor> priorityOrderedPostProcessors = new ArrayList<>();
//存放了内部的BeanPostProcessor
List<BeanPostProcessor> internalPostProcessors = new ArrayList<>();
//存放实现了Ordered接口的BeanPostProcessor
List<String> orderedPostProcessorNames = new ArrayList<>();
//其他普通的BeanPostProcessor
List<String> nonOrderedPostProcessorNames = new ArrayList<>();
for (String ppName : postProcessorNames) {
if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
//如果实现了priorityOrdered接口，则进行实例化为bean，
// （这里不会调用CheckBeanPostProcessor，因为checkBeanPostProcessor只用于非BeanPostProcessor类型的bean
//然后加入到priorityOrderedPostProcessors集合中
BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
priorityOrderedPostProcessors.add(pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors.add(pp);
}
}
else if (beanFactory.isTypeMatch(ppName, Ordered.class)) {
//如果实现了Ordered接口，先不进行实例化，放进orderedPostProcessorNames集合
orderedPostProcessorNames.add(ppName);
}
else {
//其他的也放进集合
nonOrderedPostProcessorNames.add(ppName);
}
}
// First, register the BeanPostProcessors that implement PriorityOrdered.
//注册实现了PriorityOrdered的BeanPostProcessors到容器的List<BeanPostProcessor>中去
sortPostProcessors(priorityOrderedPostProcessors, beanFactory);
registerBeanPostProcessors(beanFactory, priorityOrderedPostProcessors);
// Next, register the BeanPostProcessors that implement Ordered.
List<BeanPostProcessor> orderedPostProcessors = new ArrayList<>(orderedPostProcessorNames.size());
for (String ppName : orderedPostProcessorNames) {
//实例化实现了Ordered接口BeanPostProcessor
BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
orderedPostProcessors.add(pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors.add(pp);
}
}
//注册实现了Ordered的BeanPostProcessors到容器的List<BeanPostProcessor>中去
sortPostProcessors(orderedPostProcessors, beanFactory);
registerBeanPostProcessors(beanFactory, orderedPostProcessors);
// Now, register all regular BeanPostProcessors.
List<BeanPostProcessor> nonOrderedPostProcessors = new ArrayList<>(nonOrderedPostProcessorNames.size());
for (String ppName : nonOrderedPostProcessorNames) {
//实例化其他普通的BeanPostProcessor
BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
nonOrderedPostProcessors.add(pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors.add(pp);
}
}
registerBeanPostProcessors(beanFactory, nonOrderedPostProcessors);
//注册到List中
// Finally, re-register all internal BeanPostProcessors.
sortPostProcessors(internalPostProcessors, beanFactory);
registerBeanPostProcessors(beanFactory, internalPostProcessors);
// Re-register post-processor for detecting inner beans as ApplicationListeners,
// moving it to the end of the processor chain (for picking up proxies etc).
beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(applicationContext));
}aaa
1445
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
