Provide additional conditional registration capabilities in `BeanRegistrar`

[spring-projects-issues]

Dave Syer opened SPR-16959 and commented

There is a gap in the the functional bean registration features in BeanDefinitionBuilder and GenericApplicationContext. Once you register a Supplier you have committed to provide an instance of the class you register, whereas in a lot of use cases you don't know whether or not you want to provide it until the bean factory is available (e.g. conditional on another instance of the same class being available). I guess the change needs to be in the BeanDefinitionRegistry interface, for example to support a Predicate<ConditionContext> as well as the Supplier. If the interface doesn't change, I suppose returning null from the Supplier might be an option, but that seems a bit ugly, and might be too late, since the BeanDefinition has already been registered at that point.

---

Issue Links:

• Programmatic bean registration with configuration classes #18353 Programmatic bean registration within configuration classes

[spring-projects-issues]

Andy Wilkinson commented

I've been experimenting a bit with conditions in functional bean registration building on top of Framework. It has become apparent that we really need support at the Framework level so that condition evaluation and bean registration can occur at the right time. As Dave alludes to above, the biggest stumbling block at the moment is with bean-based conditions where we'd need a callback at the point where @Configuration class parsing is performing bean registration. This would, I think, allow a mixture of functional-based and annotation-based conditional registration in the same application context.

As things stand, condition evaluation is tied to the @Configuration programming model. It feels to me like this could be generalised so that @Configuration classes are just one source of conditional beans. Rather than driving the registration from ConfigurationClassPostProcessor it could be driven from something general that calls multiple different types of sources of conditional beans. That might result in a new callback that's specifically intended for functional bean registration, rather than the current approach that typically seems to involve the use of the more general ApplicationContextInitializer which doesn't have a well-defined lifecycle for when it's called.

The thoughts above have come from some experimentation and prototyping for reducing memory usage and startup time of Boot apps. Functional registration appears to be one way of doing that but we're quite a way short of declaring that it's the way to do it. As such, we (the Boot team) don't have a concrete need for this functionality just yet, although I do think that conditional beans becoming a broader concept, rather than being confined to the annotation-based programming model as they are today, would be generally useful beyond what Boot may or may not need.