Red Hat build of Quarkus 3.20 のリリースノート

Red Hat build of Quarkus 3.20 では、次のエクステンションによって Fabric8 Kubernetes Client がバージョン 6.13 から 7.1 にアップグレードされます。

このアップグレードにより、パフォーマンス、互換性、テストにいくつかの改善がもたらされます。

Fabric8 Kubernetes Client 7.1 の主な利点は次のとおりです。

この変更により、重大な変更が導入されます。詳細は、「以前のバージョンとの互換性に影響を与える変更」セクションの こちらのリリースノート を参照してください。

この変更には手動による介入が必要です。これは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新プロセスには含まれていません。

Red Hat build of Quarkus 3.20 以降、Red Hat ビルダーおよびランタイムベースイメージは、デフォルトで Red Hat Universal Base Image 9 (UBI 9) を使用します。

以下のイメージがアップグレードされます。

このアップグレードでは重大な変更が導入されます。ビルダーおよびランタイムベースイメージが UBI 9 にアップグレードされます。

UBI 9 イメージに手動でアップグレードする場合のオプションの概要を次の表に示します。

UBI 9 ベースのランタイムイメージで問題が発生した場合は、手動で UBI 8 ベースのイメージに切り替えることができます。詳細は、ビルダーおよびランタイムベースイメージが UBI 9 にアップグレードされる を参照してください。

詳細は、以下の資料を参照してください。

Red Hat build of Quarkus 3.20 では、エクステンションは開発モード (dev モード) でのみ、または特定の条件が満たされた場合にのみアクティブ化される条件付き依存関係を宣言できるようになり、通常モードとテストモードでの不要な依存関係を回避できます。

詳細は、Quarkus ガイド「条件付きエクステンションの依存関係」の 開発モードのみのエクステンションの依存関係 セクションを参照してください。

Red Hat build of Quarkus 3.20 では、Mandrel バージョン 24.2 以降に合わせてロケール処理が更新されています。

アプリケーションは、ビルドシステムのロケールに関係なく、実行時に一貫したデフォルトのロケールを使用するようになりました。この変更により、環境間でのロケールに依存する動作の移植性と予測可能性が向上します。

この変更により、重大な変更が導入されます。詳細は、「以前のバージョンとの互換性に影響を与える変更」セクションの こちらのリリースノート を参照してください。

この変更には手動による介入が必要です。これは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新プロセスには含まれていません。

Red Hat build of Quarkus 3.20 以降、quarkus-agroal エクステンションにより、Dev UI へのデータベース接続を監視するための専用の Agroal - Database connection pool カードとページが追加されます。

Quarkus アプリケーションに quarkus-agroal エクステンションを使用する JDBC ドライバーエクステンションが含まれている場合、そのエクステンションはアプリケーションに自動的に含まれます。

Dev UI では、Agroal - Database connection pool カードをお気に入り (星印) にすることができます。また、Database view のリンクをカードから Dev UI メニューにドラッグすることもできます。Database view をクリックすると、Agroal - Database connection pool ページが開き、接続 URL を含むすべてのアクティブなデータソースを表示できます。

この機能拡張により、Dev UI 内でのデータベースの監視と設定が合理化され、デバッグとデータベース管理が改善されます。

Red Hat build of Quarkus 3.20 では、quarkus-datasource エクステンションが、ArC に最適化された依存性注入フレームワークを使用して、アプリケーションの起動時にデータソース設定を検証するようになりました。この機能拡張により、設定ミスが早期に検出されるようになり、ランタイムエラーを防ぎ、障害のあるインスタンスにトラフィックがルーティングされるリスクを低減します。

Red Hat build of Quarkus における主な変更点:

詳細は、「データソースの設定」ガイドの データソースのアクティブ化または非アクティブ化 セクションを参照してください。

Red Hat build of Quarkus 3.20 では、SmallRye Reactive Messaging Kafka コネクターを通じて Apache Kafka トランザクションのサポートを追加する quarkus-messaging-kafka エクステンションが導入されました。この機能により、複数の Kafka トピックとパーティションへのアトミックな書き込みが可能になり、トランザクション内のすべてのレコードをコミットするか、一切コミットしないかを確実にすることで、イベント駆動型アプリケーションのデータの整合性を高めます。

この機能は テクノロジープレビュー として利用できます。

詳細は、Quarkus ガイド「Apache Kafka リファレンス」の Kafka トランザクション セクションを参照してください。

Red Hat build of Quarkus 3.20 以降、エクステンション開発者は Dev UI フッターにカスタムログタブを作成し、そこにログデータをストリームできます。このプロセスは、Dev UI でカードまたはページを作成するプロセスに似ています。

ログタブは、アプリケーション開発者がツールを切り替えることなく、アプリケーションを監視およびトラブルシューティングできるように継続的なデータを提供します。ページは他のページに移動するとバックエンドから切断されますが、ログタブは永続的に接続されたままになります。

詳細は、Quarkus ガイド「エクステンション開発者向けの Dev UI」の フッタータブの追加 セクションを参照してください。

