1. Overview
In this tutorial, we’ll learn how to migrate a Spring Boot application to version 3.0. To successfully migrate an application to Spring Boot 3, we have to ensure that its current Spring Boot version is 2.7, and its Java version is 17.
2. Core Changes
Spring Boot 3.0 marks a major milestone for the framework, bringing several important modifications to its core components.
2.1. Configuration Properties
Some property keys have been modified:
- spring.redis has moved to spring.data.redis
- spring.data.cassandra has moved to spring.cassandra
- spring.jpa.hibernate.use-new-id-generator is removed
- server.max.http.header.size has moved to server.max-http-request-header-size
- spring.security.saml2.relyingparty.registration.{id}.identity-provider support is removed
To identify those properties, we can add the spring-boot-properties-migrator in our pom.xml:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-properties-migrator</artifactId>
<scope>runtime</scope>
</dependency>
The latest version of spring-boot-properties-migrator is available from Maven Central.
This dependency generates a report, printed at start-up time, of deprecated property names, and temporarily migrates the properties at runtime.
2.2. Jakarta EE 10
The new version of Jakarta EE 10 brings updates to the related dependencies of Spring Boot 3:
- Servlet specification updated to version 6.0
- JPA specification updated to version 3.1
So if we’re managing those dependencies by excluding them from the spring-boot-starter dependency, we should make sure to update them.
Let’s start by updating the JPA dependency:
<dependency>
<groupId>jakarta.persistence</groupId>
<artifactId>jakarta.persistence-api</artifactId>
<version>3.1.0</version>
</dependency>
The latest version of jakarta.persistence-api is available from Maven Central.
Next, let’s update the Servlet dependency:
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>6.0.0</version>
</dependency>
The latest version of jakarta.servlet-api is available from Maven Central.
*In addition to changes in the dependency coordinates, Jakarta EE now uses “jakarta” packages instead of “javax.”* So after we update our dependencies, we may need to update import statements.
2.3. Hibernate
If we’re managing the Hibernate dependency by excluding it from the spring-boot-starter dependency, it’s important to make sure to update it:
<dependency>
<groupId>org.hibernate.orm</groupId>
<artifactId>hibernate-core</artifactId>
<version>6.1.4.Final</version>
</dependency>
The latest version of hibernate-core is available from Maven Central.
2.4. Other Changes
In addition, there are also other significant changes at the core level included in this release:
- Image banner supports removed: To define a custom banner, only the banner.txt file is considered a valid file.
- Logging date formatter: The new default date format for Logback and Log4J2 is yyyy-MM-dd’T’HH:mm:ss.SSSXXX
If we want to restore the old default format, we need to set the value of the property logging.pattern.dateformat on application.yaml to the old value. - @ConstructorBinding only at the constructor level: It’s no longer necessary to have @ConstructorBinding at the type level for @ConfigurationProperties classes, and it should be removed.
However, if a class or record has multiple constructors, we must utilise @ConstructorBinding on the desired constructor to specify which one will be used for property binding.
3. Web Application Changes
Initially, assuming that our application is a web application, we should consider certain changes.
3.1. Trailing Slash Matching Configuration
The new Spring Boot release deprecates the option to configure trailing slash matching, and sets its default value to false.
For instance, let’s define a controller with one simple GET endpoint:
@RestController
@RequestMapping("/api/v1/todos")
@RequiredArgsConstructor
public class TodosController {
@GetMapping("/name")
public List<String> findAllName(){
return List.of("Hello","World");
}
}
Now the “*GET /api/v1/todos/name/*” doesn’t match anymore by default, and will result in an HTTP 404 error.
We can enable the trailing slash matching for all the endpoints by defining a new configuration class that implements WebMvcConfigurer or WebFluxConfigurer (in case it’s a reactive service):
public class WebConfiguration implements WebMvcConfigurer {
@Override
public void configurePathMatch(PathMatchConfigurer configurer) {
configurer.setUseTrailingSlashMatch(true);
}
}
3.2. Response Header Size
As we already mentioned, the property server.max.http.header.size is deprecated in favour of server.max-http-request-header-size, which checks only the size of the request header. To also define a limit for the response header, we’ll define a new bean:
@Configuration
public class ServerConfiguration implements WebServerFactoryCustomizer<TomcatServletWebServerFactory> {
@Override
public void customize(TomcatServletWebServerFactory factory) {
factory.addConnectorCustomizers(new TomcatConnectorCustomizer() {
@Override
public void customize(Connector connector) {
connector.setProperty("maxHttpResponseHeaderSize", "100000");
}
});
}
}
If we’re using Jetty instead of Tomcat, we should change TomcatServletWebServerFactory to JettyServletWebServerFactory. It’s important to note that the other embedded web containers don’t support this feature.
3.3. Other Changes
There are also other significant changes at the web application level in this release:
- Phases on graceful shutdown: the SmartLifecycle implementations for graceful shutdown have updated the phases. Spring now initiates graceful shutdown in the phase SmartLifecycle.DEFAULT_PHASE – 2048 and stops the web server in the phase SmartLifecycle.DEFAULT_PHASE – 1024.
- HttpClient upgrade on RestTemplate: Rest Template updates its version of Apache HttpClient5
4. Actuator Changes
Some significant changes have been introduced in the Actuator module.
4.1. Actuator Endpoints Sanitization
In previous versions, Spring Framework automatically masks the values for sensitive keys on the endpoints /env and /configprops, which display sensitive information such as configuration properties and environment variables. In this release, Spring changes the approach to be more secure by default.
Instead of only masking certain keys, it now masks the values for all keys by default. We can change this configuration by setting the properties management.endpoint.env.show-values (for the /env endpoint) or management.endpoint.configprops.show-values (for the /configprops endpoint) with one of these values:
- NEVER: no values shown
- ALWAYS: all the values shown
- WHEN_AUTHORIZED: all the values are shown if the user is authorized. For JMX, all the users are authorized. For HTTP, only a specific role can access the data.
4.2. Other Change
Other relevant updates have occurred on the Spring Actuator Module:
- Jmx Endpoint Exposure: JMX handles only the health endpoint. By configuring the properties management.endpoints.jmx.exposure.include and management.endpoints.jmx.exposure.exclude, we can customize it.
- httptrace endpoint renamed: this release renamed the “*/httptrace” endpoint to “/httpexchanges*“
- Isolated ObjectMapper: this release now isolates the ObjectMapper instance responsible for serializing the responses of the actuator endpoint. We may change this feature by setting the management.endpoints.jackson.isolated-object-mapper property to false.
5. Spring Security
**Spring Boot 3 is only compatible with Spring Security 6.
**
Before upgrading to Spring Boot 3.0, we should first upgrade our Spring Boot 2.7 application to Spring Security 5.8. Afterwards, we can upgrade Spring Security to version 6 and Spring Boot 3.
A few important changes have been introduced in this version:
- ReactiveUserDetailsService not autoconfigured: in the presence of an AuthenticationManagerResolver, a ReactiveUserDetailsService is no longer autoconfigured.
- SAML2 Relying Party Configuration: we previously mentioned that the new version of Spring boot no longer supports properties located under spring.security.saml2.relyingparty.registration.{id}.identity-provider. Instead, we should use the new properties under spring.security.saml2.relyingparty.registration.{id}.asserting-party.
6. Spring Batch
Now let’s see some significant changes introduced in the Spring Batch module.
6.1. @EnableBatchProcessing Discouraged
Previously, we could enable Spring Batch’s auto-configuration, annotating a configuration class with @EnableBatchProcessing. The new release of Spring Boot discourages the usage of this annotation if we want to use autoconfiguration.
In fact, using this annotation (or defining a bean that implements DefaultBatchConfiguration) tells the autoconfiguration to back off.
6.2. Running Multiple Jobs
Previously, it was possible to run multiple batch jobs at the same time using Spring Batch. However, this is no longer the case. If the auto-configuration detects a single job, it will be executed automatically when the application starts.
So if multiple jobs are present in the context, we’ll need to specify which job should be executed on startup by providing the name of the job using the spring.batch.job.name property. Thus, if we want to run multiple jobs, we have to create a separate application for each job.
Alternatively, we can use a scheduler like Quartz, Spring Scheduler, or other alternatives for scheduling the jobs.
7. Conclusion
In this article, we learned how to migrate a 2.7 Spring Boot app to version 3, focusing on the core components of the Spring environment. Some changes have also occurred in other modules, like Spring Session, Micrometer, Dependency management, etc.
As always, the complete source code of the examples can be found over on GitHub.