Spring Boot 1.4.0 M3 Release Notes

For changes in earlier milestones, please refer to:

Upgrading from Spring Boot 1.4.0 M2

See instructions in the 1.4.0.M2 release notes for upgrading from v1.4.0.M2 and earlier.

Dispatch Options Request

The default spring.mvc.dispatch-options-request property has changed from false to true to align with Spring Framework’s preferred default. If you don’t want OPTIONS requests to be dispatched to FrameworkServlet.doService you should explicitly set spring.mvc.dispatch-options-request to false.

Remote Shell

The CRaSH properties have moved from the shell. namespace to the management.shell. namespace. Also, the authentication type should now be defined via management.shell.auth.type.

Multipart support

The multipart properties have moved from the multipart. namespace to the spring.http.multipart. namespace.

Integration Starter

spring-boot-starter-integration has been streamlined by removing four modules that are not necessarily used by a typical Spring Integration application. The four modules are:

spring-integration-file
spring-integration-http
spring-integration-ip
spring-integration-stream

If your application relies on any of these four modules, you should add an explicit dependency to your pom or build.gradle.

Additionally, spring-integration-java-dsl has been added to the starter. Using the DSL is the recommended way to configure Spring Integration in your application.

Spring Session auto-configuration improvements

Spring Boot supports more backend stores for Spring Session: alongside Redis, JDBC, MongoDB, Hazelcast and in memory concurrent hash maps are also supported. A new spring.session.store-type mandatory property has been introduced to select the store Spring Session should be using. If you were using Spring Session with the redis store previously, you’ll need to set the following to you configuration now:

spring.session.store-type=redis

Launch script identity

When the launch script is determining the application’s default identity, the canonical name of the directory containing the jar will now be used. Previously, if the directory containing the jar was a symlink, the name of the symlink was used. If you require more control over the application’s identity, the APP_NAME environment variable should be used.