Red Hat build of Quarkus 3.20 は、LGTM Dev Services を使用する際に、事前設定された複数の Grafana ダッシュボードを提供します。これらのダッシュボードは、アプリケーションのメトリクス、トレース、およびログを視覚化します。また、シームレスなデータ収集とプレゼンテーションのために OpenTelemetry を活用しています。一部のダッシュボードでは、OpenTelemetry 出力など、複数の方法で Micrometer データが表示されます。各ダッシュボードは、特定のアプリケーションセットアップに合わせて調整されています。

利用可能なダッシュボードは次のとおりです。

一部のダッシュボードパネルでは、スライディングタイムウィンドウでの計算を行うため、正確なデータが表示されるまでに数分かかる場合があります。

この更新以降、quarkus.otel.traces.suppress-application-uris 設定プロパティーを使用して、OpenTelemetry トレーシングから特定の URI を除外できるようになりました。これにより、トレーサーが無視する URI パターンのコンマ区切りリストを定義できます。

たとえば、quarkus.otel.traces.suppress-application-uris=trace,ping,people* を設定すると、/trace および /ping URI のトレースだけでなく、/people/1 や /people/1/cars などの /people で始まるすべての URI のトレーシングもオフになります。

カスタムの quarkus.http.root-path を使用する場合は、必ずそれを設定に含めてください。

Red Hat build of Quarkus 3.20 では、quarkus-opentelemetry エクステンションによって、終了するとすぐにスパンとログをエクスポートする SimpleSpanProcessor のサポートが追加されました。この動作は、サーバーレス環境や短命のアプリケーションで特に役立ちます。

この機能を有効にするには、次の設定プロパティーを true に設定します。

quarkus.otel.simple=true

この設定は、デフォルトの BatchSpanProcessor を置き換え、スパンとログがバッファリングされるのではなく、すぐに送信されるようにします。この変更は、アプリケーションがシャットダウンする前にテレメトリーデータが確実にエクスポートされるようにするため、Lambda 関数やその他の短期的なプロセスにとって極めて重要です。これにより、バッチ処理の遅延によるデータ損失を防ぐことができます。

Red Hat build of Quarkus 3.20 では、quarkus-opentelemetry エクステンションが OpenTelemetry (OTel) ロギングをサポートするようになりました。この機能を使用すると、対話型 Web アプリケーションに分散ロギングを提供できます。

この機能を有効にするには、次の設定プロパティーを true に設定します。

quarkus.otel.logs.enabled=true

詳細は、Quarkus ガイド OpenTelemetry Logging の使用 を参照してください。

Red Hat build of Quarkus 3.20 では、OpenTelemetry メトリクスが有効になっている場合、quarkus-opentelemetry エクステンションによって、MicroProfile Telemetry 2.0 仕様に準拠した JVM および HTTP サーバー要求メトリクスの自動計装が提供されます。

OpenTelemetry メトリクスはデフォルトで無効になっています。JVM および HTTP サーバー要求メトリクスを収集するには、quarkus.otel.metrics.enabled=true を設定して有効にする必要があります。

対応する設定プロパティーはデフォルトで有効になっていますが、設定で quarkus.otel.instrument.jvm-metrics=false または quarkus.otel.instrument.http-server-metrics=false を設定することで無効化できます。

OpenTelemetry メトリクスと統合したフォールトトレランス機能は、現時点ではサポートされていません。

Red Hat build of Quarkus 3.20 では、単一のリクエスト内で複数の認証メカニズムを使用するためのサポートが追加されました。相互 TLS (mTLS) や OpenID Connect (OIDC) ベアラートークン認証などのメカニズムを同じ認証フローで組み合わせることができるようになりました。

デフォルトでは、登録された認証メカニズムの 1 つによって最初の SecurityIdentity が生成されると、認証が完了します。すべてのメカニズムに認証情報の検証を要求するには、設定プロパティーを設定して包括的認証を有効にします。

この機能は、クライアント証明書へのアクセストークンのバインドが必要なシナリオなど、相互 TLS とベアラートークン認証を組み合わせる場合に役立ちます。

詳細と例は、「セキュリティーアーキテクチャー」ガイドの 認証メカニズムの組み合わせ セクションを参照してください。

Red Hat build of Quarkus 3.20 では、メタアノテーション内で @PermissionsAllowed を使用するためのサポートが追加され、より合理化されたアクセス制御管理のためのカスタムセキュリティーアノテーションを作成できるようになりました。

この機能拡張により、パーミッションベースの設定が簡素化され、セキュリティーコードの繰り返しが減少し、保守性が向上します。@PermissionsAllowed をカプセル化する再利用可能なセキュリティーアノテーションを定義できるようになりました。これにより、パーミッションの処理がより効率的かつ一貫したものになります。

詳細と例は、「Web エンドポイントの認可」ガイドの パーミッションメタアノテーションの作成 セクションを参照してください。

Red Hat build of Quarkus 3.20 以降、@PermissionChecker アノテーションを使用して、CDI Bean メソッドで宣言型パーミッションチェッカーを定義できます。この機能拡張により、パーミッションチェックをリソースクラスとは別に実装できるようになり、コードの重複が削減され、保守性が向上するため、柔軟で再利用可能な認可ロジックが実現します。

