1.2. 以前のバージョンとの互換性に影響を与える変更


このセクションでは、以前の製品バージョンでビルドされたアプリケーションの互換性に影響を与える、Red Hat build of Quarkus 3.2 の変更点について説明します。

これらの破壊的変更を確認し、アプリケーションを Red Hat build of Quarkus 3.2 に更新した後も、アプリケーションが確実に機能し続けるために必要な手順を実行してください。

これらの変更の多くを自動化するには、quarkus update コマンドを使用して、プロジェクトを Red Hat build of Quarkus の最新バージョンに更新 します。

1.2.1. クラウド

1.2.1.1. Red Hat build of Quarkus に含まれる Kubernetes Client へのアップグレード

Kubernetes Client が 5.12 から 6.7.2 にアップグレードされました。詳細は、Kubernetes Client - Migration from 5.x to 6.x ガイドを参照してください。

1.2.1.2. TLS ベースのコンテナーポートを生成するためのロジックの改善

Red Hat build of Quarkus 3.2 では、Kubernetes エクステンションが TLS ベースのコンテナーポートを生成する方法に変更が導入されています。

以前のバージョンでは、生成されたデプロイメントリソースに https という名前のコンテナーポートが自動的に追加されました。このアプローチでは、特に SSL/TLS が設定されていない場合に問題が発生し、ポートが機能しなくなりました。

3.2 以降では、Kubernetes エクステンションはデフォルトで https という名前のコンテナーポートを追加しません。コンテナーポートは、次の手順を実行した場合にのみ追加されます。

  • 関連する quarkus.http.ssl.* プロパティーを application.properties ファイルで指定する場合。
  • quarkus.kubernetes.ports.https.tls=trueapplication.properties ファイルで指定する場合。

1.2.1.3. 一部の Kubernetes および OpenShift プロパティーの削除

この 3.2 リリースでは、以前に非推奨となった Kubernetes および OpenShift 関連のプロパティーの一部が削除されました。削除されたプロパティーは、新しいプロパティーに置き換えてださい。

Expand
表1.1 削除されたプロパティーと新しいプロパティー
削除されたプロパティー新規プロパティー

quarkus.kubernetes.expose

quarkus.kubernetes.ingress.expose

quarkus.openshift.expose

quarkus.openshift.route.expose

quarkus.kubernetes.host

quarkus.kubernetes.ingress.host

quarkus.openshift.host

quarkus.openshift.route.host

quarkus.kubernetes.group

quarkus.kubernetes.part-of

quarkus.openshift.group

quarkus.openshift.part-of

さらに、このリリースでは、quarkus. の接頭辞がないプロパティーは無視されます。たとえば、このリリースより前は、kubernetes.name プロパティーを追加した場合、それは quarkus.kubernetes.name にマップされました。2.16.0.Final から 2.16.1.Final #30850 にアップグレードする際の java.lang.ClassCastException のような例外を回避するために、この種のマッピングは行われなくなりました。

Quarkus のコンテキストで Kubernetes と OpenShift の作業を続ける場合は、新しいプロパティーを使用し、必要に応じて quarkus. の接頭辞を付けます。

1.2.2. Core

1.2.2.1. Jandex 3 へのアップグレード

