Preserve 'reader' attribute in @ImportResource hierarchies [SPR-6327]

[spring-projects-issues]

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 @Configuration class hierarchies
• Support relative and by-convention use of @ImportResource [SPR-6310] #10976 Support relative and by-convention use of @ImportResource

Referenced from: commits ae11387

[spring-projects-issues]

Chris Beams commented

See TODO in @Ignored test for this feature with in ImportResourceTests.testImportDifferentResourceTypes().