これらのパーミッションチェッカーは、文字列の等価性に基づいてパーミッション名を照合することにより、@PermissionsAllowed と連携して動作します。認証されたユーザーを表す SecurityIdentity と、受信した HTTP 要求パラメーターを評価することにより、汎用的な認可チェックをサポートします。このアプローチにより、きめ細かなアクセス制御が可能になります。チェッカーは、通常スコープまたはシングルトン CDI Bean で定義され、boolean または Uni<Boolean> のいずれかを返す必要があり、同期認可チェックとリアクティブ認可チェックの両方をサポートします。

この機能は、認可ロジックを一元化することでパーミッション管理を簡素化し、複数のエンドポイントにわたってセキュリティーポリシーをより簡単に適用できるようにします。開発者は、複数のアクションを動的に検証する汎用的なパーミッションチェッカーを作成できます。

詳細は、「Web エンドポイントの認可」ガイドの パーミッションチェッカーの作成 セクションを参照してください。

Red Hat build of Quarkus 3.20 以降では、quarkus-oidc を使用して、ファイルシステムから JWT ベアラートークンをロードすることで、OIDC プロバイダークライアントを認証するように OIDC を設定できます。

このアプローチにより、セキュアで自動化された認証が可能になります。これは、サービスアカウントトークンをファイルとしてマウントできる OpenShift などのコンテナー化された環境で特に役立ちます。Red Hat build of Quarkus はファイルからトークンを自動的に読み込み、トークンの有効期限が切れると再読み込みします。

設定の詳細と使用例は、次のリソースを参照してください。

Red Hat build of Quarkus 3.20 では、次の Quarkus エクステンションによって OpenID Connect (OIDC) 応答フィルターが導入されています。

ロギングやその他のアクションのために、応答ステータス、ヘッダー、本文を検査するには、OidcResponseFilter を実装します。

デフォルトでは、OIDC 応答フィルターはグローバルに適用されます。トークンエンドポイントなどの特定のエンドポイントをターゲットにするには、@OidcEndpoint アノテーションを使用します。

詳細は、「OpenID Connect (OIDC) 認証」ガイドの OIDC 応答フィルター セクションを参照してください。

相互 TLS (mTLS) トークンバインディングは、アクセストークンがクライアントの mTLS 認証証明書に暗号的にバインドされるようにして、セキュリティーを強化します。

この機能は RFC 8705 に基づいており、認証に使用される証明書の拇印がトークンに含まれる証明書の拇印と一致することを確認することで、盗まれたベアラーアクセストークンを受け入れるリスクを最小限に抑えます。

Red Hat build of Quarkus 3.20 以降、Quarkus OIDC エクステンション quarkus-oidc は、OpenID Connect (OIDC) と mTLS の両方で保護されたエンドポイントの証明書にバインドされたアクセストークンをサポートするようになりました。

この機能を有効にするには、次の設定プロパティーを設定します。

quarkus.oidc.token.binding.certificate=true

詳細は、「OpenID Connect (OIDC) 認証」ガイドの 相互 TLS トークンバインディング セクションを参照してください。

Red Hat build of Quarkus 3.20 では、OidcProviderClient の注入のサポートが導入され、アプリケーションが OpenID Connect (OIDC) プロバイダーの UserInfo、トークンイントロスペクション、および失効エンドポイントと対話できるようになりました。

これにより、開発者は必要に応じてプログラムで UserInfo、トークンイントロスペクション、および失効エンドポイントにアクセスできるようになります。たとえば、ユーザーがログアウトした後にアクセストークンを取り消すことができます。

詳細は、OpenID Connect (OIDC) 認証ガイドの トークンの失効 セクションを参照してください。

Red Hat build of Quarkus 3.20 以降、quarkus-oidc を使用すると、application.properties ファイルで設定する代わりに、OidcTenantConfig ビルダーを使用して OpenID Connect (OIDC) テナントをプログラムで定義できます。

このアプローチは、設定で OIDC テナントを定義するよりも柔軟性が高くなります。

このアプローチは、発行者ベースやパスベースのテナントリゾルバーなど、静的テナントを必要とする機能に特に役立ちます。

詳細は、「OpenID Connect (OIDC) 認証」ガイドの次のリソースを参照してください。

Red Hat build of Quarkus 3.20 では、quarkus-oidc エクステンションが存在しない場合でも、Dev Services for Keycloak を起動できるようになりました。この変更により、完全な OIDC エクステンションを必要とせずに、quarkus-oidc-client エクステンションを単独でテストできるようになります。

さらに、Dev Services for Keycloak が有効になっている場合、Red Hat build of Quarkus では次のような主要な OIDC クライアントプロパティーが自動的に設定されるようになりました。

以前は、これらのプロパティーを手動で設定する必要がありました。

これらの機能拡張は下位互換性があります。既存のワークフローと手動設定は、引き続き期待どおりに機能します。

