This change adds support for configuring redirect view controllers and
also status controllers to the MVC Java config and the MVC namespace.
Issue: SPR-11543
This change makes it possible to configure RedirectView such that the
query string of the current request is added to the target URL.
This change is preparation for SPR-11543.
This change two new capabilities to ParameterizableViewController:
- configure a View instance (in addition to view name)
- configure response status code
The status code may be useful to send a 404 while also writing to the
body using a view.
The status code may also be used to override the redirect status code
of RedirectView. Even today it's possible to configure a "redirect:"
prefixed view name but the status code could not be selected. When a
3xx status is set, the code is passed on to the RedirectView while the
view name is automatically prefixed with "redirect:" (if not already).
For full control over RedirectView it is now also possible to
parameterize the controller with a View instance.
As one more possible resulting variation, given status 204 and no view
the request is considered handled (controller returns null).
This change is preparation for SPR-11543.
Since the MVC Java config always registers a ViewResolver (composite)
bean, at a very minimum we must add an InternalResourceViewResolver
consistent with default DispatcherServlet configuration and by
extension with the MVC namespace which falls back on DispatcherServlet
implicity if no <view-resolvers> element is present.
Issue: SPR-7093
Prior to this commit, the support for SQL script execution via @Sql
provided an algorithm for looking up a required
PlatformTransactionManager to use to drive transactions. However, a
transaction manager is not actually required for all testing scenarios.
This commit improves the transaction management support for @Sql so
that SQL scripts can be executed without a transaction if a transaction
manger is not present in the ApplicationContext. The updated algorithm
now supports the following use cases.
- If a transaction manager and data source are both present (i.e.,
explicitly specified via the transactionManager and dataSource
attributes of @SqlConfig or implicitly discovered in the
ApplicationContext based on conventions), both will be used.
- If a transaction manager is not explicitly specified and not
implicitly discovered based on conventions, SQL scripts will be
executed without a transaction but requiring the presence of a data
source. If a data source is not present, an exception will be thrown.
- If a data source is not explicitly specified and not implicitly
discovered based on conventions, an attempt will be made to retrieve
it by using reflection to invoke a public method named
getDataSource() on the transaction manager. If this attempt fails,
an exception will be thrown.
- If a data source can be retrieved from the resolved transaction
manager using reflection, an exception will be thrown if the
resolved data source is not the data source associated with the
resolved transaction manager. This helps to avoid possibly
unintended configuration errors.
- If @SqlConfig.transactionMode is set to ISOLATED, an exception will
be thrown if a transaction manager is not present.
Issue: SPR-11911
This commit adds an extra test implementation that runs the cache
abstraction tests using a JSR-107 cache manager. This further covers
JCacheCacheManager.
The actual JSR-107 implementation is ehcache-jcache that requires at
least ehcache 2.8.3. Since the ehcache-core artifact is no longer a
public artifact, this commit switches to the full ehcache library,
that is net.sf.ehcache:ehcache
Prior to this commit, @Sql provided attributes for configuring the
syntax of the referenced SQL scripts as well as exception handling and
transaction behavior; however, such configuration could not be reused
across @Sql declarations thus requiring developers to copy-and-paste
common configuration and resulting in unnecessary code duplication.
This commit addresses this issue by introducing a new @SqlConfig
annotation that can be used to declare common, global configuration for
SQL scripts that can be reused within a test class hierarchy.
- Introduced top-level @SqlConfig annotation and extracted
common configuration attributes from @Sql.
- @SqlConfig can be used at the class level for common, global config
or via the new 'config' attribute of @Sql for local config.
- Introduced MergedSqlConfig as a holder for the merged values from
local and global @SqlConfig instances. MergedSqlConfig also contains
the logic for overriding global configuration with local
configuration.
- Refactored all attributes of @SqlConfig to be either of type String
or custom enums in order to support overriding. Empty Strings or
DEFAULT enum values imply the use of a default or inherited value.
Issue: SPR-11896
Make it possible to use a ListenableFuture with Java 8
lambda expressions, using a syntax like
listenableFuture.addCallback(() -> ..., () -> ...);
Issue: SPR-11820
