I was trying to understand the bean factory post processing logic but it was hard to understand the difference between a BeanFactoryPostProcessor
vs BeanDefinitionRegistryPostProcessor
until I read the PostProcessorRegistrationDelegate
code .
I think the documentation can state more clearly that BeanDefinitionRegistryPostProcessors
are executed as the first step of the post processing logic before any BeanFactoryPostProcessor
is invoked but not the postProcessBeanFactory
methods. Those are invoked based on the order of regular BeanFactoryPostProcessors
I'll check if I can add a PR for this when I'm available if it is OK
https://github.com/spring-projects/spring-framework/blob/409cecfff954770f03a1eff1292cebce0fa416a3/spring-beans/src/main/java/org/springframework/beans/factory/support/BeanDefinitionRegistryPostProcessor.java#L24
Comment From: snicoll
I don't understand the confusion to be honest. A BeanDefinitionRegistryPostProcessor
is a BeanFactoryPostProcessor
so it boils down to whether you need the extra callback. If you don't, then just use the regular interface.
I think the documentation can state more clearly that BeanDefinitionRegistryPostProcessors are executed as the first step of the post processing logic before any BeanFactoryPostProcessor is invoked
Doesn't the first sentence of the class javadoc state that already, with: "Extension to the standard BeanFactoryPostProcessor SPI, allowing for the registration of further bean definitions before regular BeanFactoryPostProcessor detection kicks in.".
but not the postProcessBeanFactory methods.
Yeah that's from the parent class and the regular contract.
I am open to change the Javadoc, but it needs to have merits and the extra explanation shouldn't bring confusion. I think it's all there already so can you clarify what's missing?
Comment From: ckalan
For a BeanFactoryPostProcessor
, it is clear that it processes a bean factory but for BeanDefinitionRegistryPostProcessor
, it wasn't clear when its postProcessBeanFactory
method was called. Now I understand that, that method is from the parent class and the regular contract but it wasn't clear from the docs.
Comment From: snicoll
OK. I don't really understand why you think that the scope of a method would change in an interface that extends an existing contract but I am glad this is all cleared now.