@Autowired List<ToAutoWire> into Configuration that defines @Bean ToAutoWire fails [SPR-12646]

[spring-projects-issues]

Rob Winch opened SPR-12646 and commented

Starting with Spring 4.0.7 (4.0.6 works) the following setup will fail because only the ToAutoWire("a") will be Autowired :

public class ToAutoWire {
    private final String name;

    public ToAutoWire(String name) {
        super();
        this.name = name;
    }
}

@Configuration
public class ConfigA {

    @Bean
    public ToAutoWire a() {
        return new ToAutoWire("a");
    }
}

@Configuration
public class ConfigB {
    List<ToAutoWire> values;

    @Bean
    public ToAutoWire b() {
        return new ToAutoWire("b");
    }

    @Autowired
    public void setValues(List<ToAutoWire> values) {
        this.values = values;
    }
}

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = {ConfigA.class, ConfigB.class})
public class AutowireListTests {
    @Autowired
    ConfigB b;

    @Test
    public void run() {
        assertEquals(2,b.values.size());
    }
}

A few notes:

• Using Spring 4.0.6 and prior appears to work just fine
• If ConfigA is removed from the test, ConfigB will correctly autowire ToAutoWire("b")
• When I was putting this together I got this isolated test case within another project and tried to reproduce it, but it failed. For whatever reason coping the complete project exactly as is and then removing the additional pieces seemed to ensure the issue was fixed in 4.0.6 properly (it was consistently failing otherwise). This leads me to believe this may be some sort of ordering issue.
• You can find a sample of the application at https://github.com/rwinch/spring-framework-issues/tree/SPR-12646/SPR-12646 (Note this is in my @Autowired List<ToAutoWire> into Configuration that defines @Bean ToAutoWire fails [SPR-12646] #17247 branch)
• This seems to be causing SEC-2822

---

Affects: 4.0.7, 4.0.8, 4.0.9, 4.1 GA, 4.1.1, 4.1.2, 4.1.3, 4.1.4

Reference URL: https://github.com/rwinch/spring-framework-issues/tree/SPR-12646

Issue Links:

• Autowire bean in @Configuration class itself [SPR-12127] #16743 Autowire bean in @Configuration class itself
• Spring may invoke @Bean methods too early in case of a circular reference [SPR-12018] #16634 Spring may invoke @Bean methods too early in case of a circular reference
• SEC-2822 IllegalStateException: Cannot apply DaoAuthenticationConfigurer to already built object

[spring-projects-issues]

Juergen Hoeller commented

Rob, I'm afraid this is intentional: There is an inherent lifecycle problem in such a setup, with the b() call having to come in before the configuration class has been fully initialized. Due to the issues pointed out in #16634, we explicitly exclude such beans from injection now.

As a way out, consider declaring the b() method as static, which indicates that no instance of the configuration class is needed at that point. Alternatively, add the b() declared bean manually within your configuration class implementation, if you know that this can be reliably done at that point.

Juergen

[spring-projects-issues]

Rob Winch commented

Juergen Hoeller Thank you for your response and the references to the related issues. I find it very surprising that this is intentional for a few reasons.

• This use to work before
• Removing ConfigA from my example above causes the ToAutoWire("b") to be autowired. Why does ToAutoWire("b") get autowired when it is the only Bean but not when there are multiple?
• If this is not intended to work, I feel like this should result in an error rather than silently be dropped.

Given #1 will not be addressed, "Do you think it makes sense to address #2 and #3?"

[spring-projects-issues]

Juergen Hoeller commented

The reason for #2 is Spring 4.0's fallback matching algorithm: Analogous to fallback matches for generic types vs raw types, instead of failing without a result, we'll do a best-effort pass and rather take an 'imperfect' match over none at all. This wasn't really designed for our present case but also applies to our scenario since we're not explicitly preventing it.

So effectively, matches to other beans override self-references back to factory methods on the declaring bean, with no side effects triggered by attempts to resolve the self-references in such a case (which was the goal of #16634, still very much worth having). Just if it turns out that there are no proper matches to other beans, a self-reference is being considered as a fallback. I'm not a great fan of that end result but that's what it is right now. We could consider disallowing the fallback match altogether.

As for raising an error in such a case, we're not doing that for regular self-references either: The autowire candidate algorithm explicitly skips references back to the declaring bean even if it does match the requested type, silently assuming that such self-references aren't intended. This dates back to Spring 2.5 even, IIRC. Now we're also skipping references back to factory methods on the declaring bean, through the same algorithm, and therefore silently proceed in such a case as well.

All of that said, self-references weren't intended to work in the first place and shouldn't be relied on within our own configuration class arrangements. The simplest way out is to change the affected factory methods to static, explicitly declaring that they don't rely on instance state of the containing bean. However, preferably, a configuration class should just ask for injection of external matches and programmatically add defaults if necessary, or have the default instances declared on a separate configuration class that it imports.

For your SEC-2822 purposes, does any of those alternatives work?

Juergen

[spring-projects-issues]

Rob Winch commented

Juergen Hoeller Thank you again for your follow up.

In general, I find this behavior very unintuitive and think Spring should try to be more consistent or report an error (preferred).

For your SEC-2822 purposes, does any of those alternatives work?

Yes. I was able to use a static method to declare the Bean and everything is working now. Thank you for pointing me in this direction.