24.0.0.9 の MicroProfile Telemetry 2.0 などで監視を簡素化

Mavenを使用している場合は、pom.xml ファイルに以下を含めます。

または、Gradle の場合は、build.gradle ファイルに次の内容を含めます。

または、コンテナ イメージ を使用している場合:

または、ダウンロード・ページをご覧ください。

IntelliJ IDEA、Visual Studio Code、または Eclipse IDEを使用している場合は、オープンソースの Liberty 開発者ツール を活用して、IDE 内から効果的な開発、テスト、デバッグ、アプリケーション管理を行うこともできます。

このリリースでは、MicroProfile Telemetry 2.0 機能 (mpTelemetry-2.0) により、OpenTelemetryを使用して標準化された方法でログ、メトリクス、トレースを収集およびエクスポートすることで、Javaアプリケーションの可観測性を向上させます。以前のバージョンのMicroProfile Telemetryは、分散トレースのみを管理できました。

利用可能な構成プロパティに関する詳細については、MicroProfile Configプロパティ: MicroProfile Telemetry を参照してください。

MicroProfile Telemetryを使用して、標準化された方法でメトリクス、ログ、トレースを管理する方法については、Enable observability with MicroProfile Telemetry を参照してください。

MicroProfile Telemetry 2.0は最新のOpenTelemetryテクノロジーを提供します。分散トレース に加えて、この機能はOpenTelemetryを使用してメトリクスとログを収集およびエクスポートできるようになりました。 MicroProfile Telemetry を使用したメトリック と ログ の管理については、次のセクションを参照してください。

プライバシーを向上させ追跡を減らすために、Google Chromeは2025年にサードパーティCookieを段階的に廃止すると発表しました。その後、2024年7月22日時点で、Chromeは規制上の懸念から段階的廃止計画を撤回する可能性があると述べました。代わりに、ユーザーはブラウザでサードパーティCookieをブロックするオプションを選択できるようになります。サードパーティCookieを前提に設計されたサイトの一部は、サードパーティCookieのブロックを選択するブラウザによって正しく動作しなくなることがあります。Chromeは、サイトが影響を受けているかどうかをテストするためのドキュメントを提供しています。この変更を緩和するためのオプションの1つとして、CHIPS（独立したパーティション状態を持つCookie）という手法があります。

まず、サードパーティ (クロスサイト) Cookie に関する背景情報をいくつか紹介します。

トップレベル サイト X が iframe などの別のサイト Z を埋め込む場合、埋め込まれたサイト Z によって設定された Cookie は、トップレベル サイト Y など、サイト Z を埋め込む他のサイトと共有される可能性があります。この脆弱性は、Z サイト キーの下の Cookie jar に配置されている Cookie が原因で発生します。このシナリオでは、Cookie が SameSite=None としてラベル付けされていると想定しています。これは、Cookie が Lax または Strict に設定されている場合は共有されないためです。

Chrome は、制限のあるサードパーティ Cookie の回避策として、Cookie jar を分割する「パーティション化」Cookie 属性を提供します。Cookie は Z サイト キー内に保存されるのではなく、X や Y などのトップレベル サイトの下にもキーが付けられます。このように、X が Z を埋め込み、Y が Z を埋め込む場合、Z の Cookie は X と Y の間で共有されません。

Partitioned 属性を使用して、Cookie をパーティション分割するかどうかを指定できます。Cookie に SameSite=None 属性がない場合、これは Lax として扱われるため、Chrome および Chromium ベースのブラウザによってブロックされます。

パーティション属性の設定はオプトインであり、SameSite 設定とほぼ同じように動作します。samesite チャネル設定はすべての Cookie に適用されますが、httpSession および webAppSecurity 設定はそれぞれの Cookie に適用されます。httpSession および webAppSecurity 設定はチャネル設定よりも優先されることに注意してください。これら 2 つの属性のデフォルト値は defer で、チャネル設定に従うことを意味します。チャネル設定に関しては、デフォルト値は false で、Partitioned 属性が追加されないことを意味します。

Partitioned 属性を宣言するために使用する構成に応じて、Liberty は 3 つの属性のいずれかを使用します。

次の例は、server.xml ファイルの httpSession 属性で HTTP セッション Cookieの cookiePartitioned 属性を設定する方法を示しています。

次の例は、server.xml ファイルの webAppSecurity 属性で LTPA および JWT セキュリティ Cookieの partitionedCookie 属性を設定する方法を示しています。

次の例は、server.xml ファイルの httpEndpoint 属性で他の Cookie の partitioned 属性を設定する方法を示しています。

あるいは、次の 2 つの HttpServletResponse API で Set-Cookie ヘッダーを使用して Partitioned を設定することもできます。

詳しい情報やビジュアル例については、GitHubのCHIPS (Cookies Having Independent Partitioned State) をご覧ください。

24.0.0.8 では、Open Liberty にバージョンレス Java EE および Jakarta EE 機能が導入されました。これらの新しいバージョンレス機能により、どの機能バージョンを使用するかを知らなくても、機能を簡単に使用できます。バージョンレス機能の最初のリリースには、特定の Java EE または Jakarta EE コンポーネント仕様の独自の実装を提供できる Container 機能は含まれていませんでした。このような機能の例として、facesContainer-4.0 があります。

24.0.0.9 では、Open Liberty は不足している Container 機能に対してバージョンレス機能を追加します。次のバージョンレス機能が追加されました。

次の server.xml 構成ファイルは、バージョンレス機能 jpaContainer、jsfContainer、jsonbContainer、および jsonpContainer を備えた Java EE プラットフォーム javaee-8.0 を使用します。

詳細を学び、利用可能なプラットフォームやバージョンレス機能の完全なコレクションについては、Open Liberty ドキュメントをご覧ください。今後のリリースでは、さらに多くのバージョンレス機能やプラットフォームが登場予定です。

過去のセキュリティ脆弱性修正の一覧については、セキュリティ脆弱性 (CVE) リスト を参照してください。

Open Liberty 24.0.0.9は、Maven, Gradle, Docker, and as a downloadable archiveのリンクからお試しいただけます。