Introduce a DelegatingSmartContextLoader [SPR-8387]

[spring-projects-issues]

Sam Brannen opened SPR-8387 and commented

Status Quo

Placing an empty @ContextConfiguration annotation on a test class signals that default resource locations should be generated. Without declaring a specific ContextLoader, GenericXmlContextLoader will be used by default, which generates a default XML resource location.

With the introduction of AnnotationConfigContextLoader in Spring 3.1 M2, it would be nice if the TestContext framework supported a look-up mechanism to determine which ContextLoader (from a list of candidates) should be used to generate default resource locations or configuration classes and eventually load the context.

Goals

Introduce a DelegatingSmartContextLoader that delegates to a candidate SmartContextLoader list to determine which context loader is able to generate default resource locations or configuration classes for a given test class. The winning candidate should then be used to actually load the context.

Implementation Notes

By default, DelegatingSmartContextLoader should delegate to GenericXmlContextLoader and AnnotationConfigContextLoader, in that order. GenericPropertiesContextLoader will not be included by default.

Furthermore, the new SmartContextLoader SPI will have to provide support to query a SmartContextLoader to determine if the context loader is capable of generating default resource locations or configuration classes. Implementations must preemptively determine if the generated default(s) actually exists.

Depending on time and complexity, the implementation may or may not be generic in terms of whether it knows explicitly about only GenericXmlContextLoader and AnnotationConfigContextLoader or whether it supports any number of configured SmartContextLoader candidates.

---

Affects: 3.1 M2

Issue Links:

• Introduce SmartContextLoader SPI [SPR-8386] #13033 Introduce SmartContextLoader SPI ("depends on")
• Document DelegatingSmartContextLoader [SPR-8541] #13185 Document DelegatingSmartContextLoader ("is depended on by")

Referenced from: commits 72da569, 9a40021, a298c2d, d0cd678, 4611199, 21f3f59, f874ed9, e7298a8, e34fa6a, b8624b4, d2e6f82, 12eb9d7, 8e497d9, 4aed64e, 4cbe2ae, 19fc200, 4ef895a, b49d11f

[spring-projects-issues]

Søren Boisen commented

Would this also eliminate the need to specify loader=AnnotationConfigContextLoader.class when specifying classes=... ? I am guessing no from the description, but I think this case is pretty important too:

• Since you are using the classes annotation property, it is possible to automatically determine that the loader needs to be capable of supporting @Configuration classes.
• The need to specify the loader property requires some knowledge of the inner workings of the framework. It is not immediately obvious that you need to specify a specific loader implementation when using the classes property.

[spring-projects-issues]

Sam Brannen commented

Hi Søren,

Yes, that was actually the initial impetus behind this issue. Sorry that I didn't spell that out so clearly in the description.

I discuss this in my blog, Spring 3.1 M2: Testing with @Configuration Classes and Profiles.

Furthermore, you can actually see this already working in the DefaultLoaderDefaultConfigClassesBaseTests and DefaultLoaderExplicitConfigClassesBaseTests test cases that I recently checked in.

- Sam

[spring-projects-issues]

Sam Brannen commented

Implemented DelegatingSmartContextLoader that delegates to GenericXmlContextLoader and AnnotationConfigContextLoader.