Upgrade Spring Boot 2.6 To 2.7

[Milan Skidmore]

Themove to Spring Boot 3 will upgrade a number of dependencies and might require work on your end.You can review dependency management for 2.7.x with dependency management for 3.0.x to asses how your project is affected.

You may also use dependencies that are not managed by Spring Boot (e.g. Spring Cloud).As your project defines an explicit version for those, you need first to identify the compatible version before upgrading.

Spring Boot 3.0 uses Spring Security 6.0.The Spring Security team have released Spring Security 5.8 to simplify upgrading to Spring Security 6.0.Before upgrading to Spring Boot 3.0, consider upgrading your Spring Boot 2.7 application to Spring Security 5.8.The Spring Security team have produced a migration guide that will help you to do so. From there, you can follow the 5.8 to 6.0 migration guide when upgrading to Spring Boot 3.0.

Whenever Spring Boot depends on a Jakarta EE specification, Spring Boot 3.0 has upgraded to the version that is included in Jakarta EE 10.For example, Spring Boot 3.0 uses the Servlet 6.0 and JPA 3.1 specifications.

@ConstructorBinding is no longer needed at the type level on @ConfigurationProperties classes and should be removed.When a class or record has multiple constructors, it may still be used on a constructor to indicate which one should be used for property binding.

If you were relying on autowiring of a dependency into the constructor of a @ConfigurationProperties class, you must now annotate it with @Autowired to prevent it being identified as a target for property binding.

Spring Boot 2.7 introduced a new META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports file for registering auto-configurations, while maintaining backwards compatibility with registration in spring.factories.With this release, support for registering auto-configurations in spring.factories using the org.springframework.boot.autoconfigure.EnableAutoConfiguration key has been removed in favor of the imports file. Other entries in spring.factories under other keys are unaffected.

Libraries targeting both Spring Boot 3.x and 2.x can safely list their auto-configuration classes in both spring.factories and AutoConfiguration.imports. Spring Boot 2.7, which supports both locations, will de-duplicate any entries that are listed twice.

As of Spring Framework 6.0, the trailing slash matching configuration option has been deprecated and its default value set to false.This means that previously, the following controller would match both "GET /some/greeting" and "GET /some/greeting/":

Previously, the server.max-http-header-size was treated inconsistently across the four supported embedded web servers.When using Jetty, Netty, or Undertow it would configure the max HTTP request header size.When using Tomcat it would configure the max HTTP request and response header sizes.

To address this inconsistency, server.max-http-header-size has been deprecated and a replacement, server.max-http-request-header-size, has been introduced.Both properties now only apply to the request header size, irrespective of the underlying web server.

The phases used by the SmartLifecycle implementations for graceful shutdown have been updated.Graceful shutdown now begins in phase SmartLifecycle.DEFAULT_PHASE - 2048 and the web server is stopped in phase SmartLifecycle.DEFAULT_PHASE - 1024.Any SmartLifecycle implementations that were participating in graceful shutdown should be updated accordingly.

Support for Apache HttpClient has been removed in Spring Framework 6.0, immediately replaced by org.apache.httpcomponents.client5:httpclient5 (note: this dependency has a different groupId). If you are noticing issues with HTTP client behavior, it could be that RestTemplate is falling back to the JDK client. org.apache.httpcomponents:httpclient can be brought transitively by other dependencies, so your application might rely on this dependency without declaring it.

By default, only the health endpoint is now exposed over JMX, to align with the default web endpoint exposure.This can be changed by configuring the management.endpoints.jmx.exposure.include and management.endpoints.jmx.exposure.exclude properties.

Related infrastructure classes have also been renamed.For example, HttpTraceRepository is now named HttpExchangeRepository and can be found in the org.springframework.boot.actuate.web.exchanges package.

Responses from the actuator endpoints shipped with Spring Boot now use an isolated ObjectMapper instance to ensure results are consistent.If you want to revert to the old behavior and use the application ObjectMapper you can set management.endpoints.jackson.isolated-object-mapper to false.

If you have developed your own endpoints, you might want to ensure that responses implement the OperationResponseBody interface.This will ensure that the isolated ObjectMapper is considered when serializing the response as JSON.

