Beans defined by @ComponentScan are skipped in @Configuration override [SPR-9567]

[spring-projects-issues]

Alexander Glass opened SPR-9567 and commented

Use case: I have my container configured via classpath scanning @ComponentScan. For my test configuration I need the ability to mock specific beans.

Due to the order of loading, beans loaded via classpath scan are not overriding properly when using @Configuration. The following code samples demonstrate the problem. BaseExample.java shows how it is possible to override beans via configuration. ScanExample.java shows that overriding a bean that was loaded via @ComponentScan is skipped.

From the logs:

21:21 DEBUG | o.s.c.a.ConfigurationClassBeanDefinitionReader | Skipping loading bean definition for [BeanMethod:name=accountDao,declaringClass=com.glassworks.demo.ScanExample$OverrideConfig]: a definition for bean 'accountDao' already exists. This is likely due to an override in XML.

The attached zipfile contains a maven project with sample code to illustrate.

---

Affects: 3.1.1

Reference URL: http://forum.springsource.org/showthread.php?128123-Overriding-Bean-Configuration-with-annotations

Attachments:

• spring-override-bug.zip (6.12 kB)

Issue Links:

• ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForModelMethod should take into account the allowBeanDefinitionOverride settings [SPR-9682] #14316 ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForModelMethod should take into account the allowBeanDefinitionOverride settings
• Cannot use @Primary to override @ComponentScan-ed beans [SPR-10795] #15421 Cannot use @Primary to override @ComponentScan-ed beans
• Beans defined by XML are skipped in @Configuration override [SPR-15805] #20360 Beans defined by XML are skipped in @Configuration override
• @Configuration imported via @ImportResource is not processed [SPR-11723] #16345 @Configuration imported via @ImportResource is not processed

9 votes, 17 watchers

[spring-projects-issues]

Lukasz commented

I would increase the priority. I think the three ways to configure Spring context (xml, autoscan, @Configuration) doesn't work seamlessly with each other. Btw. is there anywhere a clear description about how they actually should work together?

[spring-projects-issues]

Pedro Vilaça commented

I would like to use this approach to override some beans if a jar is present in the classpath. This way it'll be possible to create pluggable modules without any change in xml files (I'm taking about pluggable features just using the component-scan for the base package of the application). As a workaround, I implemented a configuration class annotated with @ImportResource, declaring a xml file with the override.

[spring-projects-issues]

Tadaya Tsuyukubo commented

Faced same issue and took same workaround that @Pedro Vilaça mentioned:

@Configuration
@ImportResource("classpath:override-context.xml")
public class ConfigOverrideByXml {
}

[spring-projects-issues]

Juergen Hoeller commented

This has finally been addressed now, with 4.2 not considering an existing scanned bean definition as an override anymore, as you would conceptually expect. The risk for regressions should be limited since such overridden @Bean methods were effectively dead code before, which is hardly intentional.

Juergen