Spring Boot 1.3 Release Notes
Classes, methods and properties that were deprecated in Spring Boot 1.2 have been removed in this release. Please ensure that you aren’t calling deprecated methods before upgrading.
Spring Boot 1.2 registered any Jackson Module beans with every ObjectMapper in the application context. This made it impossible to take complete control of an ObjectMapper bean’s modules. Spring Boot 1.3 will only register Jackson Module beans with ObjectMappers that are created or configured with the auto-configured Jackson2ObjectMapperBuilder. This brings the behaviour of module configuration into line with Boot’s other Jackson configuration.
In order to prevent double initialization Spring specific log configuration files can now be used. It’s recommended (although not required) that you rename any default log configuration files to use a -spring suffix. For example logback.xml would change to logback-spring.xml.
In Spring Boot 1.2, if you specified a custom logging configuration file using logging.config and the file did not exist, it would silently fallback to using the default configuration. Spring Boot 1.3 fails due to the missing file. Similarly, if you provided a custom Logback configuration file which was malformed, Spring Boot 1.2 would fall back to its default configuration. Spring Boot 1.3 fails and reports the problems with the configuration to System.err.
The spring.hateoas.apply-to-primary-object-mapper property has been removed as the Spring HATEOAS auto-configuration has been reworked such that it no longer affects the context’s primary ObjectMapper. It has been replaced with a property named spring.hateoas.use-hal-as-default-json-media-type which controls whether or not
the Spring HATEOAS HTTP message converter will handle requests for application/json in addition to requests for
application/hal+json.
The security settings for what information is visible on the actuator /health endpoint have been tweaked a little to provide better consistency. See the HTTP health endpoint access restrictions section in the reference guide for complete details.
Spring Boot 1.2 supported native response compression for Tomcat users, or compression using Jetty’s GZipFilter for users of Jetty, Tomcat, and Undertow. Motivated by the Jetty team’s deprecation of their gzip filter, Spring Boot 1.3 replaces this with support for native response compression in all three embedded containers. As a result the server.tomcat.compression. and spring.http.gzip. properties are no longer supported. The new server.compression.* properties should be used instead.
By default tomcat no longer saves session data in /tmp. If you want to use persistent sessions with Tomcat set the server.session.persistent property to true. The server.session.store-dir can be used to save files in a specific location.
The spring-boot-starter-jetty "Starter POM" no longer includes org.eclipse.jetty:jetty-jsp. If you are using Jetty with JSPs you will now need to directly add this dependency yourself.
Stacktrace information is now never included when Spring MVC renders an error response. If you want Spring Boot 1.2 behavior set error.include-stacktrace to on-trace-param.
Due to the upgrade to Spring Security 4, Spring Boot 1.3 has also upgraded the dependency management and auto-configuration of Thymeleaf’s Spring Security support. The coordinates of the new artifact are org.thymeleaf.extras:thymeleaf-extras-springsecurity4. Please update your pom.xml or build.gradle accordingly.
Spring Boot applications no longer fail to start when a /templates folder cannot be found. If you are using a supported templating technology, and you forget to add /templates, a warning is now logged instead.
The GroovyTemplateProperties class now extends AbstractTemplateViewResolverProperties and provides additional configuration options. If you currently define a prefix.spring.groovy.template.prefix property to define a custom resource location you should rename it to prefix.spring.groovy.resource-loader-location.
Spring Boot no longer honours @Order to manage ordering between auto-configuration classes, please use @AutoconfigureOrder instead. Note also that you can use @AutoconfigureBefore and @AutoconfigureAfter to specify the order against specific auto-configuration classes.
The Spring Boot Gradle plugin no longer adds src/main/resources directly to the classpath when using bootRun. If you want live, in-place editing we recommend using Devtools. The addResources property can be set in your gradle build if you want to restore Spring Boot 1.2. behaviour.
Spring Boot’s gradle plugin has been updated in this release to use the dependency management plugin. Most users should be unaffected by this change, however those who were using the versionManagement configuration to apply their own blessed versions will have to update their build scripts.
Rather than requiring a properties file to configure version management, the new plugin allows you to use a Maven bom. For example:
dependencyManagement {
imports {
mavenBom 'com.example:example-bom:1.0'
}
}The Spring Boot Gradle plugin will no longer apply Gradle’s application plugin by default. If you wish to make use of the application plugin you will have to apply it in your build.gradle.
If you do not need the functionality provided by the application plugin, but were using its mainClassName or applicationDefaultJvmArgs properties then you will need to make some minor updates to your build.gradle.
The main class should now be configured using the mainClass property on the springBoot extension, for example:
springBoot {
mainClass = 'com.example.YourApplication'
}
applicationDefaultJvmArgs should now be configured in your project’s ext block,
for example:
ext {
applicationDefaultJvmArgs = [ '-Dcom.example.property=true' ]
}
If you were configuring your project’s main class using the main property of the application plugin’s run task, you should move this configuration to the bootRun task instead:
bootRun {
main = com.example.YourApplication
}
The Spring Boot Maven plugin no longer adds src/main/resources directly to the classpath when using spring-boot:run. If you want live, in-place editing we recommend using Devtools. The addResources property can be set in your pom.xml if you want to restore Spring Boot 1.2. behavior.
If you use the spring-boot-starter-parent, Maven tokens are only filtered using @ now. This prevents any Spring placeholders in your configuration (e.g. ${foo}) to be be expanded by the build.
Concretely, if you are still using the standard format (i.e. ${project.version}) please migrate them (@project.version@) or override the maven-resources-plugin configuration.
Spring Boot 1.3 now supports the use of Maven boms to configure its dependency management in place of the properties file-based metadata. @DependencyManagementBom should be used in place of @GrabMetadata to provide the coordinates of a bom, for example @DependencyManagementBom("io.spring.platform:platform-bom:1.1.2.RELEASE").
The following application.properties keys have been renamed to improve consistency:
-
spring.view.tospring.mvc.view. -
spring.pidfiletospring.pid.file -
error.pathtoserver.error.path -
server.session-timeouttoserver.session.timeout -
servet.tomcat.accessLogEnabledtoserver.tomcat.accesslog.enabled -
servet.tomcat.accessLogPatterntoserver.tomcat.accesslog.pattern -
servet.undertow.accessLogDirtoserver.undertow.accesslog.dir -
servet.undertow.accessLogEnabledtoserver.undertow.accesslog.enabled -
servet.undertow.accessLogPatterntoserver.undertow.accesslog.pattern -
spring.oauth2.tosecurity.oauth2. -
server.tomcat.compressionandspring.http.gziptoserver.compression.* -
prefix.spring.groovy.template.prefixtoprefix.spring.groovy.resource-loader-location
Spring Boot 1.3 requires Spring Framework 4.2 or later and is not compatible with earlier versions.
Spring Boot 1.3 uses Spring Security 4.0. See the Spring Security documentation for information on migrating from 3.2.
|
Tip
|
Check the configuration changelog for a complete overview of the changes in configuration. |
Spring Boot 1.3 builds on and requires Spring Framework 4.2. Several 3rd party dependencies have been upgraded with this release. No major upgrades have been made to the Tomcat or Jetty versions with this release.
Spring Boot 1.3 includes a new spring-boot-devtools module which aims to improve the development-time experience. The module provides:
-
Sensible property defaults (for example disabling template caches)
-
Automatic application restarts
-
LiveReload support
-
Remote development support (including remote updates and remote debug via an HTTP tunnel).
-
Persistent HTTP sessions across restarts
See the updated documentation for more information.
Auto-configuration is now provided for the following cache technologies:
-
EhCache
-
Hazelcast
-
Infinispan
-
Any compliant JCache (JSR 107) implementation
-
Redis
-
Guava
In addition, simple Map based in-memory caching is also supported. Caching is automatically configured when your application @Configuration is annotated with @EnableCaching. Cache statistics are now also exposed as an actuator endpoint (when the underlying technology allows).
For complete details see the updated documentation.
The Spring Boot Maven and Gradle plugins can now generate full executable archives for Linux/Unix operating systems. Furthermore you can now easily install these JARs as init.d or systemd services. Running a fully executable JAR is as easy as typing:
$ ./myapp.jarand to install it as an init.d service:
$ sudo link -s /var/myapp/myapp.jar /etc/init.d/myappAdditional information is available in the reference documentation.
Auto-configuration is now provided for Cassandra. See the reference documentation for details.
You can now use @EnableAuthorizationServer and @EnableResourceServer to quickly create OAuth2 authorization and resource servers. In addition, @EnableOAuth2Client allows your application to act as an OAuth2 client. For details see the overhauled security section of the reference guide.
With Spring Session and Spring Data Redis on the classpath, web applications will now be auto-configured to store user sessions in Redis. See the accompanying sample for more information.
Auto-configuration is now provided for jOOQ. You can @Autowire a jOOQ DSLContext directly into your Spring Beans to create type safe database queries. Additional customization is supported via spring.jooq.* application properties.
See the "Using jOOQ" section of the reference documentation for details.
Auto-configuration is now provided for the SendGrid email delivery service.
Apache Artemis was formed in 2015 when HornetQ was donated to the Apache Foundation. As of Spring Boot 1.3, Apache Artemis is fully supported and can be used in pretty much the same way as HornetQ. If you are migrating to Artemis you should rename any spring.hornetq. properties to spring.artemis..
A new spring-boot-starter-validation "starter POM" is now available to provide bean validation (JSR 303) support.
When using an embedded servlet container, automatic registration of @WebServlet, @WebFilter and @WebListener annotated classes can now be enabled using @ServletComponentScan.
You can now configure basic aspects of Spring’s ResourceChainRegistration via application properties. This allows you to create unique resource names so that you can implement cache busting. The spring.resources.chain.strategy.content. properties can be used to configure fingerprinting based on the content of the resource; and spring.resources.chain.strategy.fixed. properties can be used if you want to use a "fixed version" for your fingerprint.
Spring Boot will now automatically infer the driver class name from the JDBC URL for the following databases:
-
DB2
-
Firebird
-
Teradata
The connection pool used by auto-configuration can now be specified via the spring.datasource.type configuration key.
Auto-configuration for H2’s web console has been added.
When you are using Spring Boot’s developer tools, adding a dependency on com.h2database:h2 to your web application is all that is necessary to get started. Please see the documentation for further information.
Auto-configuration for Embedded MongoDB has been added. A dependency on de.flapdoodle.embed:de.flapdoodle.embed.mongo is all that’s necessary to get started.
Configuration, such as the version of Mongo to use, can be controlled via application.properties. Please see the
documentation for further information.
You can now use ANSI placeholders in your banner.txt file to produce color output. Any ${Ansi.}, ${AnsiColor.}, ${AnsiBackground.} or ${AnsiStyle.} properties will be expanded. For example:
${AnsiColor.BRIGHT_GREEN}My Application
${AnsiColor.BRIGHT_YELLOW}${application.formatted-version}${AnsiColor.DEFAULT}
The -default suffix is now considered when loading application.properties (and application.yml) files when no specific profile is active. This can be helpful when you use profiles to indicate deployment environments, for example:
| File | Description |
|---|---|
|
Shared properties that are always loaded |
|
Properties loaded when the |
|
Properties loaded when the |
|
Properties loaded when no profile is active. |
You can now implement the ApplicationRunner interface as an alternative to CommandLineRunner. This works in the same way but provides arguments as a ApplicationArguments interface rather than a String[]. You can also inject ApplicationArguments directly into any existing bean if you need to access the application arguments.
The ApplicationArguments interface provides convenience methods for accessing "option" and "non-option" arguments. For example:
@Autowired
public MyBean(ApplicationArguments args) {
boolean debug = args.containsOption("debug");
List<String> files = args.getNonOptionArgs();
// if run with "--debug logfile.txt" debug=true, files=["logfile.txt"]
}See Accessing application arguments for details.
The logging.pattern.console and logging.pattern.file properties can now be used to specify a logging pattern directly from your application.properties. That can be handy If you only want to customize patterns as you no longer need to define your own log*.xml file.
If you are using logback or log4j2, we now include information about the location from which each class in a stack trace was loaded (this can be customized via logging.exception-conversion-word).
Log4J 2’s default output has been improved and is now similar to the output produced by Logback.
Tomcat access logs have better customizations: the directory and file prefix/suffix can now be customized via configuration.
Spring Boot 1.3 supports some new tags which can be used in your logback configuration file. To use the tags you need to first rename any logback.xml configuration to logback-spring.xml. Once your configuration file has been renamed, the following tags are available.
| Tag | Description |
|---|---|
|
Allows you to optionally include or exclude sections of configuration based on the active Spring profiles. |
|
Allows you to surface properties from the Spring Environment for use within Logback. |
See the Logback extensions section of the reference documentation for more details.
Update Tomcat, Jetty and Undertow to serialize session data when the application is stopped and load it again when the application restarts. Persistent session are opt-in; either by setting persistentSession
on the ConfigurableEmbeddedServletContainer or by using the property server.session.persistent=true (Persistent sessions are enabled by default with Devtools).
The location to save persistent session data can be specified using the server.session.store-dir property.
X-Forwarded-For header support is now included for Jetty and Undertow. Tomcat support has also been refreshed so that a single server.use-forward-headers property can be set to true if X-Forwarded-For headers should be respected. Spring Boot will detect deployments to Cloud Foundry or Heroku and automatically enable support.
If you are using @ConfigurationProperties on beans, you no longer need to add @EnableConfigurationProperties to your configuration as Spring Boot autoconfigures it now. As before you can ask Spring to create a bean for your @ConfigurationProperties class using the value attribute of @EnableConfigurationProperties or with a regular @Bean definition.
If you need custom type conversion for some configuration keys without a custom ConversionService (with bean id conversionService), you now need to qualify the Converter beans to use with @ConfigurationPropertiesBinding as we no longer lookup all Converter beans.
Both JMS and Rabbit endpoints can be easily disabled via configuration. The default container factory that is created if none exists can also be customized via configuration.
The fallbackToSystemLocale flag of the auto-configured MessageSource instance can now be configured via the spring.messages.fallback-to-system-locale configuration key.
The auto-configuration report has now an additional section called "Unconditional classes". It lists any auto-configuration classes that do not have any class-level conditions, i.e. the class will be always be part of the application’s configuration. It also now lists configurations that have been manually excluded via @SpringBootApplication(exclude=…) or @EnableAutoConfiguration(exclude=…).
It is now possible to also exclude auto-configuration classes via the spring.autoconfigure.excludes property. Similarly, a new @ImportAutoConfiguration annotation can be used by tests that wish to selectively import certain auto-configuration classes.
The error.include-stacktrace property can now be used to determine when stack trace attributes should be included in MVC error responses. Options are never, always or on-trace-param (with never being the default).
The spring-boot-actuator metrics support has been extended to support export and aggregation. In addition, Java 8 specific GaugeService and CounterService implementations are now provided (and used when possible) which offer improved performance.
See the extended metrics documentation for details.
Additional HealthIndicators are now provided and auto-configured for:
-
Elasticsearch
-
Email
-
JMS
The following additional actuator endpoints have been added with Spring Boot 1.3:
| Name | Description |
|---|---|
|
Provides access to the log file (if one has been configured). |
|
Provides details of any Flyway database migrations that have been applied. |
|
Provides details of any Liquibase database migrations that have been applied. |
The Actuator’s endpoint now support CORS. Support is disabled by default but can be enabled by configuring endpoints.cors.allowed-origins.
You can now use regular expression to filter the /env and /metrics actuator endpoints. For example http://localhost:8080/metrics/.root..
Actuator HTTP endpoints are now enhanced with hypermedia links when you have Spring HATEOAS on your classpath (for example via spring-boot-starter-hateoas). A new "discovery page" is also provided with links to all actuator endpoints. Support is also provided for the HAL browser if its webjar is on the classpath.
See the "Hypermedia for MVC Endpoints" reference section for more details.
A new spring-boot-actuator-docs modules is provided with Spring Boot 1.3 which allows actuator documentation to be embedded into your application. Once the modules is on your classpath you can hit /docs to get information about the actuator endpoints including a sample of the data that each endpoint returns.
It is now possible to easily disable all the default health indicators via the management.health.defaults.enabled property.
The actuator TraceWebFilter (use to trace HTTP request/response details) can now log more information. Use the management.trace.include property to configure the options that you want to include (see the TraceProperties.Include enum).
The Maven plugin now include start and stop goals. These enable applications to be started without blocking Maven (allowing other goals to operate on the application). This technique is often used to launch intergration tests from Maven.
A byproduct of this work is that a new SpringApplicationAdminMXBean interface has been added which (when enabled) allows a Spring Boot application to be controlled via JMX.
The spring-boot-maven-plugin now includes a profiles property that can be used with spring-boot:run. You can configure profiles in your pom.xml or use -Drun.profiles on the command line. See the updated plugin documentation for details.
Spring Boot now includes an AntLib module to help you create executable jars from Ant. See the "Spring Boot AntLib module" section in the reference docs.
The META-INF/spring-configuration-metadata.json file format has been updated to support new deprecation and hints attributes. Hints can be used by IDE developers to provided better content assist support. Deprecation allow for the deprecation and a replacement key, if any. Such information can be provided by adding @DeprecatedConfigurationProperty on the getter of the property. See the updated appendix for details.
We’ve also improved the detection of default value: if a property is initialized via a method call having a single argument, we consider said argument to be the default value (i.e. Charset.forName("UTF-8") would detect UTF-8 as the default value).
A new spring-boot-configuration-metadata module is now available for any tool developers wishing to use the configuration meta-data in their own tools and apps; it offers an API to read the meta-data and build a repository out of it.
The CLI will now use the repositories configured in Maven’s settings.xml during dependency resolution. For a repository to be used, the profile in which it is declared must be active.
The CLI can also now generate executable WAR files. Use $ spring war <filename.war> <script.groovy>.
Apache HttpCore 4.4.5 removed a handful of annotations. This is a binary incompatible change if you are using an annotation processor and are sub-classing a class that uses one of the removed annotations. For example, if the class was using @Immutable you will see compile-time annotation processing fail with [ERROR] diagnostic: error: cannot access org.apache.http.annotation.Immutable.
The problem can be avoided by downgrading to HttpCore 4.4.4 or, preferably, by structuring your code so that the problematic class is not subject to compile-time annotation processing.
The following miscellaneous updates are also include with Spring Boot 1.3:
-
Jackson’s Java 8 module will be automatically registered when using Java 8.
-
A
TransactionTemplatebean is now included as part ofTransactionAutoConfiguration. -
A
MailServerbean can now be obtained via JNDI by using thespring.mail.jndi-nameproperty. -
You can now configure the servlet name (when using an embedded servlet container) via the
server.display-nameproperty. -
Flyway migration strategies can now be configured via a
FlywayMigrationStrategybean. -
A new
SpringBootVersionclass has been added (similar toSpringVersionfrom the core framework). -
You can now used hamcrest matchers with
OutputCaptureto verify tests produce certain output. -
You can now configure Spring Boot to use Elasticsearch non local nodes.
-
The
ApplicationPidFileWritercan now throw an exception if afail-on-write-errorproperty is set (see the updated javadoc). -
The Maven plugin now includes a
useTestClasspathoption for use withspring-boot:run. -
Extra database heath queries are now provided for DB2 and Informix.
-
Property binding failures now include better exception messages.
-
The
@SpringBootApplicationannotation now includesscanBasePackagesandscanBasePackageClassesattributes. -
New
AllNestedConditionsandNoneNestedConditionsare provided (similar to the existingAnyNestedCondition) -
Active profiles are now printed to output log when your application starts.
-
The
spring.main.banner-modeproperty can be used to switch betweenCONSOLE,LOGorOFFoutput. -
Remote DevTools can now work behind a proxy server (see the
spring.devtools.remote.proxy.*properties) -
Jackson’s parameter names module (providing Java 8 support) will now be auto-configured when it’s on your classpath.
-
Spring’s WebSocket message converters will now be auto-configured.
-
A new
DelegatingFilterProxyRegistrationBeanclass has been added to allow filters to be registered with embedded servlet containers via aDelegatingFilterProxy.
-
The
Application.showBannerandApplicationBuilder.showBannermethods have been deprecated in favor ofsetBannerMode. -
@ConditionalOnMissingClassnow expects the class name to be provided using thevalueattribute rather thanname. -
Log4JLoggingSystemis now deprecated following Apache’s EOL declaration for log4j 1.x. -
The
ConfigurableEmbeddedServletContainersetJspServletClassNameandsetRegisterJspServletmethods have been replaced bysetJspServlet. -
The
EndpointMBeanclass (and subclasses) now expect anObjectMapperto be provided to the constructor. -
The
DropwizardMetricWriterhad been replaced byDropwizardMetricService. -
The protected
SpringApplication.afterRefreshmethod that takes aString[]has been deprecated in favor of a version that takesApplicationArguments. -
VcapEnvironmentPostProcessorhas been deprecated in favor ofCloudFoundryVcapEnvironmentPostProcessor. -
The
LoggingSysteminitializemethod has been deprecated in favor of a version that acceptsLoggingInitializationContext. -
The
ServerPortInfoApplicationContextInitializerhas been deprecated to move it to a new package -
org.springframework.boot.autoconfigure.orm.jpa.EntityManagerFactoryBuilderhas been deprecated to move it to a new package.org.springframework.boot.orm.jpa.EntityManagerFactoryBuildershould be used instead. A bean of the old type is no longer auto-configured. If your application uses this bean it should be updated to use theorg.springframework.boot.orm.jpa.EntityManagerFactoryBuilderbean instead.