Red Hat build of Quarkus 3.20 では、証明書チェーン全体での TLS ハンドシェイク中に期限切れまたはまだ有効でない証明書を処理するためのポリシーの設定がサポートされるようになりました。

以前は、トラストストアは RFC 3280 および関連仕様に準拠し、警告なしでこのような証明書を許可していました。

この更新により、ユーザーは次のいずれかのオプションを選択して動作を制御できるようになります。

Red Hat build of Quarkus 3.20 では、quarkus-oidc エクステンションがアクセストークンの Demonstrating Proof of Possession (DPoP) をサポートするようになりました。

この機能は テクノロジープレビュー として利用できます。

詳細は、以下の資料を参照してください。

Red Hat build of Quarkus 3.20 では、quarkus-tls-registry エクステンションにより、PEM キーストア内の暗号化された PKCS#8 秘密鍵のサポートが導入されています。

この機能は テクノロジープレビュー として利用できます。

これにより、開発者は AES-128-CBC 暗号化を使用して秘密鍵を保護し、アプリケーションのセキュリティーを向上させることができます。

この機能を使用するには、quarkus.tls.key-store.pem.password プロパティーにキーストアのパスワードを設定します。

詳細は、TLS レジストリーを使用したセキュリティーキーと証明書の管理 ガイドを参照してください。

Red Hat build of Quarkus 3.20 では、エクステンションの作成者は開発モードで実行されているアプリケーションの JVM オプションを定義できます。--enable-preview や --add-opens などのオプションをエクステンションメタデータで直接指定できるため、アプリケーション開発者がこれらを設定する必要がなくなります。

エクステンションは、開発モードで実行するときにこれらの JVM オプションを自動的に適用し、すべてのアプリケーション開発者の環境を一貫したものにします。

アプリケーション開発者は、Quarkus Maven プラグインを使用して、エクステンションが提供するすべての JVM オプションをオフにしたり、特定のエクステンションのオプションを選択的にオフにしたりできます。詳細は、Quarkus ガイド「Quarkus と Maven」の エクステンションが提供する開発モード Java オプション セクションを参照してください。

Red Hat build of Quarkus 3.20 以降、Dev UI フッターに HTTP タブが含まれるようになりました。これを使用して、ツールやコンテキストを切り替えることなく、受信 HTTP アクセスログメッセージを監視できます。

たとえば、Dev UI の SmallRye OpenAPI - Swagger UI ページを使用してアプリケーションの HTTP エンドポイントと対話する場合、Dev UI フッターの HTTP タブに、対応するログメッセージが表示されます。

詳細は、Quarkus ガイド「HTTP リファレンス」の HTTP アクセスログの設定 セクションを参照してください。

Red Hat build of Quarkus 3.20 では、REST エンドポイントパラメーターコンテナーとして Java レコードのサポートが導入され、簡潔で不変のデータ構造が可能になります。レコードはクエリー、Cookie、ヘッダー、フォーム、またはマルチパートパラメーターをカプセル化できるため、RESTful サービスでのデータ処理が簡素化されます。

Java レコードはすでに、REST 本文の JSON シリアル化とデシリアル化に使用できます。ただし、Jakarta REST 仕様の制限により、@BeanParam はまだこれらをサポートしていません。

Red Hat build of Quarkus 3.20 では、quarkus-rest および quarkus-resteasy エクステンションにより、新しい @AuthorizationPolicy アノテーションのサポートが追加されました。このアノテーションを使用すると、名前付きの HttpSecurityPolicy を Jakarta REST エンドポイントに直接バインドできます。この機能は、パス一致ルールの代替手段を提供し、SecurityIdentity ロールを変更せずに、より柔軟な認可チェックを可能にします。

詳細は、「Web エンドポイントの認可」ガイドの カスタム HttpSecurityPolicy セクションを参照してください。

Red Hat build of Quarkus 3.20 では、quarkus-rest-client エクステンションによって @Url アノテーションのサポートが追加されました。REST クライアントメソッドのパラメーターにアノテーションを付けて、ランタイムに URL を動的に提供できるようになりました。

通常、REST クライアントには、グローバルに設定されたベース URL が必要です。ただし、呼び出しごとに URL を設定する必要がある場合もあります。@Url アノテーションは、個々の呼び出しに対して動的な URL 解決を有効にすることで、このユースケースをサポートします。

詳細は、Quarkus ガイド「REST Client の使用」の 動的ベース URL セクションを参照してください。

Red Hat build of Quarkus 3.20 では、quarkus-rest-client エクステンションが MicroProfile REST Client 4.0 に更新されました。この更新では、REST クライアントを作成および管理するための標準化された宣言型 API を提供することで、アプリケーションが RESTful サービスと対話する方法が強化されます。柔軟性、パフォーマンス、セキュリティーが向上し、外部 REST サービスの統合が簡素化されます。

Red Hat build of Quarkus 3.20 では、quarkus-rest-jackson エクステンションにより、リフレクションフリーのデシリアライゼーションが導入され、JSON 処理機能が強化されます。

この機能拡張は、以前のリリースで実装されたリフレクションフリーのシリアル化を補完します。

