Introduce 'value' attribute in @SpringApplicationConfiguration

[sbrannen]

Issue #3400 retrofitted @SpringApplicationConfiguration to use the new @AliasFor annotation from Spring Framework 4.2 to introduce explicit annotation attribute overrides.

Due to the opinionated view of Spring Boot with regard to favoring @Configuration classes over XML and Groovy configuration, @SpringApplicationConfiguration can benefit from yet another feature of @AliasFor. Namely, @SpringApplicationConfiguration can introduce a new value attribute that is an attribute override for the classes attribute in @ContextConfiguration.

Proposed change:

// ...
public @interface SpringApplicationConfiguration {

    /**
     * @return the context configuration classes
     * @see ContextConfiguration#classes
     * @see #classes
     */
    @AliasFor(annotation = ContextConfiguration.class, attribute = "classes")
    Class<?>[] value() default {};

    // ...
}

Consequently, if a Spring Boot integration test only needs to declare a configuration class, the declaration can be simplified as follows: @SpringApplicationConfiguration(SampleApplication.class).

[snicoll]

👍

[sbrannen]

I unfortunately made the proposal too soon...

Declaring multiple annotation attribute overrides for the same attribute in a meta-annotation is not supported in Spring Framework 4.2.0. The reason is that the merge algorithm in MergedAnnotationAttributesProcessor in AnnotatedElementUtils overwrites previous aliased values with subsequent aliased values, thereby letting the last one win -- which happens silently and is not intuitive.

This will be fixed in Spring Framework 4.2.1. See SPR-13345 for details.

[sbrannen]

The following is an alternative solution:

// ...
public @interface SpringApplicationConfiguration {

    @AliasFor("value")
    Class<?>[] classes() default {};

    @AliasFor("classes")
    Class<?>[] value() default {};

    // ...
}

The above approach defines an explicit local alias pair between the classes and value attributes. In theory, this should have worked with Spring Framework 4.2.0; however, due to a bug it did not. This bug has already been fixed in SPR-13325, and the use case has been tested in commit spring-projects/spring-framework@e20b47c.

Thus, this approach can be used against recent 4.2.1 snapshots.

[snicoll]

Stuck again, see SPR-13320