AnnotationConfigContextLoader should not restrict the name of default configuration classes to ContextConfiguration [SPR-8395]

[spring-projects-issues]

Eric Sirianni opened SPR-8395 and commented

Overview

This issue is a spinoff of #10852 and was originally titled "Support flexible (wildcard-based) resource suffixes in AnnotationConfigContextLoader".

Status Quo

When generating default configuration classes, AnnotationConfigContextLoader currently (as of Spring 3.1 M2) generates a class name by appending "$ContextConfiguration" to the name of the test class. For a test class named MyTests this requires the default configuration class to be named MyTests$ContextConfiguration (i.e., that it be a static inner class named ContextConfiguration).

Goal

AnnotationConfigContextLoader should use reflection to inspect all inner classes defined within the test class that is annotated with @ContextConfiguration and consider any inner class that meets the following criteria to be a default configuration class:

• not private
• not final
• static
• annotated with @Configuration

Original Description

Suggestion to enhance AnnotationConfigContextLoader to support wildcards for the default @Configuration look-up rules. The semantics would be that any class that matches that wildcard AND has an @Configuration annotation could be picked up.

As a further suggestion, change the default resource suffix pattern to "$*" -- this would satisfy the 'convention over configuration' but also give some naming flexibility to users.

---

Affects: 3.1 M2

Issue Links:

• Provide TestContext support for @Configuration classes [SPR-6184] #10852 Provide TestContext support for @Configuration classes

[spring-projects-issues]

Sam Brannen commented

AnnotationConfigContextLoader now generates a list of default configuration classes by finding all non-private, non-final, static, inner classes of the test class that are annotated with @Configuration. This lifts the restriction that such candidate default configuration classes be named ContextConfiguration. In other words, developers now have the freedom to name static inner @Configuration classes as they wish, and such classes will be automatically recognized as default configuration classes.