デフォルトでは、リフレクションフリーの JSON 処理は無効になっています。有効にするには、次の設定プロパティーを true に設定します。

quarkus.rest.jackson.optimization.enable-reflection-free-serializers=true

デシリアライズ中にリフレクションへの依存を排除することで、アプリケーションはパフォーマンスを向上させ、メモリー消費を削減できます。特に、リフレクションによってオーバーヘッドが生じる可能性があるネイティブアプリケーションではその効果が顕著です。この機能を有効にする場合は、テストを実行してアプリケーションへの影響を評価します。

詳細は、Quarkus ガイド「Quarkus REST を使用した REST サービスの作成」の JSON シリアル化 セクションを参照してください。

Red Hat build of Quarkus 3.20 では、WebSocket サーバーおよびクライアントエンドポイントを定義するための最新の宣言型 API を提供する quarkus-websockets-next エクステンションのサポートが導入されています。

このエクステンションにより、効率的でスケーラブルなリアルタイム通信が可能になり、Red Hat build of Quarkus のリアクティブアーキテクチャーおよびネットワークレイヤーと統合されます。

非推奨の quarkus-websockets エクステンションとは異なり、WebSockets Next は Jakarta WebSocket 仕様を実装していません。

WebSockets Next によって導入された主な機能:

詳細は、「WebSockets Next リファレンス」ガイドの セキュリティー セクションを参照してください。

詳細は、シリアル化とデシリアル化 セクションを参照してください。

設定の詳細は、「WebSockets Next リファレンス」ガイドの テレメトリー セクションを参照してください。

詳細は、以下の資料を参照してください。

Red Hat は、Quarkus CLI、Maven および Gradle プラグインなどの Quarkus 開発ツールを使用して、Red Hat build of Quarkus アプリケーションのプロトタイプを作成、開発、テスト、デプロイするための 開発サポート を提供します。

Red Hat は、実稼働環境での Quarkus 開発ツールの使用をサポートしていません。詳細は、Red Hat ナレッジベースの記事 Development Support Scope of Coverage を参照してください。

Red Hat build of Quarkus 3.20 では、次のエクステンションによって Fabric8 Kubernetes Client がバージョン 6.13 から 7.1 にアップグレードされます。

quarkus-openshift および quarkus-kubernetes エクステンションは、Fabric8 を使用しますが、機能は変更されていないため、更新する必要はありません。

このアップグレードの一環として、io.quarkus:quarkus-test-openshift-client モジュールが削除されました。テストでこのモジュールを使用する場合は、同等の機能を提供する io.quarkus:quarkus-test-kubernetes-client に移行してください。詳細は、Quarkus ガイド「Kubernetes Client」の OpenShift Client セクションを参照してください。

アップグレードされた Fabric8 Kubernetes Client では、一部のモデルタイプとクラスが再編成されています。一部は別のモジュールに移動されました。新しい場所を確認するには、Fabric8 公式の Kubernetes Client: Migration from 6.x to 7.x ガイドを参照してください。

影響を受ける依存関係、設定、または API の使用状況をアプリケーションで確認し、必要に応じて更新してください。その後、アプリケーションを十分にテストして、Fabric8 7.1 との完全な互換性を確保します。

この変更には手動による介入が必要です。これは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新プロセスには含まれていません。

Red Hat build of Quarkus 3.15 で、RESTEasy Reactive から Quarkus REST へ、Reactive Messaging から Quarkus Messaging へブランド変更の一環として、多くのエクステンションと設定プロパティーの名前が変更されました。この変更に対応するために、アーティファクトの再配置と設定のフォールバックが導入されました。

Red Hat build of Quarkus 3.20 では、このアーティファクトの再配置と設定のフォールバックが削除されました。新しいアーティファクト名と設定プロパティーを使用する必要があります。

関連する背景情報は、「Red Hat build of Quarkus 3.15 のリリースノート」ガイドの RESTEasy Reactive エクステンションの名前が Quarkus REST に変更される セクションを参照してください。

Red Hat build of Quarkus 3.20 では、Mandrel バージョン 24.2 以降に合わせてロケール処理が更新されています。

すべてのアプリケーションで一貫したロケールの動作を確保するために、Red Hat build of Quarkus は標準化されたデフォルトのロケールストラテジーを適用します。次の表を使用して、ロケール設定に応じてアプリケーションの動作がどのように変化するかを確認してください。

quarkus.locales の設定に関係なく、en_US ロケールは常にネイティブ実行可能ファイルに埋め込まれます。

予期しない動作の変更を回避するために、設定プロパティーでアプリケーションのロケール設定を確認し、必要に応じて設定を更新してください。

この変更には手動による介入が必要です。これは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新プロセスには含まれていません。

Red Hat build of Quarkus 3.20 では、@Fallback.fallbackMethod() および @BeforeRetry.methodName() の設定プロパティーがビルド時に解決され、ランタイムに変更できなくなりました。影響を受ける設定プロパティーは次のとおりです。

この変更により、適切なリフレクション設定とネイティブイメージコンパイルとの互換性が確保されます。