この 3.2 リリースでは、Jandex は SmallRye プロジェクトの一部となり、すべての Jandex プロジェクトが 1 つのリポジトリー (https://github.com/smallrye/jandex/) に統合されます。その結果、Jandex Maven プラグインの新しいリリースが Jandex コアとともに提供されます。

このリリースでは、Maven コーディネートも変更されます。古いコーディネートを新しいコーディネートに置き換えます。

Expand
表1.2 古いコーディネートと新しいコーディネート

古いコーディネート

新しいコーディネート

org.jboss:jandex

io.smallrye:jandex

org.jboss.jandex:jandex-maven-plugin

io.smallrye:jandex-maven-plugin

Maven Enforcer プラグインを使用する場合は、org.jboss:jandex への依存関係を禁止するように設定します。Gradle ユーザーは、同等のプラグインを利用できます。

1.2.2.2. Jandex API ユーザーの移行パス

Jandex 3 には、多くの興味深い機能と改善が含まれています。残念ながら、これらの変更には、いくつかの破壊的変更が必要でした。推奨される移行パスは次のとおりです。

  1. Jandex 2.4.3.Final にアップグレードします。このバージョンでは、Jandex 3.0.0 で変更されたいくつかのメソッドの代替が提供されます。たとえば、ClassInfo.annotations() の代わりに annotationsMap() を使用し、MethodInfo.parameters()parameterTypes() に置き換えます。Jandex が非推奨としてマークしたメソッドの使用を停止してください。
  2. Indexer.index() または indexClass() の戻り値を使用しないようにしてください。
  3. Jandex 2.4.3.Final に対してコードをコンパイルすると、2.4.3.Final と 3.0.0 の両方に対して実行できます。ただし、これには例外があります。IndexView インターフェイスを実装するか、場合によっては UnresolvedTypeVariable クラスに依存する場合は、プロジェクトを Jandex 2.4.3 と Jandex 3 の両方と互換性を保つことができません。
  4. Jandex 3.0.0 にアップグレードします。IndexView インターフェイスを実装する場合は、追加されたメソッドを必ず実装してください。また、Jandex Type 階層を広範囲に使用する場合は、再帰型変数を表すために現在使用されている TypeVariableReference を処理する必要があるか確認してください。

このリリースと並行して、Jandex は 新しいドキュメントサイト を導入します。現在進行中の作業ですが、今後より包括的なものになる予定です。詳細は、改良された Jandex Javadoc を参照してください。

1.2.2.3. io.quarkus.arc.config.ConfigProperties アノテーションの削除

この 3.2 リリースでは、以前に非推奨になった io.quarkus.arc.config.ConfigProperties アノテーションが削除されました。

代わりに、io.smallrye.config.ConfigMapping アノテーションを使用して、複数の関連する設定プロパティーを注入します。

詳細は、MAPPING CONFIGURATION TO OBJECTS ガイドの @ConfigMapping セクションを参照してください。

この 3.2 リリースでは、プライベートメソッドでのインターセプターバインディングアノテーションの宣言はサポートされておらず、ビルドの失敗をトリガーします。以下に例を示します。

jakarta.enterprise.inject.spi.DeploymentException: @Transactional does not affect method com.acme.MyBean.myMethod() because the method is private. [...]

以前のリリースでは、プライベートメソッドでインターセプターバインディングアノテーションを宣言すると、ログに警告が表示されるだけで、それ以外は無視されていました。

このサポート変更は、プライベートメソッドでのインターセプターアノテーションの意図しない使用を防ぐことを目的としています。インターセプターアノテーションによる効果がなく、混乱を引き起こす可能性があるためです。

この変更に対処するには、プライベートメソッドからそのようなアノテーションを削除します。これらのアノテーションの削除が不可能な場合は、設定プロパティー quarkus.arc.fail-on-intercepted-private-methodfalse に設定できます。この設定により、システムは以前の動作に戻り、警告のみが記録されます。

1.2.2.5. @AlternativePriority アノテーションの削除

このリリースでは、以前に非推奨になった @AlternativePriority アノテーションが削除されました。これを @Alternative および @Priority の両方のアノテーションに置き換えます。

例: 削除されたアノテーション

@AlternativePriority(1)

例: 置き換えられたアノテーション

@Alternative
@Priority(1)

非推奨となり、今後のリリースで削除される予定の io.quarkus.arc.Priority に代わり、@Priority アノテーションを付けた jakarta.annotation.Priority を使用します。どちらのアノテーションも同じように機能します。

1.2.2.6. テストの変更: Mockito サブクラス mockmaker の修正

このリリースでは、Mockito バージョン 5.x が更新されます。特に、Mockito は 5.0.0 リリース で、デフォルトの mockmaker を inline に切り替えました。

ただし、Quarkus 1.x 以降、Quarkus ユーザーが慣れ親しんだモック動作を維持し、広範なテストスイートのメモリーリーク を防ぐために、Quarkus 3.0 では、inline がフルサポートされるまで、これに代わって mockmaker を subclass に修正します。

inline mockmaker を強制する場合は、次の手順に従います。

  1. 次の除外を pom.xml に追加します。

    <dependency>
       <groupId>io.quarkus</groupId>
       <artifactId>quarkus-junit5-mockito</artifactId>
       <exclusions>
           <exclusion>
               <groupId>org.mockito</groupId>
               <artifactId>mockito-subclass</artifactId>
           </exclusion>
       </exclusions>
    <dependency>
  2. 依存関係に mockito-core を追加します。
  3. Mockito 5.3 では、mockito-inline アーティファクトが削除されました。これは依存関係から削除できます。

1.2.2.7. サポートされる Maven の最小バージョンの更新

Quarkus は、Maven 3.9 をサポートするために Maven プラグインのリファクタリングを実施しました。その結果、Quarkus がサポートする Maven の最小バージョンは 3.6.2 から 3.8.6 以降に引き上げられました。最新の改善点や機能を活用できるように、開発環境がこれに応じて更新されることを確認してください。

1.2.2.8. quarkus-bootstrap-maven-plugin の削除

この 3.2 リリースでは、以前に非推奨となった io.quarkus:quarkus-bootstrap-maven-plugin Maven プラグインが削除されました。

このプラグインは、Quarkus エクステンション開発専用です。したがって、カスタム Quarkus エクステンションを開発している場合は、アーティファクト ID を io.quarkus:quarkus-bootstrap-maven-plugin から io.quarkus:quarkus-extension-maven-plugin に変更する必要があります。

注記

この変更は、特にカスタムエクステンションの開発に関連します。標準アプリケーション開発の場合は、quarkus-maven-plugin プラグインを使用します。

1.2.2.9. Mutiny 2 の Java Flow への移行

Mutiny はリアクティブプログラミングライブラリーで、バージョン 1.x は org.reactivestream インターフェイスに基づいていますが、バージョン 2 は java.util.concurrent.Flow に基づいています。これらの API は同一ですが、パッケージ名が変更されています。

Mutiny は、Mutiny 2 (Flow API) とレガシーリアクティブストリーム API を備えた他のライブラリーの間をブリッジするアダプターを提供します。

1.2.3. Data

1.2.3.1. Panache メソッドによる Hibernate ORM の削除

この 3.2 リリースでは、以前に非推奨となった Panache メソッドによる Hibernate ORM および Kotlin の Panache メソッドによる Hibernate ORM からの以下のメソッドが削除されました。

  • io.quarkus.hibernate.orm.panache.PanacheRepositoryBase#getEntityManager(Class<?> clazz)
  • io.quarkus.hibernate.orm.panache.kotlin.PanacheRepositoryBase#getEntityManager(clazz: KClass<Any>)

代わりに、Panache.getEntityManager(Class<?> clazz) メソッドを使用してください。

1.2.3.2. Hibernate ORM の機能強化: IN 句パラメーターの自動パディング

この 3.2 リリースでは、Hibernate Object-Relational Mapping (ORM) エクステンションが変更され、デフォルト設定として自動 IN 句パラメーターパディングが組み込まれました。この改善により、IN 句を組み込んだクエリーのキャッシュ効率が向上します。

quarkus.hibernate-orm.query.in-clause-parameter-padding のプロパティー値を false に設定すると、以前の機能に戻してこの機能を非アクティブにできます。

1.2.3.3. 新しい依存関係: Hibernate Reactive 2 および Hibernate ORM 6.2

この 3.2 リリースでは、Quarkus は Hibernate Reactive 1 ではなく Hibernate Reactive 2 エクステンションに依存します。この変更は、以前のバージョンと互換性のない動作およびデータベーススキーマの期待項目におけるいくつかの変更を意味します。

変更のほとんどは、Hibernate ORM 5.6 ではなく Hibernate ORM 6.2 に依存する Hibernate Reactive 2 に関連しています。

重要

Hibernate Reactive 2 エクステンションは、Red Hat build of Quarkus 3.2 のテクノロジープレビューとして利用できます。

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

1.2.3.4. Hibernate Search の変更

GeoPoint フィールドの projectable および sortable のデフォルトの変更

この 3.2 リリースでは、Hibernate Search 6.2 で GeoPoint フィールドのデフォルトの処理方法が変更されています。

Hibernate Search マッピングに、projectable オプションのデフォルト値と、sortable オプションのデフォルト値または Sortable.NO を使用する GeoPoint フィールドが含まれているとします。その場合、これらのフィールドに doc 値が欠落しているため、Elasticsearch スキーマの検証は起動時に失敗します。

この失敗を防ぐには、次のいずれかの手順を実行します。

  • 関連する GeoPoint フィールドのマッピングアノテーションに projectable = Projectable.NO を追加して、以前のデフォルトに戻します。
  • Elasticsearch インデックスを再作成し、データベースを再インデックス化します。これを行う最も簡単な方法は、dropAndCreateSchemaOnStart(true) を指定して MassIndexer を使用することです。

詳細は、Hibernate Search 6.2.3.Final: Migration Guide from 6.1 の Data format and schema changes セクションを参照してください。

非推奨になった、または名前が変更された設定プロパティー

この 3.2 リリースでは、quarkus.hibernate-search-orm.automatic-indexing.synchronization.strategy プロパティーは非推奨となり、今後のバージョンでは削除される予定です。代わりに、quarkus.hibernate-search-orm.indexing.plan.synchronization.strategy プロパティーを使用してください。

また、quarkus.hibernate-search-orm.automatic-indexing.enable-dirty-check プロパティーは非推奨となり、今後のバージョンで削除される予定です。これに置き換わる代替のプロパティーはありません。削除後は、トランザクションがオブジェクトのフィールドを変更した後、検索によって常に再インデックス化がトリガーされることが計画されています。つまり、トランザクションによってフィールドが "ダーティー" になった場合です。

詳細は、Hibernate Search 6.2.3.Final: Migration Guide from 6.1 の Configuration changes セクションを参照してください。

この 3.2 リリースでは、Quarkus は ValidatorFactory インスタンスの手動作成をサポートしていません。代わりに、Validation.buildDefaultValidatorFactory() メソッドを使用する必要があります。このメソッドは、コンテキストと依存性注入 (CDI) を通じて注入した Quarkus によって管理される ValidatorFactory インスタンスを返します。この変更の主な理由は、ValidatorFactory がネイティブ実行可能ファイルで動作するように慎重に作成する必要があることです。このリリースより前では、機能させることができる場合は、ValidatorFactory インスタンスを手動で作成し、自分で処理することができました。この変更は、独自の ValidatorFactory を作成するコンポーネントとの互換性を向上させることを目的としています。

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

1.2.3.6. Quartz ジョブのクラス名の変更

Java Database Connectivity (JDBC) を使用して Quartz エクステンション のジョブをデータベースに保存している場合は、次のクエリーを実行して、JOB_DETAILS テーブル内のジョブクラス名を更新します。

UPDATE JOB_DETAILS SET JOB_CLASS_NAME = 'io.quarkus.quartz.runtime.QuartzSchedulerImpl$InvokerJob' WHERE JOB_CLASS_NAME = 'io.quarkus.quartz.runtime.QuartzScheduler$InvokerJob';

1.2.3.7. QuarkusTransaction.run メソッドと QuarkusTransaction.call メソッドが非推奨に

QuarkusTransaction.run メソッドと QuarkusTransaction.call メソッドは非推奨となり、より明示的な新しいメソッドが採用されました。

これらの非推奨のメソッドに依存するコードを次のように更新します。

更新前

QuarkusTransaction.run(() -> { ... });
QuarkusTransaction.call(() -> { ... });

更新後

QuarkusTransaction.requiringNew().run(() -> { ... });
QuarkusTransaction.requiringNew().call(() -> { ... });

更新前

QuarkusTransaction.run(QuarkusTransaction.runOptions()
        .semantic(RunOptions.Semantic.REQUIRED),
        () -> { ... });
QuarkusTransaction.call(QuarkusTransaction.runOptions()
        .semantic(RunOptions.Semantic.REQUIRED),
        () -> { ... });

更新後

QuarkusTransaction.joiningExisting().run(() -> { ... });
QuarkusTransaction.joiningExisting().call(() -> { ... });

更新前

QuarkusTransaction.run(QuarkusTransaction.runOptions()
        .timeout(10)
        .exceptionHandler((throwable) -> {
            if (throwable instanceof SomeException) {
               return RunOptions.ExceptionResult.COMMIT;
            }
            return RunOptions.ExceptionResult.ROLLBACK;
        }),
        () -> { ... });
QuarkusTransaction.call(QuarkusTransaction.runOptions()
        .timeout(10)
        .exceptionHandler((throwable) -> {
            if (throwable instanceof SomeException) {
               return RunOptions.ExceptionResult.COMMIT;
            }
            return RunOptions.ExceptionResult.ROLLBACK;
        }),
        () -> { ... });

更新後

QuarkusTransaction.requiringNew()
        .timeout(10)
        .exceptionHandler((throwable) -> {
            if (throwable instanceof SomeException) {
               return RunOptions.ExceptionResult.COMMIT;
            }
            return RunOptions.ExceptionResult.ROLLBACK;
        })
        .run(() -> { ... });
QuarkusTransaction.requiringNew()
        .timeout(10)
        .exceptionHandler((throwable) -> {
            if (throwable instanceof SomeException) {
               return RunOptions.ExceptionResult.COMMIT;
            }
            return RunOptions.ExceptionResult.ROLLBACK;
        })
        .call(() -> { ... });

詳細は、USING TRANSACTIONS IN QUARKUS ガイドの Programmatic approach セクションを参照してください。

1.2.3.8. Narayana トランザクションマネージャープロパティーの名前の変更

この 3.2 リリースでは、quarkus.transaction-manager.object-store-directory 設定プロパティーの名前が quarkus.transaction-manager.object-store.directory に変更されました。古いプロパティー名を新しいプロパティー名に置き換えて、設定を更新します。

1.2.4. メッセージング

1.2.4.1. SmallRye Reactive Messaging からの vertx-kafka-client 依存関係の削除

このリリースでは、以前に非推奨となった smallrye-reactive-messaging-kafka エクステンションの vertx-kafka-client 依存関係が削除されます。クライアント実装には使用されませんでしたが、vertx-kafka-client は、io.vertx.kafka.client.serialization パッケージから io.vertx.core.buffer.Bufferio.vertx.core.json.JsonObject、および io.vertx.core.json.JsonArray 型のデフォルトの Kafka Serialization and Deserialization (SerDes) を提供しました。

この依存関係が必要な場合は、io.quarkus.kafka.client.serialization パッケージから前述の型の SerDes を取得できます。

1.2.5. ネイティブ

1.2.5.1. ネイティブコンパイル - ネイティブ実行可能ファイルと .so ファイル

この 3.2 リリースでは、GraalVM/Mandrel の変更は、Java Abstract Window Toolkit (AWT) エクステンションなどの .so ファイルに依存するエクステンションの使用に影響します。

これらのエクステンションを使用する場合は、対応する .so ファイルをネイティブコンテナーに追加またはコピーする必要があります。以下に例を示します。

COPY --chown=1001:root target/*.so /work/
COPY --chown=1001:root target/*-runner /work/application
注記

これに関連して、AWT エクステンションは、GUI 機能ではなく、ヘッドレスサーバー側のイメージ処理機能を提供します。

1.2.5.2. ネイティブコンパイル - 不足する CPU 機能の回避

この 3.2 リリースでは、最近のマシンでネイティブ実行可能ファイルをビルドし、古いマシンで実行すると、アプリケーションの起動時に次のエラーが発生する可能性があります。

The current machine does not support all of the following CPU features that are required by the image: [CX8, CMOV, FXSR, MMX, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, POPCNT, LZCNT, AVX, AVX2, BMI1, BMI2, FMA].
Please rebuild the executable with an appropriate setting of the -march option.

このエラーメッセージは、ネイティブコンパイルで、アプリケーションを実行している CPU でサポートされていない高度な命令セットが使用されたことを意味します。この問題を回避するには、application.properties ファイルに次の行を追加します。

quarkus.native.additional-build-args=-march=compatibility

次に、ネイティブ実行可能ファイルを再ビルドします。この設定により、ネイティブコンパイルで古い命令セットの使用が強制され、互換性の可能性は高まりますが、最適化は低下します。

ターゲットアーキテクチャーを明示的に定義するには、native-image -march=list を実行して、サポートされる構成のリストを取得します。次に、ターゲットアーキテクチャーを指定します。以下に例を示します。

quarkus.native.additional-build-args=-march=x86-64-v4

古い AMD64 ホストでこの問題が発生している場合は、-march=compatibility を使用する前に -march=x86-64-v2 を試してください。

ネイティブイメージビルドオプション に関する GraalVM ドキュメントには、次のように記載されています: "[the -march parameter generates] instructions for a specific machine type. [This parameter] defaults to x86-64-v3 on AMD64 and armv8-a on AArch64.Use -march=compatibility for best compatibility, or -march=native for best performance if a native executable is deployed on the same machine or on a machine with the same CPU features.To list all available machine types, use -march=list."

注記

-march パラメーターは、GraalVM 23 以降でのみ使用できます。

1.2.5.3. テストの変更: 一部のアノテーションの削除

この 3.2 リリースでは、以前は非推奨だった @io.quarkus.test.junit.NativeImageTest および @io.quarkus.test.junit.DisabledOnNativeImageTest アノテーションが、rimage::images/ref_changes-that-affect-backward-compatibility-88d2f.png[] になりました。削除されたプロパティーは、新しいプロパティーに置き換えてださい。

Expand
表1.3 削除されたアノテーションと新しいアノテーション
削除されたアノテーション新しいアノテーション

@io.quarkus.test.junit.NativeImageTest

@io.quarkus.test.junit.QuarkusIntegrationTest

@io.quarkus.test.junit.DisabledOnNativeImageTest

@io.quarkus.test.junit.DisabledOnIntegrationTest

置き換えられたアノテーションは、削除されたアノテーションと機能的に同等です。

1.2.6. 可観測性

1.2.6.1. 非推奨の OpenTracing ドライバーが OpenTelemetry に置き換えられる

この 3.2 リリースでは、OpenTracing ドライバーのサポートが非推奨となりました。OpenTracing ドライバーの削除は、今後の Quarkus リリースで計画されています。

この 3.2 リリースでは、SmallRye GraphQL エクステンションが OpenTracing インテグレーションを OpenTelemetry に置き換えました。その結果、OpenTracing を使用する場合、エクステンションは GraphQL 操作のスパンを生成しなくなります。

また、このリリースでは、quarkus.smallrye-graphql.tracing.enabled 設定プロパティーは廃止され、削除されました。代わりに、OpenTelemetry エクステンションが存在する場合、SmallRye GraphQL エクステンションは自動的にスパンを生成します。

OpenTelemetry を使用するように Quarkus アプリケーションを更新して、今後の Quarkus リリースとの互換性を維持します。

1.2.6.2. Micrometer のデフォルトのメトリクスフォームが Prometheus に準拠する

この 3.2 リリースでは、Micrometer エクステンションは、Prometheus 標準に準拠して、デフォルトで application/openmetrics-text フォームでメトリクスをエクスポートします。この変更により、データの読み取りと解釈が容易になります。

以前のフォームでメトリクスを取得する場合は、Accept リクエストヘッダーを text/plain に変更できます。curl コマンドを使用すると、以下のようになります。

curl -H "Accept: text/plain" localhost:8080/q/metrics/

1.2.7. セキュリティー

Cross-Origin Resource Sharing (CORS) フィルターのデフォルトの動作が大幅に変更されました。以前のリリースでは、CORS フィルターが有効になっている場合、デフォルトですべてのオリジンがサポートされていました。この 3.2 リリースでは、すべてのオリジンのサポートがデフォルトで有効化されなくなりました。すべてのオリジンを許可する場合は、そのように明示的に設定する必要があります。

徹底的な評価の後、すべてのオリジンでサポートが必要であると判断した場合は、次の方法でシステムを設定します。

quarkus.http.cors=true
quarkus.http.cors.origins=/.*/

同一オリジンリクエストは、quarkus.http.cors.origins 設定を必要とせずにサポートを受けられます。したがって、quarkus.http.cors.origins の調整は、信頼できるサードパーティーのオリジンリクエストを許可する場合にのみ必須となります。このような状況では、すべてのオリジンを有効にすると、不必要なリスクが生じる可能性があります。

警告

最適なシステムセキュリティーを維持するために、この設定は注意して使用してください。

1.2.7.2. OpenAPI CORS サポートの変更

この 3.2 リリースでは、OpenAPI は Cross-Origin Resource Sharing (CORS) 設定を変更し、デフォルトでワイルドカード (*) オリジンサポートを有効化しなくなりました。この変更は、OpenAPI ドキュメントの漏洩の可能性を防ぎ、アプリケーションの全体的なセキュリティーを強化するのに役立ちます。

開発モードでワイルドカードオリジンのサポートを有効にする ことはできますが、潜在的なセキュリティーへの影響を考慮することが重要です。実稼働環境では、アプリケーションがセキュリティーの脅威にさらされることになるため、すべてのオリジンを有効にしないでください。CORS 設定が、実稼働環境で推奨されるセキュリティーのベストプラクティスと一致していることを確認してください。

1.2.7.3. デフォルトでの OIDC セッション Cookie の暗号化

この 3.2 リリースでは、OpenID Connect (OIDC) 認証コードフローの完了後に作成される OIDC セッション Cookie が、デフォルトで暗号化されます。ほとんどのシナリオでは、この変化に気づくことはほとんどありません。

ただし、mTLS または private_key_jwt 認証方法 (OIDC クライアントの秘密鍵が JSON Web Token (JWT) に署名する) が Quarkus と OIDC プロバイダーの間で使用される場合、メモリー内暗号化キーが生成されます。このキーの生成により、特に多くのリクエストを処理するアプリケーションでは、一部の Pod がセッション Cookie の復号化に失敗する可能性があります。この状況は、Cookie を復号化しようとしている Pod が、それを暗号化した Pod ではない場合に発生する可能性があります。

このような問題が発生した場合は、32 文字の暗号化シークレットを登録してください。以下に例を示します。

quarkus.oidc.token-state-manager.encryption-secret=eUk1p7UB3nFiXZGUXi0uph1Y9p34YhBU

暗号化されたセッション Cookie は、4096 バイトを超える可能性があるため、一部のブラウザーがそれを無視する可能性があります。この問題が発生した場合は、次の手順を 1 つ以上試してください。

  • quarkus.oidc.token-state-manager.split-tokens=true を設定すると、ID、アクセス、およびリフレッシュトークンが個別の Cookie に保存されます。
  • UserInfo をリクエストしたりダウンストリームサービスに伝播したりするためのロールのソースとしてアクセストークンを使用する必要がない場合は、quarkus.oidc.token-state-manager.strategy=id-refresh-tokens を設定します。
  • 代替優先度を 1 に設定して、カスタム quarkus.oidc.TokenStateManager コンテキストと依存性注入 (CDI) Bean を登録します。

アプリケーションユーザーが信頼できるネットワーク内から Quarkus アプリケーションにアクセスする場合は、次の設定を適用してセッション Cookie 暗号化を無効にします。

quarkus.oidc.token-state-manager.encryption-required=false

1.2.7.4. OIDC セッション Cookie のデフォルト SameSite 属性が Lax に設定される

この 3.2 リリースでは、Quarkus OpenID Connect (OIDC) エクステンションの場合、セッション Cookie の SameSite 属性がデフォルトで Lax に設定されます。

Quarkus の以前のリリースの一部では、OIDC セッション Cookie の SameSite 属性がデフォルトで Strict に設定されていました。この設定により、さまざまなブラウザーがセッション Cookie をどのように処理するかが予測不能になりました。

1.2.7.5. OIDC ID トークンオーディエンスクレームがデフォルトで検証される

この 3.2 リリースでは、OpenID Connect (OIDC) ID トークン aud (audience) クレームがデフォルトで検証されます。このクレームは、OIDC 仕様の要求に従って、設定された quarkus.oidc.client-id プロパティーの値と等しくなければなりません。

予期される ID トークンオーディエンス値をオーバーライドするには、quarkus.oidc.token.audience 設定プロパティーを設定します。ID トークン aud クレームを設定しない非準拠の OIDC プロバイダーを扱う場合は、quarkus.oidc.token.audienceany に設定できます。

警告

quarkus.oidc.token.audienceany に設定すると、3.2 アプリケーションのセキュリティーが低下します。

1.2.7.6. JWT キーとキーストアのデフォルトのパスワードの削除

このリリースより前は、Quarkus は JSON Web Token (JWT) キーとキーストアのデフォルトのパスワードとして password を使用していました。この 3.2 リリースでは、このデフォルト値は削除されました。

デフォルトのパスワードをまだ使用している場合は、application.properties ファイル内の次のプロパティーの password を置き換える新しい値を設定します。

quarkus.oidc-client.credentials.jwt.key-store-password=password
quarkus.oidc-client.credentials.jwt.key-password=password

1.2.8. Web

1.2.8.1. RESTEasy Reactive マルチパートへの変更

この 3.2 リリースでは、次の変更が RESTEasy Reactive のマルチパートサポートに影響します。

  • このリリースより前は、構文 @RestForm List<FileUpload> all を使用して、パラメーター名に関係なくすべてのファイルのアップロードをキャッチできましたが、これは曖昧で直感的ではありませんでした。現在、このフォームは、他の型の他のすべてのフォーム要素と同様に、all という名前のパラメーターのみを取得します。また、名前に関係なく、すべてのパラメーターを取得するには、@RestForm(FileUpload.ALL) List<FileUpload> all というフォームを使用する必要があります。
  • マルチパートフォームパラメーターのサポートが @BeanParam に追加されました。@MultipartForm アノテーションは非推奨になりました。@MultipartForm の代わりに @BeanParam を使用します。
  • @BeanParam はオプションとなり、@Rest* または @*Param アノテーションが付けられたフィールドを持つアノテーションの付いていないメソッドパラメーターに対して暗黙的に使用できるようになりました。
  • マルチパート要素は、@MultipartForm アノテーション付きクラス内にカプセル化されることに限定されなくなり、メソッドのエンドポイントパラメーターおよびエンドポイントクラスフィールドとして使用できます。
  • マルチパート要素は、FileUploadPathFilebyte[]、または InputStream 型でない限り、デフォルトで @PartType(MediaType.TEXT_PLAIN) MIME 型になります。
  • MediaType.TEXT_PLAIN MIME 型のマルチパート要素は、通常の ParamConverter インフラストラクチャーを使用してデシリアライズされるようになりました。このリリースより前は、デシリアライズには MessageBodyReader が使用されていました。
  • FileUploadPathFilebyte[]、または InputStream 型のマルチパート要素は特殊なケースであり、MessageBodyReader クラスや ParamConverter クラスではなく、RESTEasy Reactive エクステンションによってデシリアライズされます。
  • 他の明示的に設定された MIME 型のマルチパート要素は、引き続き適切な MessageBodyReader インフラストラクチャーを使用します。
  • マルチパート要素を List でラップして、同じ名前のパートのすべての値を取得できるようになりました。
  • @RestForm または @FormParam パラメーターを含むクライアント呼び出しは、FilePathBufferMulti<Byte>、または byte[] 型 (この場合のデフォルトは MediaType.MULTIPART_FORM_DATA コンテンツ型) でない限り、デフォルトで MediaType.APPLICATION_FORM_URLENCODED コンテンツ型になります。
  • クラス org.jboss.resteasy.reactive.server.core.multipart.MultipartFormDataOutput は、org.jboss.resteasy.reactive.server.multipart.MultipartFormDataOutput に移動されました。
  • クラス org.jboss.resteasy.reactive.server.core.multipart.PartItem は、org.jboss.resteasy.reactive.server.multipart.PartItem に移動されました。
  • クラス org.jboss.resteasy.reactive.server.core.multipart.FormData.FormValue は、org.jboss.resteasy.reactive.server.multipart.FormValue に移動されました。
  • REST Client は、Jackson に関連付けられたサーバー固有の MessageBodyReader クラスと MessageBodyWriter クラスを使用しなくなりました。このリリースより前は、REST Client がこれらのクラスを意図せずに使用していました。その結果、quarkus-resteasy-reactive-jackson および quarkus-rest-client-reactive の両方のエクステンションを使用するアプリケーションには、quarkus-rest-client-reactive-jackson エクステンションを含める必要があります。

1.2.8.2. 強化された JAXB エクステンション制御

JAXB エクステンションは、JAXB アノテーションを使用するクラスを検出し、それらをデフォルトの JAXBContext インスタンスに登録します。このリリースより前は、クラスと JAXB の間の問題または競合により、実行時に JAXB 例外がトリガーされ、この問題のトラブルシューティングに役立つ詳細な説明が提供されていました。ただし、ビルド段階でこれらの競合に事前に対処することができます。

このリリースでは、ビルド時に JAXBContext インスタンスを検証できる機能が追加され、開発サイクルの早い段階で JAXB エラーを検出して修正できるようになりました。

たとえば、次のコードブロックに示すように、両方のクラスをデフォルトの JAXBContext インスタンスにバインドすると、必然的に JAXB 例外が発生します。これは、クラスが異なるパッケージに存在しているにもかかわらず、Model という同じ名前を共有しているためです。この同じ名前により競合が発生し、例外が発生します。

package org.acme.one;

import jakarta.xml.bind.annotation.XmlRootElement;

@XmlRootElement
public class Model {
    private String name1;

    public String getName1() {
        return name1;
    }

    public void setName1(String name1) {
        this.name1 = name1;
    }
}

package org.acme.two;

import jakarta.xml.bind.annotation.XmlRootElement;

@XmlRootElement
public class Model {
    private String name2;

    public String getName2() {
        return name2;
    }

    public void setName2(String name2) {
        this.name2 = name2;
    }
}

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

quarkus.jaxb.validate-jaxb-context=true

さらに、このリリースでは、quarkus.jaxb.exclude-classes プロパティーが追加されています。このプロパティーを使用すると、JAXBContext へのバインドから除外するクラスを指定できます。完全修飾クラス名のコンマ区切りリストまたはパッケージのリストを指定できます。

たとえば、前の例の競合を解決するには、クラスの 1 つまたは両方を除外します。

quarkus.jaxb.exclude-classes=org.acme.one.Model,org.acme.two.Model

または、パッケージ内のすべてのクラスを除外することもできます。

quarkus.jaxb.exclude-classes=org.acme.*
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る