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.

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. HttpClient Changes

Spring Boot 3 upgrades its internal HTTP stack to use Apache HttpClient 5.x instead of the older 4.x version. As a result, applications that customize HTTP clients, especially through RestTemplate and HttpComponentsClientHttpRequestFactory, need to update their configuration.

This transition introduces breaking changes to several commonly used patterns and brings a more modern API design, particularly in HttpClient 5.4 and later, with builder-based configuration and a stronger alignment to Java’s standard security APIs.

7.1. Legacy Configuration Using HttpClient 4.x

Before the upgrade, a typical configuration might look like this:

@Configuration
public class RestTemplateConfiguration {
    @Bean
    public RestTemplate getRestTemplate() {
        CloseableHttpClient httpClient = HttpClients.custom().build();

        HttpComponentsClientHttpRequestFactory requestFactory = new HttpComponentsClientHttpRequestFactory();
        requestFactory.setHttpClient(httpClient);
        requestFactory.setConnectTimeout(30000);
        requestFactory.setReadTimeout(30000);
        requestFactory.setConnectionRequestTimeout(30000);

        return new RestTemplate(requestFactory);
    }
}

However, after upgrading to Spring Boot 3, this approach breaks due to incompatibilities with Apache HttpClient 5.

7.2. Why This Breaks in Spring Boot 3

Custom HTTP configurations built on Apache HttpClient 4.x are no longer compatible with Spring Boot 3, which now relies on HttpClient 5.x. This upgrade introduces breaking API changes and a restructured package hierarchy.

Some key incompatibilities include:

• HttpComponentsClientHttpRequestFactory now expects a 5.x CloseableHttpClient, not a 4.x version.
• Timeout methods, such as setConnectTimeout() and setReadTimeout(), are deprecated or silently ignored.
• Runtime issues such as NoSuchMethodError, ClassNotFoundException, or incompatibilities with org.apache.http.* classes.

These problems occur because the underlying APIs have been redesigned and not just refactored. For instance, most classes have moved from the org.apache.http.* namespace (used in 4.x) to org.apache.hc.* in 5.x, and the configuration model has shifted toward builder-style patterns and core Java SSL concepts.

To ensure compatibility, we must update dependencies and refactor HTTP client configurations to match HttpClient 5.x’s redesigned API patterns.

7.3. Migrating to HttpClient 5.x (Before 5.4)

For versions before 5.4, the following configuration works:

@Configuration
public class RestTemplateConfiguration {
    @Bean
    public RestTemplate restTemplate() {
        RequestConfig config = RequestConfig.custom()
          .setConnectTimeout(Timeout.ofSeconds(30))
          .setResponseTimeout(Timeout.ofSeconds(30))
          .setConnectionRequestTimeout(Timeout.ofSeconds(30))
          .build();
        CloseableHttpClient client = HttpClients.custom()
          .setDefaultRequestConfig(config)
          .build();
        return new RestTemplate(new HttpComponentsClientHttpRequestFactory(client));
    }
}

<dependency>
    <groupId>org.apache.httpcomponents.client5</groupId>
    <artifactId>httpclient5</artifactId>
</dependency>

7.4. Migrating to HttpClient 5.4 and Later

Starting with HttpClient 5.4, Apache introduced a more modern and modular configuration model. This update aligns more closely with Java’s platform APIs and moves away from deprecated or removed methods such as setConnectTimeout() and setSSLHostnameVerifier(). Instead, client configuration now relies on builder-based APIs, offering better separation of concerns and clearer semantics around connection pooling, timeout settings, and extensibility.

Let’s walk through a practical example that demonstrates how to configure a RestTemplate using HttpClient 5.4+:

@Configuration
public class RestTemplateConfiguration {
    @Bean
    public RestTemplate restTemplate() {
        try {
            // Timeout configurations
            SocketConfig socketConfig = SocketConfig.custom()
              .setSoTimeout(Timeout.ofSeconds(30))  // Read timeout
              .build();

            ConnectionConfig connectionConfig = ConnectionConfig.custom()
              .setConnectTimeout(Timeout.ofSeconds(30))  // Connect timeout
              .build();

            RequestConfig requestConfig = RequestConfig.custom()
              .setConnectionRequestTimeout(Timeout.ofSeconds(30))  // Pool wait timeout
              .build();

            // Connection pool configuration
            PoolingHttpClientConnectionManager connectionManager =
              PoolingHttpClientConnectionManagerBuilder.create()
                .setMaxConnPerRoute(20)
                .setMaxConnTotal(100)
                .setDefaultSocketConfig(socketConfig)
                .setDefaultConnectionConfig(connectionConfig)
                .build();

            CloseableHttpClient httpClient = HttpClients.custom()
              .setConnectionManager(connectionManager)
              .setDefaultRequestConfig(requestConfig)
              .build();

            return new RestTemplate(new HttpComponentsClientHttpRequestFactory(httpClient));
        } catch (Exception e) {
            throw new IllegalStateException("Failed to configure RestTemplate", e);
        }
    }
}

By migrating to this updated configuration model, our application becomes fully compatible with Spring Boot 3 and benefits from the improved modularity, clarity, and security features introduced in HttpClient 5.4 and beyond.

8. 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.