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

[spring-projects-issues]

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:

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

4 votes, 8 watchers

[spring-projects-issues]

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

[spring-projects-issues]

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

[spring-projects-issues]

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