Allow @Bean to override a dynamically registered bean definition [SPR-10607]

[spring-projects-issues]

Dave Syer opened SPR-10607 and commented

ConfigurationClassBeanDefinitionReader does not allow a @Bean to override anything that is not itself a @Bean:

if (!(existingBeanDef instanceof ConfigurationClassBeanDefinition)) {
// no -> then it's an external override, probably XML
// overriding is legal, return immediately
...

The assumption that non-@Beans come from XML is false, since they can be (and increasingly are) registered by an import selector or similar piece of framework machinery. In any case this seems like an arbitrary rule (XML beans are just as valid to override as any other). All users really need is some predictability about the bean definition load order, so they can reason about what should override what.

---

Affects: 4.0 M1

Issue Links:

• Regression in 4.0.0 - A scoped-proxy bean cannot override another bean [SPR-11229] #15854 Regression in 4.0.0 - A scoped-proxy bean cannot override another bean
• Reconsider whether to generally allow bean overriding by name [SPR-10808] #15434 Reconsider whether to generally allow bean overriding by name

[spring-projects-issues]

Juergen Hoeller commented

Dave, I suppose you're programmatically creating GenericBeanDefinitions or RootBeanDefinitions early, expecting same-named @Bean methods to override them later on? I've adapted ConfigurationClassBeanDefinitionReader to allow an override of BeanDefinitions with a role other than ROLE_APPLICATION, so you may for example set ROLE_SUPPORT on such BeanDefinitions now (simply through a setRole call). However, for an an existing top-level bean definition with our usual ROLE_APPLICATION - indicating a user-defined bean -, it will still expect that one to override. This is about a general assumption that user-defined top-level beans override 'nested' bean definitions such as @Bean methods.

The general problem is the two-pass nature of configuration class processing, with all top-level bean definitions getting registered first and then all @Bean methods getting detected and registered in a second pass. As a consequence, the effective order of bean definition registration is sometimes at odds with the user's intent, e.g. with an XML file containing <bean> elements pointing to a mix of regular beans and configuration classes: Through the effective order of registration with the BeanFactory, no XML bean definition would ever override an @Bean method - no matter when it got registered - unless we had such special checks in ConfigurationClassBeanDefinitionReader.

The same effect shows not only with XML but with programmatic registration as well, e.g. with the user doing registerBeanDefinition calls for a few configuration classes and a few subsequent registerBeanDefinition calls for specific bean overrides: Due to those overriding bean definitions effectively being registered with the BeanFactory already when ConfigurationClassBeanDefinitionReader kicks in, we once again need those special checks to detect whether an @Bean method has been conceptually overridden in such a case.

All in all, I'm afraid that the role stuff is the best we can do at this point. For framework authors, this should hopefully be a good enough solution and actually reflect the different role of such default bean definitions that the framework puts in. For regular users, I'd strongly advise to go with distinct configuration styles anyway and not do overrides between XML and configuration classes in the first place. Within the XML world only and within the configuration class world only, overrides work reasonably well.

Juergen