Doc: @Bean methods on @Configuration class returned from another @Bean method do not work [SPR-14602]

[spring-projects-issues]

Steven Schlansker opened SPR-14602 and commented

I have an @Configuration class which holds some internal configuration data. It wants to instantiate a collaborating @Configuration class, hand off some data to it, and expects its collaborator to exist. However, it seems that an @Bean method that returns a @Configuration class fails because its BeanDefinition#getBeanClassName is null, so ConfigurationClassUtils#checkConfigurationClassCandidate returns false.

@RunWith(SpringRunner.class)
@ContextConfiguration(classes=BeanDefinitionAutowireTest.Config.class)
public class BeanDefinitionAutowireTest {

    @Configuration
    public static class InnerConfig {
        @Bean
        URI someUri() {
            return URI.create("/");
        }
    }

    @Configuration
    public static class Config {
        @Bean
        public InnerConfig innerConfig() {
            return new InnerConfig();
        }
    }

    @Autowired
    URI someUri;

    @Test
    public void testUri() {
        assertNotNull(someUri);
    }
}

I feel that this should work. If for some reason it can not, it should throw an exception or otherwise fail obviously, rather than silently discarding the definitions you expect.

(Note that this test case is a little simplified, in the real case I pass constructor arguments to InnerConfig, so making things static is not an option)

---

Affects: 4.3.1

Issue Links:

• Allow BeanDefinitionRegistryPostProcessor to register other BeanDefinitionRegistryPostProcessors [SPR-10630] #15258 Allow BeanDefinitionRegistryPostProcessor to register other BeanDefinitionRegistryPostProcessors
• @Configuration imported via ImportBeanDefinitionRegistrar is not processed as configuration [SPR-11430] #16056 @Configuration imported via ImportBeanDefinitionRegistrar is not processed as configuration
• @Configuration imported via @ImportResource is not processed [SPR-11723] #16345 @Configuration imported via @ImportResource is not processed

Referenced from: commits 9b221f5, 6fe7e56

[spring-projects-issues]

Stéphane Nicoll commented

I am confused: why are you creating InnerConfig as both a Configuration and a Bean. Creating InnerConfig as a Bean does not make any sense since you're effectively changing the semantic of the object.

A Configuration object can be injected like any other component in spring land. I've updated your test as follows and it passes.

@RunWith(SpringRunner.class)
@ContextConfiguration(classes=BeanDefinitionAutowireTest.Config.class)
public class BeanDefinitionAutowireTest {

	@Configuration
	public static class InnerConfig {
		@Bean
		URI someUri() {
			return URI.create("/");
		}
	}

	@Configuration
	public static class AnotherConfig {
		private final InnerConfig innerConfig;

		@Autowired
		public AnotherConfig(InnerConfig innerConfig) {
			this.innerConfig = innerConfig;
			System.out.println("URI --> " + innerConfig.someUri());
		}
	}

	@Configuration
	@Import({InnerConfig.class, AnotherConfig.class})
	public static class Config {

	}

	@Autowired
	URI someUri;

	@Test
	public void testUri() {
		assertNotNull(someUri);
	}
}

Regardless of this, the behaviour of the container in such a (wrong) scenario can be improved, what do you think Juergen Hoeller?

[spring-projects-issues]

Steven Schlansker commented

Hi, thanks a lot for looking at this -- the bit that I am missing is, how do I pass constructor arguments to the InnerConfig? If you add it to the @Import you cannot. I am trying to create a parameterized configuration that may be included multiple times with differing specializations. That's how I ended up going down the (apparently unsupported) @Bean path, since then I can construct my instance.

[spring-projects-issues]

Juergen Hoeller commented

We'll have to push this back for consideration in 5.0 M3 since the impact on the underlying infrastructure is non-trivial: For example, we can't dynamically create an enhanced subclass for such a configuration class (since the factory method instantiates it), and we generally have to introspect factory method return signatures to find out whether they're configuration candidates.

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid we can't reliably detect such unsupported @Bean methods on classes returned from another @Bean method since we'd have to load the return type early or even introspect the class once the bean is actually created... for every single @Bean method which almost always returns a regular bean where there is nothing to find anyway. Such a non-trivial type loading and lifecycle impact is not worth it if all we're trying to detect are unsupported scenarios. Also, we're not detecting unsupported annotations in many other cases at runtime either.

Actually supporting such configuration classes returned from factory methods on other configuration classes incurs even more trouble, including the aforementioned lack of runtime enhancement of classes. The configuration class model is really designed for the framework to instantiate such classes, not for the instances to be provided through factory methods.

Tools or IDEs may flag such invalid use of annotations, but from the core framework perspective, I'm turning this into a documentation task.