Description
Sébastien Deleuze opened SPR-15417 and commented
The new functional bean registration mechanism gets the type of the bean to register (via an explicit class parameter in Java or via reified type parameters in Kotlin) but unlike JavaConfig which declare explicitly bean dependencies as input @Bean
method parameters, the functional variant don't know what bean dependency are needed because it is based on opaque applicationContext.getBean()
invocations performed by the Supplier
implementation.
Tracking those applicationContext.getBean()
invocations would allow the functional bean registration mechanism to build the same kind of bean dependency graph than with JavaConfig, allowing to cover the same use cases and improving consistency between both approaches.
Issue Links:
- Programmatic bean registration with configuration classes #18353 Programmatic bean registration within configuration classes ("is depended on by")
- Add a functional way to register a bean [SPR-14832] #19398 Add a functional way to register a bean
- Track bean dependencies for calls between @Bean methods within @Configuration classes [SPR-15069] #19635 Track bean dependencies for calls between
@Bean
methods within@Configuration
classes