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 CacheInterface 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 21.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 21.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 21.7.2, “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 TestExecutionListeners can now be automatically discovered.
Custom TestExecutionListeners 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.