Spring Boot 3.0 Migration Guide

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide

3 revision 기준으로 작성됨

이 문서는 application을 Spring Boot 3.0으로 migration 하는데 도움을 주기 위한 것입니다.

Before You Start

Upgrade to the Lastest 2.7.x Version

upgrade를 시작하기 전에 사용 가능한 최신 2.7.x 버전으로 upgrade 해야 합니다.
이렇게 하면 해당 라인의 최신 dependency에 대해 빌드하고 있는지 확인할 수 있습니다.

Review Dependencies

Spring Boot 3으로 이동하면 많은 dependency가 upgrade 되며 사용자 측에서 작업이 필요할 수 있습니다.
3.0.x 용 dependency management와 함께 2.7.x 용 dependency management를 관리하여 프로젝트가 어떻게 영향을 받는지 평가할 수 있습니다.

Spring Boot에서 관리하지 않는 dependency (ex: Spring Cloud)를 사용할 수도 있습니다.
프로젝트에서 이에 대한 명시적 버전을 정의하므로 upgrade하기 전에 먼저 호환 가능한 버전을 식별해야 합니다.

Review System Requirements

Spring Boot 3.0에는 Java 17 이상이 필요합니다.
Java 8은 더 이상 지원되지 않습니다.
또한 Spring Framework 6.0이 필요합니다.

Review Deprecations from Spring Boot 2.x

Spring Boot 2.x에서 더 이상 사용되지 않는 class, method 및 property 들은 이 release에서 제거되었습니다.
upgrade 하기 전에 더 이상 사용되지 않는 method를 호출하고 있지 않은지 확인하십시오.

Upgrade to Spring Boot 3

프로젝트의 상태와 해당 dependency를 검토한 후 Spring Boot 3.0의 최신 maintenance release로 upgrade 해야 합니다.

Configuration Properties Migration

Spring Boot 3.0에서는 몇 가지 configuration property들이 이름이 바뀌거나 제거되었으며 개발자는 그에 따라 application.properties/application.yml 을 update 해야 합니다.
이를 돕기 위해 Spring Boot는 spring-boot-properties-migrator module을 제공합니다.
프로젝트에 dependency가 추가되면 application의 환경을 분석하고 진단을 print 할 뿐만 아니라 runtime에 property 들을 일시적으로 migration 합니다.

Maven pom.xml 에 다음을 추가하여 migrator를 추가할 수 있습니다 :

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-properties-migrator</artifactId>
    <scope>runtime</scope>
</dependency>

또는 Gradle을 사용하는 경우 :

runtime("org.springframework.boot:spring-boot-properties-migrator")

Note	migration이 완료되면 프로젝트의 dependency에서 이 module을 제거해야 합니다.

Spring Framework 6.0

Spring Boot 3.0은 Spring Framework 6.0이 필요합니다.
계속하기 전에 upgrade guide를 검토할 수 있습니다.

Jakarta EE

Spring Boot가 Jakarta EE 사양에 의존할 때마다 Spring Boot 3.0은 Jakarta EE 10에 포함된 버전으로 upgrade 되었습니다.
예를 들어 Spring Boot 3.0은 Servlet 6.0 및 JPA 3.1 사양을 사용합니다.

자체적으로 dependency를 관리하고 있으며 starter POM에 의존하지 않는 경우 Maven 또는 Gradle 파일을 적절하게 update 했는지 확인해야 합니다.
이전 Java EE dependency가 더 이상 빌드에서 직접 또는 전이적으로 사용되지 않도록 특히 주의해야 합니다.
예를 들어 항상 javax.servlet:javax.servlet-api 이 아닌 jakarta.servlet:jakarta.servlet-api 를 사용해야 하는 경우입니다.

dependency 조정 변경 뿐만 아니라 Jakarta EE는 이제 javax 가 아닌 jakarta package를 사용합니다.
dependency 항목을 update 하면 프로젝트의 import 문을 update 해야 할 수 있습니다.

다음을 포함하여 migration에 도움이 되는 여러 가지 도구가 있습니다 :

• OpenRewrite recipes.
• The Spring Boot Migrator project.
• Migration support in IntelliJ IDEA.

Core Changes

대부분의 application과 관련된 Spring Boot의 core에 몇 가지 변경 사항이 적용되었습니다.

Image Banner Support Removed

