Expose registerBean(Class<T>, Supplier<T>) outside of GenericApplicationContext

[snicoll]

Affects: 5.1.5.RELEASE

We're trying to use the register bean facility using a Supplier but the current implementation is tied to GenericApplicationContext. Some of our contexts do not inherit from it which prevents us to reuse the feature.

Is there a plan to make that available higher in the stack? See spring-projects/spring-boot#16011

[jhoeller]

GenericApplicationContext is pretty much as high up as we can put it since it requires the static DefaultListableBeanFactory / BeanDefinitionRegistry arrangement at that level.

Other kinds of application contexts are only really the reloadable ones that create a fresh BeanFactory instance for each refresh, to be populated with bean definitions through load callbacks during the refresh phase. In such a case, you could simply register a GenericBeanDefinition the usual way and set a supplier through setInstanceSupplier on it... registerBean(Class, Supplier) is just a convenience, after all.

[snicoll]

registerBean(Class, Supplier) is just a convenience, after all.

I considered doing that but what about ClassDerivedBeanDefinition then? What about default bean name generation based on the target type? (I remember there was some discussion to potentially change that which would require a copy/paste on our end if that happens).

[jhoeller]

The problem turns out to be much simpler if we reduce it to annotation-config contexts: We override the central registerBean implementation there in AnnotationConfigApplicationContext anyway, delegating it to the AnnotatedBeanDefinitionReader... which is also used by AnnotationConfigWebApplicationContext, so we can easily expose more of its methods there.

FWIW, ClassDerivedBeanDefinition is not in use in such a scenario but rather AnnotatedGenericBeanDefinition. Also, ClassDerivedBeanDefinition doesn't actually add anything for supplier-defined beans; it's only really useful for plain class-derived beans with preferred constructors.

It'd be nice to avoid the complexity of GenericApplicationContext's signatures for the time being, not dealing with BeanDefinitionCustomizer and co. Maybe all it takes is adding a few simple variants to AnnotationConfigRegistry which AnnotationConfigWebApplicationContext implements already.

[jhoeller]

I've added two methods to the AnnotationConfigRegistry interface, implemented by AnnotationConfigApplicationContext as well as AnnotationConfigWebApplicationContext:

• registerBean(Class annotatedClass, Class<? extends Annotation>... qualifiers)
• registerBean(Class annotatedClass, Supplier supplier, Class<? extends Annotation>... qualifiers)

The qualifier approach is our existing AnnotatedBeanDefinitionReader model exposed through AnnotationConfigRegistry: those can be actual autowire qualifiers but also @Primary and @Lazy, providing a simple variant for bean definition customizing without exposing BeanDefinitionCustomizer callbacks (just like on AnnotatedBeanDefinitionReader itself). The customizer callback approach therefore remains exclusive to GenericApplicationContext and co, whereas the AnnotationConfigRegistry interface is nicely aligned with AnnotatedBeanDefinitionReader's design and should be sufficiently expressive for common purposes.

[snicoll]

For the purpose of the tester I am trying to improve, I need to be able to control the bean name so it looks like those two new methods are not providing the extension that I need.

Also, I've noticed a somewhat random order in which registration occurs. If we mix imports and functional bean registration, I can see functional bean registration happens at the end regardless how the context is used. I was wondering if that's a conscious decision.

[bclozel]

I need to setup a new context in spring-projects/spring-boot#16021 for RSocket support.

As far as I understand, this enhancement would help simplify the existing context hierarchy in Spring Boot and avoir creating even more. You'll find some of those in org.springframework.boot.web.reactive.context and org,springframework.boot.web.servlet.context.

[jhoeller]

The additional methods on AnnotationConfigRegistry are reverted now, in favor of a uniform GenericApplicationContext-derived hierarchy in Boot.