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.