Image-based application banner에 대한 지원이 제거되었습니다.
banner.gif, banner.jpg 및 banner.png 파일은 이제 무시되며 text-based banner.txt file로 대체되어야 합니다.

Logging Date Format

Logback 및 Log4j2에 대한 log message의 date 및 time component에 대한 default format이 ISO-8601 표준에 맞게 변경되었습니다.
새로운 default format yyyy-MM-dd'T'HH:mm:ss.SSSXXX 는 T 를 사용하여 공백 문자 대신 날짜와 시간을 구분하고 표준 시간대 offset을 끝에 추가합니다.
LOG\_DATEFORMAT_PATTERN environment variable 또는 logging.pattern.dateformat property를 사용하여 yyyy-MM-dd HH:mm:ss.SSS 의 이전 default value를 복원할 수 있습니다.

@ConstructingBinding No Longer Needed at the Type Level

@ConstructorBinding 은 class의 type level에서 더 이상 필요하지 않으므로 제거해야 합니다.
class 또는 record에 여러 constructor가 있는 경우 property binding에 사용해야 하는 constructor를 나타내기 위해 여전히 constructor에서 사용할 수 있습니다.

YamlJsonParser Has Been Removed

SnakeYAML의 JSON parsing이 다른 parser 구현과 일치하지 않아 YamlJsonParser 가 제거되었습니다.
드문 경우지만 YamlJsonParser 를 직접 사용하고 있다면 다른 JsonParser 구현 중 하나로 migration하십시오.

Auto-configuration Files

Spring Boot 2.7은 auto-configuration 등록을 위한 새로운 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.import file을 도입하면서 spring.factories 의 등록과 하위 호환성을 유지합니다.
이 release에서는 import file을 위해 spring.factories auto-configuration 등록 지원이 제거되었습니다.

Web Application Changes

web application을 upgrade 해야 하는 경우 다음 section을 검토해야 합니다.

Spring MVC and WebFlux URL Matching Changes

Spring Framework 6.0 부터 trailing slash matching (후행 슬래시 일치) configuration option은 더 이상 사용되지 않으며 default value는 false 로 설정됩니다.
이는 이전에 다음 controller가 "GET /some/greeting" 및 "GET /some/greeting/" 모두와 일치함을 의미합니다 :

@RestController
public class MyController {
    @GetMapping("/some/greeting")
    public String greeting {
        return "Hello";
    }
}

이번 Spring Framework 변경으로 "GET /some/greeting/"은 기본적으로 더 이상 일치하지 않습니다.

