The SmartContextLoader SPI supersedes the ContextLoader SPI introduced in Spring 2.5: a SmartContextLoader can choose to process either resource locations or annotated classes. Furthermore, a SmartContextLoader can set active bean definition profiles in the context that it loads (see MergedContextConfiguration.getActiveProfiles() and loadContext(MergedContextConfiguration)).
See the Javadoc for @ContextConfiguration for a definition of annotated class.
Clients of a SmartContextLoader should call processContextConfiguration() prior to calling loadContext(). This gives a SmartContextLoader the opportunity to provide custom support for modifying resource locations or detecting default resource locations or default configuration classes. The results of processContextConfiguration() should be merged for all classes in the hierarchy of the root test class and then supplied to loadContext().
Even though SmartContextLoader extends ContextLoader, clients should favor SmartContextLoader-specific methods over those defined in ContextLoader, particularly because a SmartContextLoader may choose not to support methods defined in the ContextLoader SPI.
Loads a new context based on the supplied merged context configuration, configures the context, and finally returns the context in a fully refreshed state.
Processes the ContextConfigurationAttributes for a given test class.
Concrete implementations may choose to modify the locations or classes in the supplied ContextConfigurationAttributes, generate default configuration locations, or detect default configuration classes if the supplied values are null or empty.
Note: in contrast to a standard ContextLoader, a SmartContextLoader must preemptively verify that a generated or detected default actually exists before setting the corresponding locations or classes property in the supplied ContextConfigurationAttributes. Consequently, leaving the locations or classes property empty signals that this SmartContextLoader was not able to generate or detect defaults.
Concrete implementations should register annotation configuration processors with bean factories of application contexts loaded by this SmartContextLoader. Beans will therefore automatically be candidates for annotation-based dependency injection using @Autowired, @Resource, and @Inject. In addition, concrete implementations should set the active bean definition profiles in the context's Environment.
Any ApplicationContext loaded by a SmartContextLoader must register a JVM shutdown hook for itself. Unless the context gets closed early, all context instances will be automatically closed on JVM shutdown. This allows for freeing of external resources held by beans within the context (e.g., temporary files).