Autowire bean in @Configuration class itself [SPR-12127]

[spring-projects-issues]

Janne Valkealahti opened SPR-12127 and commented

While updating SHDP to 4.1.RC2 I noticed some changed behaviour in autowiring. Short story is that I autowired list of beans in @Configuration class and had one default bean("defaultGridProjectionFactory) in a same class. This was done to allow user to replace/add these GridProjectionFactory beans. This worked up to 4.1.RC1/4.0.5 and broke with 4.1.RC2. Below is a diff showing how I fixed it in YarnAppmasterAutoConfiguration.

spring-attic/spring-hadoop@427aaeb#diff-2

I was a bit amazed that having bean defined in a @Configuration class which would be autowired in that same @Configuration actually worked. Anyway, it's all good from our side but just wanted to give heads up if this change wasn't intentional in core. You can zap this jira if it works as planned.

---

Affects: 4.1 RC2

Issue Links:

• 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
• @Autowired List<ToAutoWire> into Configuration that defines @Bean ToAutoWire fails [SPR-12646] #17247 @Autowired List into Configuration that defines @Bean ToAutoWire fails
• Non-stable BeanCurrentlyInCreationException with wrong Java config [SPR-12004] #16620 Non-stable BeanCurrentlyInCreationException with wrong Java config

[spring-projects-issues]

Janne Valkealahti commented

Forget to mention that test which failed is in https://github.com/spring-projects/spring-hadoop/blob/master/spring-yarn/spring-yarn-boot/src/test/java/org/springframework/yarn/boot/YarnAppmasterAutoConfigurationTests.java

@Test
	public void testAddCustomGridProjectionFactory() throws Exception {
  ...
  assertThat(factories.size(), is(2));
}

Above assert failed with size 1. Only 'testGridProjectionFactory' from TestConfig2WithClass was autowired.

[spring-projects-issues]

Juergen Hoeller commented

Returning to this one, there has been a bit of finetuning in the area, in particular with respect to configuration self-references. I'll double-check what happened to this specific case.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

This is a consequence of #16634, and in that sense intended: It was never meant to work that way and could cause quite some hassle in perfectly valid scenarios before, so we stopped supporting it altogether. We never supported autowired self-references for regular components either, so it's also consistent to not support it for factory method indirections.

FWIW, this self-exclusion only applies to non-static @Bean methods which have access to instance state. A simple solution for self-references is to declare those affected @Bean methods as static, or ideally to move them to a different configuration class.

Juergen