Instead, this release opts for a more secure default.The keys-based approach has been removed in favor of a role based approach, similar to the health endpoint details.Whether unsanitized values are shown or not can be configured using the properties management.endpoint.env.show-values or management.endpoint.configprops.show-values which can have the following values:

You can also similar goals using a custom ObservationFilter - adding or removing key values for an observation.Filters do not replace the default convention and are used as a post-processing component.

We have moved the properties controlling the actuator metrics export.The old schema was management.metrics.export., the new one is management..metrics.export (Example: the prometheus properties moved from management.metrics.export.prometheus to management.prometheus.metrics.export).If you are using the spring-boot-properties-migrator, you will get notified at startup.

FlywayConfigurationCustomizer beans are now called to customize the FluentConfiguration after any Callback and JavaMigration beans have been added to the configuration.An application that defines Callback and JavaMigration beans and adds callbacks and Java migrations using a customizer may have to be updated to ensure that the intended callbacks and Java migrations are used.

Auto-configuration and dependency management for Flapdoodle embedded MongoDB has been removed.If you are using embedded MongoDB for testing, use the auto-configuration library provided by the Flapdoodle project or modify the tests to use the Testcontainers project instead of embedded MongoDB.

ReactiveElasticsearchRestClientAutoConfiguration has been renamed to ReactiveElasticsearchClientAutoConfiguration and has moved from org.springframework.boot.autoconfigure.data.elasticsearch to org.springframework.boot.autoconfigure.elasticsearch.Any auto-configuration exclusions or ordering should be updated accordingly.

The coordinates of the MySQL JDBC driver have changed from mysql:mysql-connector-java to com.mysql:mysql-connector-j. If you are using the MySQL JDBC driver, update its coordinates accordingly when upgrading to Spring Boot 3.0.

A ReactiveUserDetailsService is no longer auto-configured in the presence of an AuthenticationManagerResolver.If you application relies on ReactiveUserDetailService despite the presence of an AuthenticationManagerResolver, define your own ReactiveUserDetailsService bean that meets its needs.

Support for properties under spring.security.saml2.relyingparty.registration.id.identity-provider have been removed.Use the new properties under spring.security.saml2.relyingparty.registration.id.asserting-party as a replacement.

Running multiple batch jobs is no longer supported.If the auto-configuration detects a single job is, it will be executed on startup.If multiple jobs are found in the context, a job name to execute on startup must be supplied by the user using the spring.batch.job.name property.

As part of the previously described changes to configuring Gradle tasks, the mechanism for excluding properties from the generated build-info.properties file has also changed.Previously, properties could be excluded by setting them to null.This no longer works and has been replaced with a name-based mechanism:

The Git Commit ID Maven Plugin has been updated to version 5 where its coordinates have changed.The previous coordinates were pl.project13.maven:git-commit-id-plugin.The new coordinates are io.github.git-commit-id:git-commit-id-maven-plugin.Any declaration in your pom.xml file should be updated accordingly.

Dependency management for Apache Johnzon has been removed in favor of Eclipse Yasson.A Jakarta EE 10-compatible version of Apache Johnzon can be used with Spring Boot 3, but you will now have to specify a version in your dependency declaration.

Spring Boot does not depend on Hazelcast Hibernate so it need not have an opinion about its version.As such, dependency management for Hazelcast Hibernate has been removed.If you wish to continue using Hazelcast Hibernate, specify a version that meets your needs.Alternatively, consider using org.hibernate.orm:hibernate-jcache instead.

I have a Spring Boot project which is based on

Spring Framework 4.3.7.RELEASE and Spring Boot 1.5.2.RELEASE.

I use the Java configuration approach. How Do I upgrade this project to the latest version of Spring Boot and Spring Framework (Spring Boot 2.x, Spring Framework 5.x)? I have checked out this page, but unfortunately it was of no real help to me. Would be glad to receive any further guidance on this.

For Spring Boot 2 however it is important to note, that there is no final release yet, so you have to include the milestone or snapshot repositories from Spring Boot. You can find the URLs here: -boot/docs/2.0.0.M4/reference/htmlsingle/#getting-started-first-application-pom though that documentation is for Maven.

New releases of Spring Boot are being released on a quite frequent schedule and updating your projects to newer versions of Spring Boot is something that many teams and organizations around the globe do as part of their daily work.

3a8082e126