Red Hat build of Quarkus 3.20 では、quarkus-smallrye-fault-tolerance エクステンションに SmallRye Fault Tolerance 6.7.0 が組み込まれています。これにより、互換性を失わせる変更点は導入されませんが、次の更新が導入されます。

詳細は、SmallRye Fault Tolerance 6.7.0 のリリース告知を参照してください。これには、プログラム API の移行ガイドへのリンクと、新しい設定プロパティーの詳細が記載されています。Quarkus ガイド SmallRye のフォールトトレランス には、これらの設定プロパティーの詳細なリファレンスが記載されています。

Red Hat build of Quarkus 3.20 以降、io.quarkus.scheduler.Scheduler 内のメソッドの動作が変更されました。

スケジューラーが起動していない場合、ほぼすべてのメソッドが UnsupportedOperationException を出力するようになりました。

スケジューラーが実行中かどうかを確認するには、新しいメソッド Scheduler#isStarted() を使用できます。

この変更は、quarkus-scheduler および quarkus-quartz エクステンションに基づくスケジューラーインスタンスに影響します。

Red Hat build of Quarkus 3.20 以降、開発モードおよびテストモードを使用する場合、管理インターフェイスがデフォルトで 0.0.0.0 ではなく localhost インターフェイスでリッスンします。この変更により、メインインターフェイスの動作と同じになりました。

Windows Subsystem for Linux (WSL) を搭載した Windows では、管理インターフェイスもメインインターフェイスも、引き続き 0.0.0.0 でリッスンします。

詳細は、Quarkus の Management interface reference ガイドを参照してください。

Red Hat build of Quarkus 3.20 では、設定が @ConfigMapping フレームワークに移行されました。この変更により、従来の設定クラスが非推奨になり、インターフェイスとメソッドシグネチャーに基づく統合設定モデルが導入されました。

一般的に使用される特定の設定クラスは、互換性レイヤーが残っています。ただし、このレイヤーは今後のリリースで削除される予定です。

Red Hat build of Quarkus 3.20 以降、Red Hat のビルダーおよびランタイムベースイメージが、Red Hat Universal Base Image 9 (UBI 9) を使用するようにアップグレードされます。

UBI 8 から UBI 9 にアップグレードする場合、システム依存関係、ネイティブイメージビルド、またはパッケージおよび GNU C ライブラリー (glibc) バージョンの更新による変更が、アプリケーションの動作やランタイム環境に影響する可能性があることに注意してください。必要に応じて設定を確認して更新してください。

UBI 9 で問題が発生した場合は、手動で UBI 8 に戻すことができます。

詳細は、以下の資料を参照してください。

Red Hat build of Quarkus の以前のバージョンでは、Dev Services が無効になっているか実稼働モードで実行されている場合、quarkus.datasource.reactive.url および quarkus.datasource.<datasource-name>.reactive.url プロパティーが、ドキュメント化されていないデフォルト値に暗黙的に設定され、データベース固有のポートを使用する localhost をターゲットとしていました。

Red Hat build of Quarkus 3.20 以降、Dev Services が無効になっている場合、またはアプリケーションが本番モードで実行されている場合、これらのプロパティーにデフォルト値が設定されなくなりました。プロパティーが設定されていない場合、対応するデータソースが非アクティブ化されます。非アクティブ化されたデータソースをアプリケーションが使用しようとすると、起動時にデータソースが失敗します。詳細は、リリースノート データソースが非アクティブ化されているか、URL が設定されていない場合、データソースの使用がすぐに失敗する を参照してください。

アプリケーションにアクティブなデータソースが必要で、それを localhost 上のデータベースに接続する場合は、quarkus.datasource.reactive.url または quarkus.datasource.<datasource-name>.reactive.url プロパティーを明示的に設定する必要があります。以下に例を示します。

quarkus.datasource.reactive.url=postgresql://localhost:5432/mydatabase

以前のバージョンでは、この設定は暗黙的に指定されていました。このリリース以降、データソースをアクティブ化するには、URL を定義する必要があります。

以前は、Dev Services が無効になっているか本番モードの場合、quarkus.datasource.jdbc.url、quarkus.datasource.<datasource-name>.jdbc.url、quarkus.datasource.reactive.url、または quarkus.datasource.<datasource-name>.reactive.url プロパティーが設定されていない場合でも、Red Hat build of Quarkus がデータソースのヘルスチェックを実行していました。これにより、JDBC データソースでは常に成功し、リアクティブデータソースではほぼ常に失敗していたため、ヘルスチェックの信頼性が低下していました。

Red Hat build of Quarkus 3.20 以降、URL のないデータソースはヘルスチェックに影響しなくなりました。ヘルスチェックを確実に利用可能にするには、quarkus.datasource.jdbc.url、quarkus.datasource.<datasource-name>.jdbc.url、quarkus.datasource.reactive.url、または quarkus.datasource.<datasource-name>.reactive.url プロパティーを明示的に設定します。

Red Hat build of Quarkus 3.20 では、データソースが quarkus.datasource.active=false で非アクティブ化されている場合や URL が欠落している場合でも、アプリケーションが正常に起動します。この動作により、特に Dev Services が無効になっている場合や本番モードになっている場合に、データソースに初めてアクセスしたときにランタイムエラーが発生することがよくあります。