개발자들은 대신에 proxy, Servlet/web filter를 통해 명시적인 redirects/rewrites를 구성하거나 심지어 더 대상이 되는 경우를 위해 controller handler에 명시적으로 추가 경로 (예: @GetMapping("/some/greeting", "/some/greeting/")를 선언해야 합니다.

application이 이 변경 사항에 완전히 적응할 때까지 다음 전역 구성으로 기본 값을 변경할 수 있습니다.

@Configuration
public class WebConfiguration implements WebMvcConfigurer {
    @Override
    public void configurePathMatch(PathMatchConfigurer configurer) {
        configurer.setUseTrailingSlashMatch(true);
    }
}

'server.max-http-header-size'

이전에는 지원되는 embedded web server 4개에서 server.max-http-header-size 가 일관되지 않게 처리되었습니다.
Jetty, Netty 또는 Undertow를 사용하는 경우 max HTTP request header size를 구성 합니다.
Tomcat을 사용할 때 max HTTP request 및 response header size를 구성합니다.

이러한 불일치를 해결하기 위해 server.max-http-header-size 는 더 이상 사용되지 않으며 대체품인 server.max-http-request-header-size 가 도입되었습니다.
이제 두 property 모두 기본 web server에 관계없이 request header size에만 적용됩니다.

Tomcat 또는 Jetty (이러한 설정을 지원하는 유일한 두 서버)에서 HTTP response의 max header size를 제한하려면 WebServerFactoryCustomizer 를 사용하세요.

Updated Phases for Graceful Shutdown

정상적인 shutdown을 위해 SmartLifecycle 구현에서 사용하는 단계가 update 되었습니다.
정상적인 shutdown는 이제 SmartLifecycle.DEFAULT\_PHASE - 2048 단계에서 시작되고 web server는 SmartLifecycle.DEFAULT\_PHASE - 1024 단계에서 중지됩니다.
단계적 종료에 참여했던 모든 SmartLifecycle 구현은 그에 따라 update되어야 합니다.

Jetty

Jetty는 아직 Servlet 6.0을 지원하지 않습니다.
spring Boot 3.0에서 Jetty를 사용하려면 Servet API를 5.0으로 downgrade 해야 합니다.
jakarta-servlet.version property를 사용하여 그렇게 할 수 있습니다.

Actuator Changes

Spring Boot의 actuator module을 사용하는 경우 다음 update를 숙지해야 합니다.

JMX Endpoint Exposure

기본적으로 health endpoint만 JMX를 통해 노출되어 기본 web endpoint exposure와 일치합니다.
이는 management.endpoints.jmx.exposure.include 및 management.endpoints.jmx.exposure.exclude property를 구성하여 변경할 수 있습니다.

'httptrace' Endpoint Renamed to 'httpexchanges'

httptrace endpoint 및 관련 infrastructure는 최근 HTTP request-reponse exchange에 대한 정보를 기록하고 access를 제공합니다.
Micrometer Tracing에 대한 지원이 도입된 후 httptrace 라는 이름이 혼동을 일으킬 수 있습니다.
이 혼동을 줄이기 위해 endpoint 이름이 httpexchanges 로 변경되었습니다.
endpoint의 response contents도 이 remaning의 영향을 받았습니다.
자세한 내용은 Actuator API documentation을 참조하세요.

관련 infrastructure class의 이름도 변경되었습니다.
예를 들어 HttpTraceRrepository 는 이제 HttpExchangeRepository 라는 이름이 지정되었으며 org.springframework.boot.actuatte.web.exchanges package 에서 찾을 수 있습니다.

Actuator JSON

Spring Boot와 함께 제공되는 actuator endpoint의 response는 이제 isolated ObjectMapper instance를 사용하여 결과의 일관성을 보장합니다.
이전 동작으로 되돌리고 application ObjectMapper 를 사용하려면 management.endpoints.jackson.isolated-object-mapper 를 false 로 설정할 수 있습니다.
고유한 endpoint를 개발한 경우 response가 OperationResponseBody interface를 구현하는지 확인할 수 있습니다.
이렇게 하면 reponse를 JSON으로 serializing할 때 isolated ObjectMapper 가 고려됩니다.

Actuator Endpoints Sanitization

/env 및 /configprops endpoint에는 중요한 값이 포함될 수 있으므로 모든 값은 기본적으로 항상 masking 됩니다.
이전에는 민감한 것으로 간주되는 key의 경우에만 사용되었습니다.

대신 이 release에서 보다 안전한 default를 선택합니다.
health endpoint 세부 정보와 유사한 role based 접근 방식을 위해 key based 접근 방식이 제거되었습니다.
삭제되지 않은 값이 표시되는지 여부는 다음 값을 가질 수 있는 property를 사용하여 구성할 수 있습니다.

• NEVER - 모든 값은 삭제됩니다.
• ALWAYS - 모든 값이 출력에 표시됩니다. (삭제 기능이 적용됨).
• WHEN_AUTHORIZED - 값은 사용자가 인증된 경우에만 출력에 표시됩니다. (삭제 기능이 적용됨)

JMX의 경우 사용자는 항상 인증된 것으로 간주됩니다.
HTTP의 경우 사용자가 인증되고 지정된 역할이 있으면 권한이 부여된 것으로 간주됩니다.

QuartzEndpoint에 대한 삭제도 같은 방식으로 구성할 수 있습니다.

Micrometer and Metrics Changes

Spring Boot 3.0은 Micrometer 1.10을 기반으로 합니다.
application이 metric을 수집하고 내보내는 경우 다음 변경 사항을 알고 있어야 합니다.

Deprecation of the Spring Boot 2.x instrumentation

Observation 지원과의 통합으로 인해 이제 이전 instrumentation을 더 이상 사용하지 않습니다.
actual instrumentation을 수행하는 filter, interceptor는 전체 bug class를 해결할 수 없고 duplicate instrumentation의 위험이 너무 높기 때문에 완전히 제거되었습니다.
예를 들어 WebMvcMetricsFilter 는 완전히 삭제되었으며 효과적으로 Spring Framework의 ServerHttpObservationFilter 로 대체되었습니다.
해당 *TagProvider , *TagContributor 및 *Tags class는 더 이상 사용되지 않습니다.
더 이상 observation instrumentation에서 기본적으로 사용되지 않습니다.
개발자가 기존 infrastructure를 새 infrastructure로 migration 할 수 있도록 지원 중단 단계 동안 유지하고 있습니다.

Tag providers and contributors migration

application이 metric을 customizing 하는 경우 codebase에서 새로운 지원 중단을 볼 수 있습니다.
새 모델에서는 tag provider와 contributor가 observation convention으로 대체됩니다.
Spring 2.x에서 Spring MVC "http.server.requests" metric instrumentation 지원의 예를 들어보겠습니다.

TagContributor 를 사용하여 추가 Tag 를 제공하거나 TagProvider 를 부분적으로만 재정의하는 경우 요구 사항에 맞게 DefaultServerRequestObservationConvention 을 확장해야 합니다 :

public class ExtendedServerRequestObservationConvention extends DefaultServerRequestObservationConvention {
    @Override
    public KeyValues getLowCardinalityKeyValues(ServerRequestObservationContext context) {
        // here, we just want to have an additional KeyValue to the observation, keeping the default values
        return super.getLowCardinalityKeyValues(context).and(custom(context));
    }

    protected KeyValue custom(ServerRequestObservationContext context) {
        return KeyValue.of("custom.method", context.getCarrier().getMethod());
    }
}

metric Tags 를 크게 변경하는 경우 WebMvcTagsProvider 를 custom 구현으로 대체하고 bean으로 contributing 할 수 있습니다.
이 경우 관심있는 observation에 대한 convention을 구현해야 할 것입니다.
여기서는 ServerRequestObservationConvention 을 구현합니다.
ServerRequestObservationContext 을 사용하여 현재 request에 대한 정보를 추출합니다.

그런 다음 요구 사항을 염두에 두고 method를 구현할 수 있습니다.

public class CustomServerRequestObservationConvention implements ServerRequestObservationContext {
    @Override
    public String getName() {
        // will be used for the metric name
        return "http.server.requests";
    }

    @Override
    public String getContextualName(ServerRequestObservationContext context) {
        // will be used for the trace name
        return "http " + context.getCarrier().getMethod().toLowerCase();
    }

    @Override
    public KeyValues getLowCardinalityKeyValues(ServerRequestObservationContext context) {
        return KeyValues.of(method(context), status(context), exception(context));
    }

    @Override
    public KeyValues getHighCardinalityKeyValues(ServerRequestObservationContext context) {
        return KeyValues.of(httpUrl(context));
    }

    protected KeyValue method(ServerRequestObservationContext context) {
        // You should reuse as much as possible the corresponding ObservationDocumentation for key names
        return KeyValue.of(ServerHttpObservationDocumentation.LowCardinalityKeyNames.METHOD, context.getCarrier().getMethod());
    }

    //...

}

두 경우 모두 application context에 bean으로 contribute할 수 있으며 auto-configuration에 의해 선택되어 기본 구성을 효과적으로 대체합니다.

@Configuration
public class CustomMvcObservationConfiguration {
    @Bean
    public ExtendedServerRequestObservationConvention extendedServerRequestObservationConvention() {
        return new ExtendedServerRequestObservationConvention();
    }
}

custom ObservationFilter 를 사용하여 observation에 대한 key value를 추가하거나 제거하는 유사한 목표를 수행할 수도 있습니다.
filter는 default convention을 대체하지 않으며 post-processing component로 사용됩니다.

public class ServerRequestObservationFilter implements ObservationFilter {

    @Override
    public Observation.Context map(Observation.Context context) {
        if (context instanceof ServerRequestObservationContext serverContext) {
            context.addLowCardinalityKeyValue(KeyValue.of("project", "spring"));
            String customAttribute = (String) serverContext.getCarrier().getAttribute("customAttribute");
            context.addLowCardinalityKeyValue(KeyValue.of("custom.attribute", customAttribute));
        }
        return context;
    }
}

ObservationFilter bean을 사용하여 application에 contribute 할 수 있으며 Spring Boot는 ObservationRegistry 로 auto-configure 합니다.

Auto-configuration of Micrometer's JvmInfoMetrics

Micrometer의 JvmInfoMetrics 는 이제 auto-configure 됩니다.
수동으로 구성된 JvmInfoMetrics bean 정의는 제거할 수 있습니다.

Micrometer binders

Micrometer team은 binder를 micrometer-binders 라는 별도의 micrometer module로 옮겼습니다.
split package를 방지하기 위해 import도 변경되었습니다.
이전 binder를 사용하는 경우 io.micrometer.core.instrument.binder 에서 io.micrometer.binder 로 import를 조정하세요.

Actuator Metrics Export Properties

actuator metrics export를 제어하는 property들을 이동했습니다.
이전 schema는 management.metrics.export 였습니다.
<product> , 새 항목은 management.<product>.metrics.export 입니다. (예: prometheus property가 management.metrics.export.prometheus 에서 management.prometheus.metrics.export 로 이동 됨)
spring-boot-properties-migrator 를 사용하는 경우 시작 시 알림을 받습니다.

자세한 내용은 issue #30381을 참고하세요.

Mongo Health Check

MongoDB 용 HealthIndicator 는 이제 MongoDB의 안정적은 API를 지원합니다.
buildInfo query가 isMaster 로 대체되었으며 이제 response에 version 대신 maxWireVersion 이 포함됩니다.
MongoDB documentation에 설명된 대로 client는 maxWireVersion 을 사용하여 MongoDB와의 호환성을 협상할 수 있습니다.
maxWireVersion 은 integer입니다.

Data Access Changes

application이 data로 작업하는 경우 다음 변경 사항을 검토해야 합니다.

Changes to Data properties

spring.data 접두사는 Spring Data용으로 예약되었으며 접두사 아래의 모든 property는 classpath에 Spring Data가 필요함을 의미합니다.

Cassandra Properties

Cassandra의 configuration property들이 spring.data.cassandra. 에서 spring.cassandra. 로 이동되었습니다.

Redis Properties

Redis의 configuration property들이 spring.redis. 에서 spring.data.redis. 으로 이동되었습니다.
Spring Data가 classpath에 있어야 합니다.

Flyway

Spring Boot 3.0은 기본적으로 Flyway 9.0을 사용합니다.
이것이 application에 어떤 영향을 미칠 수 있는지 알아보려면 Flyway release note 및 blog post를 참조하세요.

FlywayConfigurationCustomizer bean은 이제 Callback 및 JavaMigration bean이 configuration에 추가된 후 FluentConfiguration 을 customzie하기 위해 호출됩니다.
Callback 및 JavaMigration Bean을 정의하고 customizer를 사용하여 callback 및 Java migration을 추가하는 application은 의도한 callback 및 Java migration이 사용되도록 업데이트해야 할 수 있습니다.

Hibernate 6.1

Spring Boot 3.0은 기본적으로 Hibernate 6.1을 사용합니다.
이것이 application에 어떤 영향을 미칠 수 있는지 알아보려면 Hibernate 6.0 및 6.1 migration guide를 참조하세요.

dependency management 및 spring-boot-starter-data-jpa starter는 Hibernate dependency에 대해 새로운 org.hibernate.orm group ID를 사용하도록 update되었습니다.
Hibernate가 더 이상 이전 ID generator-mapping으로 다시 전환하는 것을 지원하지 않으므로 spring.jpa.hibernate.use-new-id-generator-mappings configuration property가 제거되었습니다.

Embedded MongoDB

Flapdoodle embedded MongoDB에 대한 auto-configuration 및 dependency management가 제거되었습니다.
테스트를 위해 embedded MongoDB를 사용하는 경우 Flapdoodle project에서 제공하는auto-configuration library를 사용하거나 embedded MongoDB 대신 Testcontainers project를 사용하도록 테스트를 수정하세요.

R2DBC 1.0

Spring Boot 3.0은 기본적으로 R2DBC 1.0을 사용합니다.
1.0 release에서 R2DBC는 더 이상 Spring Boot의 dependency management에 영향을 준 bill of materials (bom)을 publish 하지 않습니다.
r2dbc-bom.version 은 더 이상 R2DBC의 버전을 재정의하는데 사용할 수 없습니다.
그 자리에 이제 개별 및 별도로 버전이 지정된 module에 대한 몇가지 새로운 property 들을 사용할 수 있습니다.

• oracle-r2dbc.version (com.oracle.database.r2dbc:oracle-r2dbc)
• r2dbc-h2.version (io.r2dc:r2dbc-h2)
• r2dbc-pool.version (io.r2dc:r2dbc-pool)
• r2dbc-postgres.version (io.r2dc:r2dbc-postgres)
• r2dbc-proxy.version (io.r2dc:r2dbc-proxy)
• r2dbc-spi.version (io.r2dc:r2dbc-spi)

Elasticsearch Clients and Templates

Elasticsearch의 high-level RestClient에 대한 지원이 제거되었습니다.
대신 Elasticsearch의 새로운 Java client에 대한 auto-configuration이 도입되었습니다.
마찬가지로 high-level Rest client위에 구축된 Spring Data Elasticsearch template에 대한 지원이 제거되었습니다.
대신 새 Java client를 기반으로 하는 새 template에 대한 auto-configuration이 도입되었습니다.
자세한 내용은 reference documentation의 Elasticsearch section을 참조하세요.

ReactiveElasticsearchRestClientAutoConfiguration 이 ReactiveElasticsearchClientAutoConfiguration 으로 이름이 바뀌었고 org.springframework.boot.autoconfigure.data.elasticsearch 에서 org.springframework.boot.autoconfigure.elasticsearch 로 이동했습니다.
모든 auto-configuration exclusion 또는 ordering은 그에 따라 update 되어야 합니다.

Spring Security Changes

Spring Boot 3.0이 Spring Security 6.0으로 upgrade되었습니다.
다음 section과 함께 Spring Security 6.0 migration guide를 검토하세요.

ReactiveUserDetailService

ReactiveUserDetailsService 는 더 이상 AuthenticationManagerResolver 가 있는 경우 auto-configure 되지 않습니다.
application이 AuthenticationManagerResolver 의 존재에도 불구하고 ReactiveUserDetailsService 에 의존하는 경우 필요에 맞는 자체 ReactiveUserDetailsService bean을 정의하세요.

SAML2 Relying Party Configuration

spring.security.saml2.relyingparty.registration.{id}.identity-provider 하위 property들에 대한 지원이 제거 되었습니다.
spring.security.saml2.relyingparty.registration.{id}.asserting-party 하위 property들을 대신 사용하세요.

Spring Batch Changes

Spring Batch 사용자의 경우 다음 update가 관련됩니다.

@EnableBatchProcessing No Longer Required

이전에는 @EnableBatchProcessing 을 사용하여 Spring Boot의 Spring Batch auto-configuration을 활성화 할 수 있었습니다.
더 이상 필요하지 않으며 Boot의 auto-configuration을 사용하려는 application에서 제거해야 합니다.
@EnableBatchProcessing annotation이 달린 bean 또는 Batch의 DefaultBatchConfiguration 을 확장하는 bean은 이제 auto-configuration이 back off 하도록 지시하여 application이 Batch configuration 방식을 완전히 제어할 수 있도록 정의할 수 있습니다.

Multiple Batch Jobs

여러 batch job 실행은 더 이상 지원되지 않습니다.
auto-configuration이 단일 작업을 감지하면 시작 시 실행됩니다.
context에서 여러 job이 발견되면 사용자가 spring.batch.job.name property를 사용하여 시작 시 실행할 job name을 제공해야 합니다.

Spring Session Changes

다음 section은 Spring Session 사용자와 관련이 있습니다.

Spring Session Store Type

spring.session.store-type 을 통해 Spring session에 대한 store type을 명시적으로 구성하는 것은 더 이상 지원되지 않습니다.
classpath에서 여러 session store repository 구현이 감지되는 경우 auto-configure 해야 하는 SessionRepository 를 결정하는 데 fixed order가 사용됩니다.
Spring Boot의 정의된 순서가 요구 사항을 충족하지 않는 경우 고유한 SessionRepository bean을 정의하고 auto-configuration을 back off 할 수 있습니다.

Gradle Changes

Gradle로 Spring Boot project를 빌드하는 사용자는 다음 section을 검토해야 합니다.

Simplified Main Class Name Resolution With Gradle

Gradle을 사용하여 application을 build할 때 application의 main class name 확인이 단순화되고 일관되게 되었습니다.
bootJar , bootRun 및 bootWar 는 이제 모두 main source set의 출력에서 찾아 main class name의 name을 확인합니다.
이렇게 하면 task가 기본적으로 동일한 main class name을 사용하지 않았을 수 있는 작은 위험이 제거됩니다.
main source set의 output에서 해결되는 main class에 의존하는 경우 springBoot DSL의 mainClass property를 사용하여 main class name을 구성하도록 Gradle configuration을 update합니다.

springBoot {
    mainClass = "com.example.Application"
}

또는 main source set의 output directory 이외의 위치에서 검색하도록 resolveMainClassName task의 classpath property를 구성할 수 있습니다.

Configuring Gradle Tasks

Spring Boot의 Gradle Task는 해당 configuration에 Gradle property 지원을 일관되게 사용하도록 update 되었습니다.
결과적으로 property 값을 참조하는 방식을 변경해야 할 수 있습니다.
예를 들어 bootBuildImage 의 imageName property 값은 이제 imageName.get() 을 사용하여 access 할 수 있습니다.
또한 Kotlin DSL을 사용하는 경우 property들을 설정하는 방식을 변경해야 할 수도 있습니다.
예를 들어 Spring Boot 2.x에서 bootJar task의 layering은 다음과 같이 비활성화 할 수 있습니다 :

tasks.named<BootJar>("bootJar") {
    layered {
        isEnabled = false
    }
}

3.0에서는 다음을 사용해야 합니다 :

tasks.named<BootJar>("bootJar") {
    layered {
        enabled.set(false)
    }
}

추가 예시는 Gradle plugin의 reference documentation을 참조하세요.

Excluding Properties From 'build-info.properties' With Gradle

앞에서 설명한 Gradle task configuration 변경 사항의 일부로 생성된 build-info.properties 파일에서 property 들을 제외하는 메커니즘도 변경되었습니다.
이전에는 property들을 null 로 설정하여 제외할 수 있었습니다.
이것은 더 이상 작동하지 않으며 name-based 메커니즘으로 대체되었습니다 :

springBoot {
    buildInfo {
        excludes = \['time'\]
    }
}

Gradle Kotlin DSL의 해당 항목은 다음과 같습니다 :

springBoot {
    buildInfo {
        excludes.set(setOf("time"))
    }
}

Maven Changes

Maven으로 Spring Boot project를 빌드하는 사용자는 다음 section을 검토해야 합니다.

Running Your Application in Maven Process

Spring Boot 2.7에서 더 이상 사용되지 않는 spring-boot:run 및 spring-boot:start 의 fork attribute가 제거되었습니다.

Git Commit ID Maven Plugin

Git Commit ID Maven Plugin이 좌표가 변경된 version 5로 변경되었습니다.
이전 좌표는 pl.project13.maven:git-commit-id-plugin 이었습니다.
새 좌표는 io.github.git-commit-id:git-commit-id-maven-plugin 입니다.
pom.xml 파일의 모든 <plugin> 선언은 그에 따라 update 되어야 합니다.

Dependency Management Changes

Spring Boot에서 관리하는 dependency 들이 다음과 같이 변경되었습니다.

JSON-B

Eclipase Yasson을 위해 Apache Johnzon에 대한 dependency management가 제거되었습니다.
Apache Johnzon의 Jakarta EE 10 호환 버전은 Spring Boot 3과 함께 사용할 수 있지만 이제 dependency 선언에서 버전을 지정해야 합니다.

ANTLR 2

ANTLR 2(antlr:antlr)에 대한 dependency management가 더 이상 필요하지 않으므로 제거되었습니다.
application에서 ANTLR 2를 사용하는 경우 필요에 맞는 버전을 지정하세요.

RxJava

RxJava 1.x 및 2.x에 대한 dependency management가 제거되고 RxJava 3에 대한 dependency management가 대신 추가되었습니다.

Hazelcast Hibernate Removed

Spring Boot는 Hazelcast Hibernate에 의존하지 않으므로 해당 버전에 대한 의견이 필요하지 않습니다.
따라서 Hazelcast Hibernate에 대한 dependency management가 제거되었습니다.
Hazelcast Hibernate를 계속 사용하려면 필요에 맞는 버전을 지정하세요.
또는 대신 org.hibernate.org:hibernate-jcache 를 사용하는 것을 고려하세요.

Other Removals

다음 dependency 들에 대한 지원이 Spring Boot 3.0에서 제거되었습니다.

• Apache ActiveMQ
• Atomikos
• EhCache 2
• Hazelcast 3

Jetty 기반 client인 Http2SolrClient 가 Jetty 11과 호환되지 않으므로 ApacheSolr에 대한 지원이 제거되었습니다.