SpringBoot 3.1がGAとなりました
Release Notesを参考に3.0系からの変更点をまとめます
自分が移行するときに関係のあるものや興味があるものが中心となりますがご容赦ください🙇♂️
関連記事はこちら
SpringBoot Updateまとめ
HttpClient4が依存から除外
HttpClient4が依存から除外されるため、RestTemplateでHttpClient4を使用している場合はHttpClient5への移行が必要になります。
基本、SpringBoot3へアップデートしたときにHttpClient5への移行を行っているはずなので対応不要だと思いますが、
移行が必要な場合はエラーが発生するので、エラーの発生ベースで対応すればよいのかなと
Jackson 2.15
Jacksonのversionが2.15に上がります。
2.15ではlimitが定義されるようです。
具体的なlimitは
| 対象 | limit |
|---|---|
| 整数、浮動小数点数 | 1000桁 |
| 文字列 | 5,000,000 byte / 5,000,000 char |
| ネストの深さ | 1000 |
となっていて、よほど大きなjsonを扱わない限り問題にならなそうですが、制約が追加されたこと自体は認識しておいた方がよさそうです。
Testcontainersがspring-boot-dependenciesの管理対象に
testcontainersがspring-boot-dependenciesに追加されました。
動作確認済みのversionが自動で使われるようになるのでversion情報は消しておきましょう！
dependencies {
// 変更前
// testImplementation 'org.testcontainers:junit-jupiter:1.18.0'
// 変更後
testImplementation 'org.testcontainers:junit-jupiter'
}（新機能）Service Connections
docker-composeやtestcontainer利用時に、dockerコンテナとの接続するための情報を自動でBean登録してくれるようになります。
そして、そのBean登録された情報が、設定したプロパティよりも優先的に読み込まれるため、起動したコンテナのport等を意識せずに接続が可能になります。
具体的に見ていきます。
3.0まではtestcontainers利用時に以下のように@DynamicPropertySourceでプロパティを設定する必要がありました。
@Container
public static CassandraContainer<?> cassandra = new CassandraContainer<>("cassandra:3.11.2")
.withInitScript("initial.cql");
@DynamicPropertySource
static void properties(DynamicPropertyRegistry registry) {
registry.add("spring.cassandra.keyspace-name", () -> "sample");
var contactPoint = "%s:%d".formatted(cassandra.getContactPoint().getHostName(), cassandra.getContactPoint().getPort());
registry.add("spring.cassandra.contact-points", () -> contactPoint);
registry.add("spring.cassandra.local-datacenter", () -> cassandra.getLocalDatacenter());
}3.1では@ServiceConnectionを@Containerと一緒に付与するだけで良くなります！
@Container
@ServiceConnection
public static CassandraContainer<?> cassandra = new CassandraContainer<>("cassandra:3.11.2")
.withInitScript("initial.cql");・何をサポートしているかは以下のURLからご確認ください
サポートイメージ：TDB
開発時のDocker利用
dockerとの連携が強化されており、アプリケーションの起動・終了に合わせてDockerコンテナの起動・終了ができるようになりました👍
testcontainersと使う方法とdocker-composeを使う方法があります。
testcontainers
testcontainersという、junit5実行時にデータベース、ウェブサーバー、メッセージキューなどの依存関係をDockerコンテナで提供してくれるツールがあります。
※JUnit5でのtestcontainersの使い方はこちら
SpringBoot3.1ではこのtestcontainersを開発時にも使えるようになりました！
testcontainersを開発時に使用するにはtest source配下にメインクラスとConfigurationクラスを実装します。
dependencies {
testImplementation 'org.springframework.boot:spring-boot-testcontainers'
// 今回はCassandraを利用
testImplementation 'org.testcontainers:cassandra'
}まずはConfigurationクラスです。
@TestConfiguration(proxyBeanMethods = false)
public class TestContainersConfiguration {
@Bean
@ServiceConnection
public CassandraContainer<?> cassandraContainer() {
return new CassandraContainer<>("cassandra:3.11.2")
.withInitScript("initial.cql") // 初期クエリ
.withExposedPorts(9042);
}
}・@ServiceConnectionを付与すると関連propertyを設定せずともコンテナに接続できるように構成してくれます
次にメインクラスです。
※main source配下のメインクラスとは別で作成します。
public class TestApplication {
public static void main(String[] args) {
SpringApplication.from(MainApplication::main) // main配下のメインクラスを指定
.with(TestContainersConfiguration.class) // 先ほど作成したConfigurationクラスを指定
.run(args);
}
}これで準備はOK！
gradleだとbootTestRunタスクを実行すると、Dockerコンテナを利用しながら開発ができます！
docker-compose
spring-boot-docker-composeを依存に追加することでプロジェクト直下のdocker-compose.ymlを元にdockerコンテナが起動してくれます。
dependencies {
...
implementation 'org.springframework.boot:spring-boot-docker-compose'
...
}ローカルのみ有効に
implementationで依存を追加すると本番でも有効なライブラリになってしまうのでちょっと気持ち悪いですよね。
そんなときに以下のような設定でbootRunのときだけdocker-compose連携することができます！
// implementationの代わりに使えるbootRunOnlyを定義
configurations {
bootRunOnly
}
dependencies {
...
bootRunOnly 'org.springframework.boot:spring-boot-docker-compose'
...
}
bootRun {
// bootRun時のみ、bootRunOnlyで定義した依存を有効に
classpath += configurations.bootRunOnly
}docker-compose連携とtestcontainerどっちを使う？
testに絞って言えば、testcontainer１択だと思います（docker-compose連携はtestのサポートがされていなさそうな🤔）
開発時のbootRun時は、docker-compose連携の方がいいかなと（機能的にはどっこいどっこいで、test用に別でmainクラスを作らなければいけないのが個人的に引っかかるので…）
