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

Cannot use @Primary to override @ComponentScan-ed beans [SPR-10795] #15421

Closed
spring-projects-issues opened this issue Jul 30, 2013 · 3 comments
Closed

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Jul 30, 2013

Mike opened SPR-10795 and commented

A @Primary @Bean cannot override a @ComponentScan-ed @Component.

For example, if I have:

@Primary
@Bean
public Foo getFoo() {...}

and a scanned:

@Component
public class Foo {...}

... the @Component will always be @Autowired instead of the @Primary-annotated @Bean. Nothing in the documentation says that @Primary @Bean's should fail against @ComponentScan-ed ones.


Affects: 3.2.3

Reference URL: http://stackoverflow.com/questions/17945290/spring-primary-fails-against-componentscan

Issue Links:

  • #14201 Beans defined by @ComponentScan are skipped in @Configuration override
  • #14316 ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForModelMethod should take into account the allowBeanDefinitionOverride settings

4 votes, 8 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 1, 2013

Biju Kunjummen commented

@Mike, The behavior is actually expected - both the @Component annotated class and @Bean method create a bean definition with the exact same name "foo" and one ends up(here the one annotated with @Component) overriding the other and hence the behavior.

You will see the right behavior if one of the beans has a different name. eg.

@Primary
@Bean
public Foo foo1()

OR

@Component("foo2");
public class Foo {...}

I have added this answer in stackoverflow question also - http://stackoverflow.com/questions/17945290/spring-primary-fails-against-componentscan

Loading

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Feb 25, 2014

Steve Ash commented

I don't think this is the users' expected behavior at all. If i were to do this with explicit @Bean definitions instead of component scanning it would work fine. Because I switch to component scannig... all of a sudden this breaks. This is broken.
Related to #14316

Loading

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 13, 2015

Juergen Hoeller commented

I'm mark this as "Works as Designed" since bean definition overriding has nothing to do with @Primary. If a bean is being overridden by name, any qualification marker such as @Primary won't have the intended effect. The clue is the "by name" part: Differently named @Bean methods or specifically named @Component classes will make it work.

That said, we are about to revise the general overriding rule for component scanned classes versus @Bean methods in #14201, which is essentially the appropriate solution for this scenario as well.

Juergen

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants