Migrate Application From Spring Boot 2 to Spring Boot 3

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.