Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-issuemaster opened this issue Jul 5, 2012 · 4 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Jul 5, 2012

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:

Issue Links:

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

9 votes, 17 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 29, 2013

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Nov 28, 2013

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 11, 2014

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 13, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.