この更新により、データソースが使用されているものの、非アクティブ化されているか URL が欠落していることを Red Hat build of Quarkus が検出した場合、アプリケーションの起動が失敗するようになりました。

Red Hat build of Quarkus は、これらの問題を早期に検出するために、以下のように、より厳格な検証を起動時に実施するようになりました。

これと同じ検証が、Flyway および Liquibase エクステンションの Flyway および LiquibaseFactory CDI Bean にも適用されます。

Red Hat build of Quarkus 3.20 では、quarkus-flyway エクステンションによって Flyway がバージョン 11 にアップグレードされます。これにより、cleanOnValidationError 設定パラメーターが削除されます。さらに、Flyway.validate() を呼び出しても検証エラーがクリーンアップされなくなりました。

この変更を緩和するために、Red Hat build of Quarkus 3.20 では、quarkus.flyway.validate-at-start.clean-on-validation-error 設定プロパティーが導入されました。これは cleanOnValidationError と同様の動作を提供するものですが、アプリケーションの起動時にのみ適用されます。

回避策: Flyway.validate() への明示的な呼び出しで cleanOnValidationError の以前の動作が必要な場合は、アプリケーションで検証エラーをキャッチし、Flyway.clean() を使用してデータベースのクリーンアップを明示的にトリガーすることを検討してください。

この変更には手動による介入が必要です。これは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新プロセスには含まれていません。

詳細は、Quarkus ガイド Using Flyway を参照してください。

Red Hat build of Quarkus 3.20 では、Dev Services が使用する IBM Db2 ドライバーとコンテナーイメージがバージョン 12 にアップグレードされました。

IBM Db2 ドライバーとコンテナーイメージは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新により、バージョン 12 にアップグレードされます。

Db2 Connect 12.1 にアップグレードする場合は、IBM の Features with behavior changes when upgrading to the Db2 Connect 12.1 driver に記載されている新しいライセンス要件、設定手順、および SSL/TLS 設定を確認してください。

この変更には手動による介入が必要です。これは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新プロセスには含まれていません。

Red Hat build of Quarkus 3.20 では、Hibernate ORM の Bean Validation 統合のデフォルト動作が変更されました。以前は、データ定義言語 (DDL) の生成時に検証制約が考慮されていませんでした。このリリースでは、Hibernate ORM がデフォルトで適用可能な検証制約を DDL に含めるようになりました。これにより、データベーススキーマとアプリケーションレベルの制約の整合性が向上します。

quarkus.hibernate-orm.validation.enabled プロパティーも非推奨になりました。

これらの変更の詳細とアプリケーションの移行に関するガイダンスは、Migration Guide 3.19 または次のリソースを参照してください。

Red Hat build of Quarkus 3.20 では、quarkus.log.*.json 設定プロパティーが非推奨になりました。ロギングで JSON 形式を有効にするには、代わりに quarkus.log.*.json.enabled プロパティーを使用します。

この変更は、YAML 設定との互換性を向上させるために導入されました。以前の構造では、ルートキーに値を割り当てるために ~ などの特殊な構文を使用する必要がありました。そのため、設定で混乱やエラーが発生しやすくなっていました。

詳細は、Migration Guide 3.19 を参照してください。

Red Hat build of Quarkus 3.20 では、quarkus-opentelemetry エクステンションによって互換性を失わせる変更が導入されました。これは、開発中のデータベース値 (Redis に関連する値など) が別のパッケージに移動されたためです。

OpenTelemetry では、データベースのセマンティック規則がまだ安定していないため、変更のリストが保持されていません。

手動計装を使用する場合、この変更によって手動による介入が必要になる可能性があります。これは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新プロセスには含まれていません。

Red Hat build of Quarkus 3.20 では、以前非推奨になった quarkus-smallrye-opentracing エクステンションと、関連する設定プロパティー quarkus.datasource.jdbc.tracing が削除されました。

現在は、quarkus-opentelemetry エクステンションが推奨されるトレーシングソリューションです。OpenTelemetry で JDBC トレーシングを有効にするには、次の設定プロパティーを使用します。

quarkus.datasource.jdbc.telemetry=true

移行するには、OpenTracing エクステンションを OpenTelemetry に置き換え、それに応じて設定を更新します。

Red Hat build of Quarkus 3.20 以降、quarkus-oidc-client エクステンションを使用する場合に、OpenID Connect (OIDC) クライアントが特定の URL を参照するように設定していないと、Dev Services for Keycloak が自動的に開発モードで起動します。

この動作を無効にするには、次のプロパティーを application.properties ファイルに追加します。

quarkus.keycloak.devservices.enabled=false

Red Hat build of Quarkus 3.20 では、セキュリティーの強化、業界標準への準拠、長期的な保守性の向上のために、WebAuthn4J を使用して quarkus-security-webauthn エクステンションが再実装されました。

そのため、この更新は以前のバージョンのエクステンションと互換性がありません。

新しい実装にスムーズに移行するために、次の情報を使用してください。

