Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Beans defined by @ComponentScan are skipped in @Configuration override [SPR-9567] #14201
Use case: I have my container configured via classpath scanning
Due to the order of loading, beans loaded via classpath scan are not overriding properly when using
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.
9 votes, 17 watchers
I would increase the priority. I think the three ways to configure Spring context (xml, autoscan,
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
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