Version 4.1 included a number of improvements, as described in the following sections:
Spring 4.1 introduces a much simpler infrastructure to register JMS
listener endpoints by annotating bean methods with
@JmsListener
.
The XML namespace has been enhanced to support this new style (jms:annotation-driven
),
and it is also possible to fully configure the infrastructure using Java config
(@EnableJms
,
JmsListenerContainerFactory
). It is also possible to register listener endpoints
programmatically using
JmsListenerConfigurer
.
Spring 4.1 also aligns its JMS support to allow you to benefit from the spring-messaging
abstraction introduced in 4.0, that is:
@Payload
, @Header
, @Headers
, and @SendTo
. It
is also possible to use a standard Message
in lieu of javax.jms.Message
as method
argument.
JmsMessageOperations
interface is available and permits JmsTemplate
like operations using the Message
abstraction.
Finally, Spring 4.1 provides additional miscellaneous improvements:
JmsTemplate
<jms:listener/>
element
BackOff
implementation
Spring 4.1 supports JCache (JSR-107) annotations using Spring’s existing cache configuration and infrastructure abstraction; no changes are required to use the standard annotations.
Spring 4.1 also improves its own caching abstraction significantly:
CacheResolver
. As a result the
value
argument defining the cache name(s) to use is no longer mandatory.
@CacheConfig
class-level annotation allows
common settings to be shared at the class level without enabling any cache operation.
CacheErrorHandler
Spring 4.1 also has a breaking change in the Cache
interface as a new putIfAbsent
method has been added.
ResourceHttpRequestHandler
has been expanded with new abstractions ResourceResolver
, ResourceTransformer
,
and ResourceUrlProvider
. A number of built-in implementations provide support
for versioned resource URLs (for effective HTTP caching), locating gzipped resources,
generating an HTML 5 AppCache manifests, and more. See Section 22.16.9, “Serving of Resources”.
java.util.Optional
is now supported for @RequestParam
, @RequestHeader
,
and @MatrixVariable
controller method arguments.
ListenableFuture
is supported as a return value alternative to DeferredResult
where an underlying service (or perhaps a call to AsyncRestTemplate
) already
returns ListenableFuture
.
@ModelAttribute
methods are now invoked in an order that respects inter-dependencies.
See SPR-6299.
@JsonView
is supported directly on @ResponseBody
and ResponseEntity
controller methods for serializing different amounts of detail for the same POJO (e.g.
summary vs. detail page). This is also supported with View-based rendering by
adding the serialization view type as a model attribute under a special key.
See the section called “Jackson Serialization View Support” for details.
@ResponseBody
and ResponseEntity
methods just after the controller method returns and before the response is written.
To take advantage declare an @ControllerAdvice
bean that implements ResponseBodyAdvice
.
The built-in support for @JsonView
and JSONP take advantage of this.
See Section 22.4.1, “Intercepting requests with a HandlerInterceptor”.
There are three new HttpMessageConverter
options:
@EnableWebMvc
or <mvc:annotation-driven/>
, this is used by default
instead of JAXB2 if jackson-dataformat-xml
is in the classpath.
@RequestMapping
. For example FooController
with method handleFoo
is named "FC#handleFoo". The naming strategy is pluggable.
It is also possible to name an @RequestMapping
explicitly through its name attribute.
A new mvcUrl
function in the Spring JSP tag library makes this easy to use in JSP pages.
See Section 22.7.3, “Building URIs to Controllers and methods from views”.
ResponseEntity
provides a builder-style API to guide controller methods
towards the preparation of server-side responses, e.g. ResponseEntity.ok()
.
RequestEntity
is a new type that provides a builder-style API to guide client-side REST
code towards the preparation of HTTP requests.
MVC Java config and XML namespace:
GroovyMarkupConfigurer
and respecitve
ViewResolver
and `View' implementations.
SockJsClient
and classes in same package.
SessionSubscribeEvent
and SessionUnsubscribeEvent
published
when STOMP clients subscribe and unsubscribe.
@SendToUser
can target only a single session and does not require an authenticated user.
@MessageMapping
methods can use dot "." instead of slash "/" as path separator.
See SPR-11660.
MessageHeaderAccessor
.
Groovy scripts can now be used to configure the ApplicationContext
loaded for
integration tests in the TestContext framework.
Test-managed transactions can now be programmatically started and ended within
transactional test methods via the new TestTransaction
API.
SQL script execution can now be configured declaratively via the new @Sql
and
@SqlConfig
annotations on a per-class or per-method basis.
Test property sources which automatically override system and application property
sources can be configured via the new @TestPropertySource
annotation.
Default TestExecutionListener
s can now be automatically discovered.
Custom TestExecutionListener
s can now be automatically merged with the default
listeners.
The documentation for transactional testing support in the TestContext framework has been improved with more thorough explanations and additional examples.
MockServletContext
, MockHttpServletRequest
, and other
Servlet API mocks.
AssertThrows
has been refactored to support Throwable
instead of Exception
.
MockMvcBuilder
recipes can now be created with the help of MockMvcConfigurer
. This
was added to make it easy to apply Spring Security setup but can be used to encapsulate
common setup for any 3rd party framework or within a project.
MockRestServiceServer
now supports the AsyncRestTemplate
for client-side testing.