Improve support for @Configuration class hierarchies [SPR-8187]

[spring-projects-issues]

Chris Beams opened SPR-8187 and commented

Consider the following @Configuration class hierarchy:@Configurationabstract class BaseConfig {
@Bean
Foo foo() {
return new Foo(dataSource());
}

abstract @Bean DataSource dataSource();

}

@Configuration
class ConfigA extends BaseConfig {
@Bean
DataSource dataSource() {
return ...;
}
}

@Configuration
class ConfigB extends BaseConfig {
@Override
@Bean
DataSource dataSource() { return ...; } }
}

It is not currently defined what will happen if all three of these classes are scanned.

Currently the container will parse each @Configuration class and register bean definitions as each are encountered. This means that the DataSource @Bean will be registered three times, and may not be registered in the correct order (e.g. the base class abstract method could be the last encountered and thus the one to override the previous two definitions.

The container should have awareness of @Configuration class hierarchies, and parse/register only the most specific/narrow base class.

Of course, in cases where there are sibling subclasses (same level in the inheritance tree), registration (and overrides) will occur on an as-scanned (or as-registered) basis.

---

Issue Links:

• Revised support for bean definition visibility and overriding [SPR-8189] #12839 Revised support for bean definition visibility and overriding ("is depended on by")
• Automatically detect and register nested @Configuration classes [SPR-8186] #12837 Automatically detect and register nested @Configuration classes ("is depended on by")
• Preserve 'reader' attribute in @ImportResource hierarchies [SPR-6327] #10993 Preserve 'reader' attribute in @ImportResource hierarchies

2 votes, 5 watchers

[spring-projects-issues]

Juergen Hoeller commented

This doesn't seem to be an issue (anymore) since we're excluding abstract classes from component scanning anyway and have stronger ordering mechanisms now.

Juergen