The {@code SmartContextLoader} SPI supersedes the {@link ContextLoader} SPIintroduced in Spring 2.5: a {@code SmartContextLoader} can choose to processeither resource locations or configuration classes. Furthermore, a {@code SmartContextLoader} can set active bean definition profiles in thecontext that it loads (see {@link MergedContextConfiguration#getActiveProfiles()}and {@link #loadContext(MergedContextConfiguration)}).
Clients of a {@code SmartContextLoader} should call{@link #processContextConfiguration(ContextConfigurationAttributes) processContextConfiguration()} prior to calling{@link #loadContext(MergedContextConfiguration) loadContext()}. This gives a {@code SmartContextLoader} the opportunity to provide custom support formodifying resource locations or detecting default resource locations or default configuration classes. The results of {@link #processContextConfiguration(ContextConfigurationAttributes) processContextConfiguration()} should be merged for all classes in thehierarchy of the root test class and then supplied to {@link #loadContext(MergedContextConfiguration) loadContext()}.
Even though {@code SmartContextLoader} extends {@code ContextLoader}, clients should favor {@code SmartContextLoader}-specific methods over those defined in {@code ContextLoader}, particularly because a {@code SmartContextLoader} may choose not to support methods defined inthe {@code ContextLoader} SPI.
Concrete implementations must provide a public
no-args constructor.
Spring provides the following out-of-the-box implementations:
|
|