Description
Chris Beams opened SPR-6327 and commented
Status Quo
Currently, either of the following work fine:
@Configuration
@ImportResource(
locations = "com/foo/config.xml",
reader = XmlBeanDefinitionReader.class)
public class ConfigA { }
@Configuration
@ImportResource(
locations = "com/foo/config.properties",
reader = PropertiesBeanDefinitionReader.class)
public class ConfigB { }However, the following will not work:
@Configuration
@ImportResource(
locations = "com/foo/config.properties",
reader = PropertiesBeanDefinitionReader.class)
public class ConfigB extends ConfigA { }Analysis
Problem: the XML file specified in ConfigA will be read by the PropertiesBeanDefinitionReader declared in ConfigB, which naturally fails.
Cause: when parsing annotations from the @Configuration class hierarchy, the last reader attribute wins, effectively overriding any other reader attributes from classes up the hierarchy.
Solution: crawl the class/annotation hierarchy manually and build up a context containing every resource and its associated BeanDefinitionReader type, analogous to the support for loader in @ContextConfiguration in the Spring TestContext Framework (TCF).
This is similar in concept to the way that TCF operates. In this way, this improvement will make sense to implement alongside #10976, which deals with support for relative paths and import-by-convention semantics -- features that are also supported by TCF.
Issue Links:
- Improve support for @Configuration class hierarchies [SPR-8187] #12838 Improve support for
@Configurationclass hierarchies - Support relative and by-convention use of @ImportResource [SPR-6310] #10976 Support relative and by-convention use of
@ImportResource
Referenced from: commits ae11387