この機能のステータスは、さらなる安定化を図るために preview から experimental にダウングレードされました。

詳細は、Quarkus ガイド Using Security with WebAuthn を参照してください。

この変更には手動による介入が必要です。これは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新プロセスには含まれていません。

以前は、Red Hat build of Quarkus 3.15 に、不具合がある未発表のバージョンの @WithTestResource が同梱されていました。

Red Hat build of Quarkus 3.20 では、この不具合が修正されました。これにより、互換性を失わせる変更が生じました。このリリースでは、以前の restrictToAnnotatedClass フィールドが scope に置き換えられました。

以前のリリースでは、quarkus-junit5-mockito 依存関係が、subclass モッキングストラテジーを使用してモックオブジェクトを作成するように設定されていました。

Red Hat build of Quarkus 3.20 以降、この依存関係はデフォルトで inline モッキングストラテジーを使用するように設定されます。

Red Hat build of Quarkus 3.20.0 では、依存関係バージョンの意図的な不一致により、quarkus-junit5-mockito 依存関係が一時的に機能しなくなっていました。使用中の Mockito のバージョンには JUnit 5.11 以降が必要でしたが、プラットフォームには JUnit 5.10 が含まれていました。

この問題を解決するために、Red Hat build of Quarkus 3.20.1 では JUnit をバージョン 5.12.1 にアップグレードします。この更新により、JUnit と Mockito のバージョンが調整され、quarkus-junit5-mockito 依存関係の互換性が回復されます。

この更新の影響は最小限になると予想されます。コミュニティーと Camel Quarkus でのテストでは、リグレッションは発生しませんでした。詳細は、関連する問題 https://github.com/quarkusio/quarkus/issues/46858 を参照してください。

すべての JUnit アーティファクトにわたって一貫したアライメントを確保するには、次のように 3.20.0 で使用される JUnit BOM バージョンをインポートします。

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.junit</groupId>
      <artifactId>junit-bom</artifactId>
      <version>5.10.5</version>
      <scope>import</scope>
      <type>pom</type>
    </dependency>
  </dependencies>
</dependencyManagement>

HTTP 圧縮が有効な場合、quarkus.http.compress-media-types 設定プロパティーで、圧縮するメディアタイプのリストが定義されます。Red Hat build of Quarkus 3.20 では、このプロパティーのデフォルト値が変更されました。新しく圧縮されるメディアタイプに、application/json と application/xhtml+xml が追加されました。

Red Hat build of Quarkus 3.20 では、REST Client の設定がより厳格になり、設定を取得するために必要な検索と組み合わせの数が削減されました。

Red Hat build of Quarkus 3.20 以降、quarkus-qute エクステンションは、対応するテンプレートのバリアントが設定されている場合、JSON テンプレート内の二重引用符 (")、バックスラッシュ (\)、および制御文字 (U+0000 から U+001F) を自動的にエスケープします。このエクステンションは、src/main/resources/templates ディレクトリーにあるテンプレートにバリアントを自動的に割り当てます。

デフォルトでは、java.net.URLConnection#getFileNameMap() によってテンプレートファイルのコンテンツタイプが決定されます。quarkus.qute.content-types 設定を使用しすると、追加の接尾辞とコンテンツタイプのマッピングを定義できます。

エスケープされていない値をレンダリングするには、java.lang.Object の拡張メソッドとして実装されている raw プロパティーまたは safe プロパティーを使用するか、文字列値を io.quarkus.qute.RawString クラスでラップします。

詳細は、Quarkus ガイド「Qute reference」の Character escapes セクションを参照してください。

Red Hat build of Quarkus 3.20 では、quarkus-rest-jackson エクステンションにより、修飾子のない ObjectMapperCustomizer Bean のみが Jackson JSON プロセッサーのデフォルトの ObjectMapper インスタンスに適用されます。

以前のバージョンでは、カスタム修飾子を持つものも含め、すべての Customizer Bean がデフォルトの ObjectMapper インスタンスに適用されていました。

この変更には手動による介入が必要です。これは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新プロセスには含まれていません。

詳細は、以下の資料を参照してください。

以前のリリースでは、quarkus-rest エクステンションでは、?foo= などの空の値を持つクエリーパラメーターが、次のようにデシリアライズされていました。

Red Hat build of Quarkus 3.20 では、この動作が次のように変更されました。

これに応じてコードを更新してください。

この変更には手動による介入が必要です。これは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新プロセスには含まれていません。

Red Hat build of Quarkus 3.20 では、Jakarta WebSocket 仕様を実装する quarkus-websockets および quarkus-websockets-client エクステンションが非推奨になりました。

Red Hat build of Quarkus は、今後のリリースでこれらのエクステンションのサポートを停止する予定です。

今後のバージョンとの互換性を確保するには、Quarkus WebSockets Next エクステンション (quarkus-websockets-next) に移行してください。このエクステンションは、より効率的な最新の WebSocket API を提供します。

詳細は、次の Quarkus リソースを参照してください。

この変更には手動による介入が必要です。これは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新プロセスには含まれていません。