Regression: @Primary annotation not working when overriding bean definition with classpath scanning [SPR-12934]

[spring-projects-issues]

Daniel Hiller opened SPR-12934 and commented

The \@Primary annotation seemed to stop working as expected since Spring 4.1.0.RELEASE (including 4.1.6.RELEASE) as demonstrated in this stripped down github repo.

In the repository mentioned we created a stripped down version of our situation to demonstrate the problem. To get a quick start please have a look at the Application classes.

Run

mvn clean install && cd overridden-bean && mvn exec:java

for a demonstration. An execption should state that another bean type was expected.

NB: This looks like a regression as this is still working with latest Spring 4.0.9.RELEASE. Change the spring version in parent pom to 4.0.9.RELEASE, run the above command and see that it works as expected.

Versions used:

• Apache Maven 3.2.3
• Java 1.8.0_45
• Ubuntu 14.04 LTS

Interestingly, when trying to convert this into spring unit tests (see branch convert-to-unit-tests) and then running the tests from either Intellij vs. maven I get a non deterministic behavior (i.e. running from Intellij fails the test, while mvn clean install does not fail the tests)

---

Affects: 4.1 GA, 4.1.6

Issue Links:

• Reconsider whether to generally allow bean overriding by name [SPR-10808] #15434 Reconsider whether to generally allow bean overriding by name
• context register @Configuration doesn't respect @Order [SPR-12657] #17257 context register @Configuration doesn't respect @Order

[spring-projects-issues]

Juergen Hoeller commented

This looks like you're relying on the order of classpath detection which is highly fragile, in particular for overriding beans by name....

You need to make sure that your overriding @Configuration class is being processed after your original configuration class: either through registering them specifically (i.e. listing the configuration class names in individual XML <bean> definitions or registering them in the right order against an ApplicationConfigApplicationContext) or through specifying @Order values on the configuration classes themselves (e.g. @Order(0) on the original and @Order(1) on the overriding class; available as of 4.2).

Note that @Primary itself does not affect bean definition overriding at all. It just serves as a hint for injection by type when multiple beans of the same type have been registered, not when beans override each other. Try dropping the specific 'myBean' name from those definitions (so that they'll be registered next to each other with their method names as bean names) and you'll see that getBean(MyBean.class) still works. However, for direct references by name, that arrangement might not be what you want.

Let's reopen this issue if the above doesn't help.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Note that we have a more general issue (#15434) for a wider revision of overriding behavior. I'll just mark this issue here as 'invalid' for its regression character since such an arrangement wasn't meant to reliably work before.

Juergen