Allow BeanDefinitionRegistryPostProcessor to register other BeanDefinitionRegistryPostProcessors [SPR-10630]

[spring-projects-issues]

Phil Webb opened SPR-10630 and commented

See #12525, originally marked as WONTFIX but would be very useful for Spring Security

---

Issue Links:

• BeanDefinitionRegistryPostProcessor registered via @Bean will not be invoked [SPR-7868] #12525 BeanDefinitionRegistryPostProcessor registered via @Bean will not be invoked
• Infinite loop caused by import of XML configuration that declares a ConfigurationClassPostProcessor [SPR-11858] #16477 Infinite loop caused by import of XML configuration that declares a ConfigurationClassPostProcessor
• sort BeanDefinitionRegistryPostProcessors added by other BeanDefinitionRegistryPostProcessors [SPR-16043] #20592 sort BeanDefinitionRegistryPostProcessors added by other BeanDefinitionRegistryPostProcessors
• Invalid WARN when returning a BeanDefinitionRegistryPostProcessor from within a @Configuration class [SPR-14603] #19172 Invalid WARN when returning a BeanDefinitionRegistryPostProcessor from within a @Configuration class
• Doc: @Bean methods on @Configuration class returned from another @Bean method do not work [SPR-14602] #19171 Doc: @Bean methods on @Configuration class returned from another @Bean method do not work
• Fix outdated javadoc of ConfigurationClassPostProcessor [SPR-17062] #21600 Fix outdated javadoc of ConfigurationClassPostProcessor
• Improve performance of #getBeanNamesForType() while the BeanFactory configuration is not yet frozen [SPR-13610] #18188 Improve performance of #getBeanNamesForType() while the BeanFactory configuration is not yet frozen

Referenced from: commits bb971ce

[spring-projects-issues]

Phil Webb commented

Juergen Hoeller,

What do you think of this idea and the pull request #299

I am not sure if the #12525 was marked as WONTFIX for a reason. Could this also be backported to 3.2.x?

/cc Chris Beams

[spring-projects-issues]

Rob Winch commented

Juergen Hoeller I'm not sure this is working properly, but please correct me if I am wrong. When using Javaconfig if I register a BeanDefinitionRegistryPostProcessor, the BeanDefinition does not appear to be populated (it exists but doesn't contain the metadata).

The Javadoc on BeanDefinitionRegistryPostProcessor's postProcessBeanDefinitionRegistry method states:

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.

My understanding is that since the beans have been loaded, then all the metadata should be present. Additionally, if I create a BeanDefinitionRegistryPostProcessor via XML the metadata for the BeanDefnition is populated properly.

I have created a small sample project to illustrate the problem at https://github.com/rwinch/spring-security-sample/tree/SPR-10630

[spring-projects-issues]

Juergen Hoeller commented

Rob, I'm afraid there is a misunderstanding here: We aren't ever populating the ConstructorArgumentValues part from @Bean methods. Instead, from the container's perspective, those methods are argument-less factory methods that just potentially happen to see some constructor invocation with arguments in the bytecode within their method body...

So this feature works as designed, even if it isn't metadata-compatible to its XML equivalent. There isn't much we can do about this since this is so inherent to the factory method mechanism.

Juergen