移行ガイド

Red Hat JBoss Enterprise Application Platform 7 向け

Red Hat Customer Content Services

Copyright © 2016 Red Hat, Inc.

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack Logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

概要

本ガイドでは、以前のバージョンの Red Hat JBoss Enterprise Application Platform からアプリケーションを移行する方法を説明します。

第1章 はじめに

Red Hat JBoss Enterprise Application Platform 7

Red Hat JBoss Enterprise Application Platform 7 (JBoss EAP) は、オープンな標準に基いて構築され、Java Enterprise Edition 7 の仕様に準拠するミドルウェアプラットフォームです。メッセージング、高可用性クラスタリングなどの技術が WildFly Application Server 10 と統合されます。

JBoss EAP には、必要な場合にだけサービスを有効にできるモジュール構造が含まれ、サービスの起動時間が短縮されます。

管理コンソールと管理コマンドラインインターフェース (CLI) により、XML 設定ファイルの編集が不要になり、タスクをスクリプト化および自動化する機能が追加されました。

JBoss EAP は、JBoss EAP インスタンスに対してスタンドアロンサーバーと管理対象ドメインの 2 つの操作モードを提供します。スタンドアロンサーバー操作モードでは、実行している JBoss EAP を 1 つのサーバーインスタンスとして表します。管理対象ドメイン操作モードでは、1 つの制御ポイントから複数の JBoss EAP インスタンスを管理できます。

また、JBoss EAP には、セキュアでスケーラブルな Java EE アプリケーションの迅速な開発を可能にする API と開発フレームワークが含まれます。

移行ガイド

本ガイドの目的は、JBoss Enterprise Application Platform 6 のアプリケーションを JBoss Enterprise Application Platform 7 で正常に実行しデプロイするために必要な変更を説明することです。また、デプロイメントおよび実行時の問題を解決する方法や、アプリケーションの動作が変わらないようにする方法ついて取り上げます。これは新しいプラットフォームへ移行する最初の一歩となります。アプリケーションが正常にデプロイされ実行されたら、JBoss EAP 7 の新機能を使用するために各コンポーネントのアップグレードを計画することができます。

移行およびアップグレード

メジャーアップグレード.  JBoss EAP 6 から JBoss EAP 7 など、アプリケーションのメジャーリリースごとにメジャーアップグレードまたは移行が必要になります。本ガイドではこのような移行について取り上げます。アプリケーションが Java EE 仕様に準拠し、非推奨の API にアクセスせず、プロプラエタリーコードを含まない場合、アプリケーションコードを変更せずにアプリケーションを JBoss EAP 7 で実行できる可能性があります。しかし、JBoss EAP 7 ではサーバー設定が変更になり、サーバー設定を移行する必要があります。

マイナーアップデート.  JBoss EAP では、定期的にポイントリリースが提供されます。これは、バグ修正、セキュリティーの修正、および新機能が含まれるマイナーアップデートです。JBoss EAP の Patching and Upgrading Guide には、ポイントリリース間のアップグレード (JBoss EAP 7.0 から JBoss EAP 7.1 など) 方法が説明されています。

累積パッチ.  JBoss EAP では、バグおよびセキュリティーの修正が含まれる累積パッチも定期的に提供されます。累積パッチのリリースごとに、リリース番号の最後の数字が 1 ずつ増えます (例: 7.0.0 から 7.0.1)。パッチインストールの詳細は、JBoss EAP の Patching and Upgrading Guide に記載されています。

本書における EAP_HOME の使用

本書では、変数 EAP_HOME を使用して JBoss EAP へのパスを示しています。この変数は JBoss EAP インストールへの実際のパスに置き換えてください。

ZIP インストール方法で JBoss EAP をインストールした場合、インストールディレクトリーは、ZIP アーカイブを抽出した jboss-eap-7.0 ディレクトリーとなります。

RPM インストール方法で JBoss EAP をインストールした場合、インストールディレクトリーは /opt/rh/eap7/root/usr/share/wildfly/ になります。

インストーラーを使用して JBoss EAP をインストールした場合、EAP_HOME のデフォルトのパスは ${user.home}/EAP-7.0.0 になります。

Red Hat Enterprise Linux、Solaris、および HP-UX では、/home/USER_NAME/EAP-7.0.0/ になります。

Microsoft Windows の場合、C:\Users\USER_NAME\EAP-7.0.0\ になります。

JBoss Developer Studio インストーラーを使用して JBoss EAP サーバーをインストールおよび設定した場合、EAP_HOME のデフォルトのパスは ${user.home}/jbdevstudio/runtimes/jboss-eap になります。

Red Hat Enterprise Linux の場合、/home/USER_NAME/jbdevstudio/runtimes/jboss-eap/ になります。

Microsoft Windows の場合、C:\Users\USER_NAME\jbdevstudio\runtimes\jboss-eap または C:\Documents and Settings\USER_NAME\jbdevstudio\runtimes\jboss-eap\ になります。

注記

EAP_HOME は環境変数ではありません。JBOSS_HOME がスクリプトで使用される環境変数です。

第2章 移行の準備

準備の概要

JBoss EAP 7 では、JBoss EAP 6 のアプリケーションに後方互換性を提供する努力をしていますが、JBoss EAP 7 で非推奨なった機能や削除された機能がアプリケーションによって使用される場合は、アプリケーションコードの変更が必要になることがあります。

さらに、本リリースには JBoss EAP 7 アプリケーションのデプロイメントに影響する可能性がある複数の変更が含まれています。移行について調査し、計画を立ててからアプリケーションを移行することが推奨されます。

Java EE 7 の機能を理解するようにしてください。

JBoss EAP 7 の新機能を確認してください。

非推奨の機能およびサポートされない機能のリストを確認してください。

JBoss EAP 7 のスタートガイドをお読みください。

移行に便利なツールを確認してください。

機能の変更、開発の資料、および移行に便利なツールについて理解したら、アプリケーションとサーバー設定を評価し、JBoss EAP 7 で実行するために必要な変更について判断します。

Java EE 7 機能の確認

Java EE 7 には、プライベートおよびパブリッククラウドでの機能が充実したアプリケーションの開発や実行を容易にする多くの改良点が含まれています。JBoss EE 7 は、HTML5、WebSocket、JSON、Batch、および Cocurrency Utilities などの新機能や最新の標準が導入されています。アップデートには JPA 2.1、JAX-RS 2.0、Servlet 3.1、Expression Language 3.0、JMS 2.0、JSF 2.2、EJB 3.2、CDI 1.2、および Bean Validation 1.1 が含まれます。

チュートリアルなどの Java EE 7 に関する詳細は、オラクルの Web サイトにある Java EE at a Glance を参照してください。

JBoss EAP 7 の新機能

JBoss EAP 7 には、以前のリリースから大幅に改善されたアップグレードや改良点が含まれています。

Java EE 7

JBoss EAP 7 は Java EE 7 の認定実装で、 Web Profile と Full Profile の両方に準拠しています。また、CDI 1.2 および Web Sockets 1.1 の最新のイテレーションもサポートします。

Undertow

Undertow は軽量で柔軟性のあるパフォーマンスに優れた新しい Web サーバーです。JBoss Web は Undertow に置き換えられました。Undertow は Java で書かれ、スループットとスケーラビリティーを最大にするよう設計されています。新しい HTTP/2 標準などの最新の Web 技術をサポートします。

Apache ActiveMQ Artemis

Apache ActiveMQ Artemis は JBoss EAP 7 の新しいビルトインメッセージングプロバイダーです。この Apache サブプロジェクトは HornetQ から寄贈されたコードをベースにし、証明された非ブロッキングアーキテクチャーを基に優れたパフォーマンスを実現します。

IronJacamar 1.2

最新の Iron Jacamar は、安定性が高く、機能が充実したサポートを JCA および DataSources に提供します。

JBossWS 5

JBossWS 5 はこれまでのバージョンから大きく飛躍し、新機能や改良されたパフォーマンスを JBoss EAP 7 Web Services に提供します。

RESTEasy 3

JBoss EAP 7 には最新の RESTEasy が含まれています。JSON Web Encryption、Jackson、YAML、JSON-P、Jettison などの便利な拡張を提供し、標準の Java EE REST API (JAX-RS 2.0) を越えた機能性を実現します。

OpenJDK ORB

JBoss EAP では、JacORB IIOP 実装が OpenJDK ORB のダウンストリームブランチに置き換えられ、JVM ORB と Java EE RI との相互運用性が向上されました。

機能が充実したクラスタリング

JBoss EAP 7 ではクラスタリングのサポートが大幅にリファクタリングされ、アプリケーションのアクセスを可能にするパブリック API が複数含まれています。

ポートの削減

JBoss EAP 7 では HTTP のアップグレードを利用し、ほぼすべてのプロトコルが管理ポート (9990) とアプリケーションポート (8080) の 2 つの HTTP ポート上で多重化されます。

ロギングの強化

管理 API が、サーバー上で利用可能なログファイルをリストおよび表示する機能をサポートするようになりました。また、デフォルトのパターンフォーマッター以外のカスタムフォーマッターを定義する機能もサポートするようになりました。さらに、デプロイメントのロギング設定も大幅に向上されました。

新機能の完全一覧については、JBoss EAP 7 リリースノートの 新機能および改良された機能を参照してください。

非推奨および未サポート機能リストの確認

アプリケーションを移行する前に、以前のリリースの JBoss EAP では使用可能で、本リリースで非推奨またはサポート対象外になった機能があることに注意する必要があります。

メンテナンスコストの高さ、コミュニティーでの関心の低さ、および高性能な代替ソリューションの存在などが理由で、一部の技術がサポート対象外になりました。サポートされない機能の一部を以下に示します。

EJB エンティティー Bean

EJB エンティティー Bean はサポート対象外になりました。アプリケーションが EJB エンティティー Bean を使用する場合は、パフォーマンスや柔軟性が高い API を提供する JPA を使用するようコードを移行してください。

JAX-RPC

JAX-WS はより正確で完全なソリューションを提供するため、JAX-RPC 用に書かれたコードは JAX-WS を使用するよう移行する必要があります。

JSR-88

すべての Java EE プラットフォーム製品でアプリケーションを設定およびデプロイするために複数のプロバイダーからツールを有効化するコントラクトを定義する、Java EE Application Deployment API 仕様 (JSR-88) は広く採用されませんでした。管理コンソール、管理 CLI、デプロイメントスキャナー、Maven など、アプリケーションのデプロイメントでは JBoss EAP がサポートする他のオプションを使用する必要があります。

汎用 JMS リソースアダプター

汎用 JMS リソースアダプターを設定して JMS プロバイダーに接続する機能は、JBoss EAP 7 ではサポート対象外になりました。

非推奨の機能およびサポートされない機能の完全リストは、JBoss EAP 7 リリースノートのサポートされない機能および非推奨の機能を参照してください。

JBoss EAP 7 スタートガイドの確認

JBoss EAP のスタートガイドを必ず確認してください。このガイドには、以下の重要な情報が含まれています。

JBoss EAP のダウンロードおよびインストール方法

Red Hat JBoss Developer Studio のダウンロードおよびインストール方法

開発環境に応じた Maven の設定方法、プロジェクト依存関係の管理方法、および JBoss EAP の Bill of Material (BOM) アーティファクトを使用するようプロジェクトを設定する方法。

製品に同梱されたクイックスタートサンプルアプリケーションのダウンロードおよび実行方法

移行の分析および計画

アプリケーションとサーバー設定はそれぞれ異なるため、移行を始める前に既存のアプリケーションと、サーバープラットフォームのコンポーネントおよびアーキテクチャーを十分に理解する必要があります。移行計画にはテストの詳細なロードマップが含まれる必要があり、以下の情報を考慮して実稼働に展開する必要があります。

移行責任者の特定

ステークホルダー、プロジェクトマネージャー、開発者、管理者、およびその他の移行責任者を特定します。

アプリケーションサーバープラットフォーム設定とハードウェアの確認

既存のアプリケーションサーバーとプラットフォーム設定を検証し、JBoss EAP 7 の今後の変更がどのように影響するかを判断します。以下の項目が含まれる必要があります。

オペレーティングシステムおよびバージョン

アプリケーションによって使用されるデータベース

Web サーバー

セキュリティーアーキテクチャー

プロセッサーの数およびタイプ

メモリーの容量

物理ディスクストレージの容量

データベースまたはメッセージングデータの移行

移行の影響を受ける可能性があるその他のコンポーネント

現在の本番環境の確認

移行プロセスのテストおよびステージングでは、できるだけ本番環境に近い状態を再現するように計画を立てる必要があります。

クラスタリング設定を考慮します。クラスターの移行方法に関する詳細は、JBoss EAP Patching and Upgrading Guide の Upgrading a Cluster を参照してください。

現在、大型の管理対象ドメインを実行している場合は、段階的な移行方法を考慮してください。

データベースまたはメッセージングデータの移行が必要であるかどうかを判断します。

既存アプリケーションの検証および理解

既存の JBoss EAP 6 アプリケーションを完全に検証します。以下を含むアーキテクチャー、関数、機能、およびコンポーネントについて完全に理解してください。

JVM バージョン

他の Red Hat アプリケーションサーバーミドルウェアコンポーネントとの統合

プロプライエタリーサードパーティーソフトウェアとの統合

代替機能が必要となる非推奨機能の使用

デプロイメント記述子、JNDI、永続性、JDBC 設定およびプーリング、JMS トピックおよびキュー、ロギングを含むアプリケーション設定

JBoss EAP 7 への移行中に変更が必要な互換性のないコード設定を特定

詳細テストプランの作成

計画には、回帰テストと受け入れ基準の要件が含まれる必要があります。

パフォーマンステストが含まれる必要もあります。

本番環境へロールアウトする前に移行をテストするため、できるだけ本番環境に近くなるようステージング環境を設定します。

必ず、バックアップおよびバックアウト計画を作成してください。

移行プロセスに使用できるリソースの確認

開発チームのスキルを評価し、トレーニングまたは追加のコンサルティングを計画します。

移行プロセス中は、ステージングやテストで追加のハードウェアやその他のリソースが必要になることにも注意してください。

正式なトレーニングが必要であるかどうかを判断します。必要な場合はスケジュールに追加します。

計画の遂行

必要なリソースを確保し、移行計画を実行します。

重要

必ずバックアップコピーを作成してからアプリケーションに変更を加えるようにしてください。

重要データのバックアップおよびサーバー状態の確認

アプリケーションを移行する前に、以下の問題が発生する可能性があることを認識しておく必要があります。

移行によって一時フォルダーが削除される可能性があります。移行前に data/content/ ディレクトリーに保存されたすべてのデプロイメントをバックアップし、移行後に復元する必要があります。この作業を怠ると、削除された内容が原因でサーバーが起動しないことがあります。

移行前に、開かれたトランザクションをすべて処理し、 data/tx-object-store/ トランザクションディレクトリーを削除します。

data/timer-service-data にある永続タイマーデータをチェックし、互換性があるかどうかを判断する必要があります。移行前に、このディレクトリーにある deployment-* ファイルをチェックし、使用されているタイマーを確認します。

移行を開始する前に、現在のサーバー設定とアプリケーションもバックアップするようにしてください。

RPM インストールの移行

重要

単一の Red Hat Enterprise Linux サーバーでサポートされるのは、RPM でインストールされた JBoss EAP のインスタンス 1 つまでです。そのため、JBoss EAP 7 に移行の際は、使用中の JBoss EAP インストールを新規マシンに移行することが推奨されます。

JBoss EAP RPM インストールを JBoss EAP 6 から JBoss EAP 7 に移行する際は、JBoss EAP 7 のインストール先となるマシンに既存の JBoss EAP RPM インストールがないことを確認してください。

RPM を使用して JBoss EAP 7 をインストールする場合は、JBoss EAP のインストールガイドを参照してください。

本ガイドの移行に関するアドバイスは JBoss EAP の RPM インストールの移行にも適用されますが、ZIP やインストーラーによるインストールの場合と比べると (JBoss EAP の開始方法などの) いくつかのステップについては修正して、RPM インストールに適合させる必要がある場合があります。

サービスとして実行するよう JBoss EAP を移行

JBoss EAP 6 をサービスとして実行する場合は、必ず JBoss EAP インストールガイドのサービスとして実行するよう JBoss EAP を設定を読んで、JBoss EAP 7 で更新された設定手順を確認してください。

第3章 移行に役立つツール

Windup を使用した移行のアプリケーションの分析

Red Hat JBoss Migration Toolkit の一部である Windup は、拡張およびカスタマイズ可能なルールベースのツールで、Java アプリケーションの移行を容易にします。Windup は移行予定のアプリケーションによって使用される API、技術、およびアーキテクチャーを分析し、各アプリケーションの詳細な移行レポートを提供します。レポートには以下の情報が含まれます。

必要な移行変更の詳細

変更が必須または任意であるかどうか

変更が複雑または簡単であるかどうか

移行変更が必要なコードへのリンク

必要な変更を行うためのヒントおよび情報へのリンク

見つかった各移行問題の推定作業量レベルおよびアプリケーションを移行するための推定合計作業量

Windup を使用すると、JBoss EAP 6 アプリケーションを JBoss EAP 7 へ移行する前にこれらのアプリケーションのコードやアークテクチャーを分析できます。JBoss EAP 6 から JBoss EAP 7 への移行に対する Windup のルールセットは XML 記述子についてレポートし、JBoss EAP 7 への移行時に代替の設定に置き換える必要がある特定のアプリケーションコードおよびパラメーターについてもレポートします。

Windup を使用して JBoss EAP 6 アプリケーションを分析する方法の詳細は、Windup User Guide を参照してください。

JBoss Server Migration Tool を使用したサーバー設定の移行

現在開発中の JBoss Server Migration Tool を使用して、既存の設定を保持しながら JBoss EAP 7 の新機能や新設定が含まれるように設定を更新することが推奨されます。

JBoss Server Migration Tool は既存の JBoss EAP 6 サーバー設定ファイルを読み取り、新しいサブシステムの設定を追加します。さらに、既存のサブシステム設定を新機能で更新し、廃止されたサブシステム設定を削除します。

JBoss Server Migration Tool の最新のプレリリース版バイナリーディストリビューションは、https://github.com/wildfly/wildfly-server-migration/releases からダウンロードできます。このバージョンは、JBoss EAP 6.4 から JBoss EAP 7.0 へのスタンドアロンサーバーの移行をサポートします。このツールの使用方法については、JBoss Server Migration Tool User Guide を参照してください。

注記

JBoss Server Migration Tool のプレリリース版はサポートされません。

第4章 サーバー設定の変更

サーバー設定移行オプション

サーバー設定を JBoss EAP 6 から JBoss EAP 7 に移行するには、JBoss Server Migration Tool 使用するか、管理 CLI の migrate 操作を使用して手作業で移行します。

JBoss Server Migration Tool

現在開発中の JBoss Server Migration Tool を使用して、既存の設定を保持しながら JBoss EAP 7 の新機能や新設定が含まれるように設定を更新することが推奨されます。

管理 CLI の migrate 操作

管理 CLI の migrate 操作を使用して JBoss EAP 6 設定ファイルの jacorb、messaging、および web サブシステムを更新すると、新しいリリースで実行できるようにすることができますが、完全な JBoss EAP 7 の設定にはならないことに注意してください。例を以下に示します。

この操作は、元の remote プロトコルおよびポート設定を JBoss EAP 7 で使用される新しい http-remoting およびポート設定に更新しません。

設定には、新しい JBoss EAP サブシステム、クラスター化されたシングルトンデプロイメントなどの機能、正常シャットダウンが含まれません。

設定には、バッチ処理などの新しい Java EE 7 の機能が含まれません。

migrate 操作を使用したサーバー設定の移行に関する詳細は、管理 CLI の移行操作を参照してください。

管理 CLI の移行操作

管理 CLI を使用して、JBoss EAP 7 上で実行するよう JBoss EAP 6 のサーバー設定ファイルを更新することができます。管理 CLI では、jacorb、messaging、および web サブシステムを以前のリリースから新しい設定へ自動的に更新する migrate 操作を実行できます。また、 jacorb、messaging、および web サブシステムに describe-migration 操作を実行すると、移行を行う前に提案された移行設定の変更を確認することもできます。cmp、jaxr、および threads サブシステムの代替はないため、これらのサブシステムをサーバー設定から削除する必要があります。

重要

migrate 操作の制限については、サーバー設定移行オプションを参照してください。現在開発中の JBoss Server Migration Tool を使用して、既存の設定を保持しながら JBoss EAP 7 の新機能や新設定が含まれるように設定を更新することが推奨されます。

表4.1 サブシステムの移行および管理 CLI 操作

JBoss EAP 6 サブシステム
JBoss EAP 7 サブシステム
管理 CLI 操作

cmp

代替なし

remove

jacorb

iiop-openjdk

migrate

jaxr

代替なし

remove

messaging

messaging-activemq

migrate

threads

代替なし

remove

web

undertow

migrate

以下の手順に従って、JBoss EAP 7 上で実行されるよう JBoss EAP 6 のサーバー設定を更新します。

移行を始める前に、重要データのバックアップおよびサーバー状態の確認の内容を見直してください。ここには、サーバーを良好な状態にし、適切なファイルをバックアップするための重要な情報が記載されています。

JBoss EAP 6 の設定で JBoss EAP 7 のサーバーを起動します。

JBoss EAP 7 サーバー設定ファイルをバックアップします。

以前のリリースの設定ファイルを JBoss EAP 7 ディレクトリーにコピーします。

$ cp EAP6_HOME/standalone/configuration/standalone-full.xml EAP7_HOME/standalone/configuration

JBoss EAP 7 のインストールディレクトリーへ移動し、--admin-only 引数を使用してサーバーを起動します。

$ bin/standalone.sh -c standalone-full.xml --admin-only

注記

サーバーを起動すると、以下の org.jboss.as.controller.management-operation エラーがサーバーログに記録されます。これらのエラーは予期されたエラーで、レガシーサブシステムの設定を削除するか JBoss EAP 7 に移行する必要があることを示しています。

WFLYCTL0402: Subsystems [cmp] provided by legacy extension 'org.jboss.as.cmp' are not supported on servers running this version. Both the subsystem and the extension must be removed or migrated before the server will function.

WFLYCTL0402: Subsystems [jacorb] provided by legacy extension 'org.jboss.as.jacorb' are not supported on servers running this version. Both the subsystem and the extension must be removed or migrated before the server will function.

WFLYCTL0402: Subsystems [jaxr] provided by legacy extension 'org.jboss.as.jaxr' are not supported on servers running this version. Both the subsystem and the extension must be removed or migrated before the server will function.

WFLYCTL0402: Subsystems [messaging] provided by legacy extension 'org.jboss.as.messaging' are not supported on servers running this version. Both the subsystem and the extension must be removed or migrated before the server will function.

WFLYCTL0402: Subsystems [threads] provided by legacy extension 'org.jboss.as.threads' are not supported on servers running this version. Both the subsystem and the extension must be removed or migrated before the server will function.

WFLYCTL0402: Subsystems [web] provided by legacy extension 'org.jboss.as.web' are not supported on servers running this version. Both the subsystem and the extension must be removed or migrated before the server will function.

新しいターミナルを開いて、JBoss EAP 7 のインストールディレクトリーへ移動し、--controller=remote://localhost:9999 引数を使用して管理 CLI を開始します。

$ bin/jboss-cli.sh --connect --controller=remote://localhost:9999

jacorb、messaging、および web サブシステムを移行します。

移行を行う前にサブシステムに追加した設定変更を確認するには、describe-migration 操作を実行します。

describe-migration 操作では以下の構文を使用します。

/subsystem=SUBSYSTEM_NAME:describe-migration

以下の例は、JBoss EAP 7 に移行されるときに JBoss EAP 6.4 の standalone-full.xml 設定ファイルに加えられる設定の変更を示しています。見やすくするため、エントリーは出力から削除されています。

例: describe-migration 操作. 

[standalone@localhost:9999 /] /subsystem=messaging:describe-migration
{
    "outcome" => "success",
    "result" => {
        "migration-warnings" => [],
        "migration-operations" => [
            {
                "operation" => "add",
                "address" => [("extension" => "org.wildfly.extension.messaging-activemq")],
                "module" => "org.wildfly.extension.messaging-activemq"
            },
            {
                "operation" => "add",
                "address" => [("subsystem" => "messaging-activemq")]
            },
            <!-- *** Entries removed for readability *** -->
            {
                "operation" => "remove",
                "address" => [("subsystem" => "messaging")]
            },
            {
                "operation" => "remove",
                "address" => [("extension" => "org.jboss.as.messaging")]
            }
        ]
    }
}

migrate 操作を実行し、サブシステムの設定を JBoss EAP 7 の代替サブシステムに移行します。この操作では以下の構文を使用します。

/subsystem=SUBSYSTEM_NAME:migrate

注記

messaging サブシステムの describe-migration および migrate 操作を使用すると、引数を渡してレガシークライアントによるアクセスを設定することができます。コマンド構文の詳細は、Messaging サブシステムの移行および前方互換性を参照してください。

このコマンドの結果を確認します。必ず、操作が正常に完了し、"migration-warning" エントリーがないことを確認してください。これは、サブシステムの移行設定が完了したことを意味します。

例: 警告のない成功した migrate 操作. 

[standalone@localhost:9999 /] /subsystem=messaging:migrate
{
    "outcome" => "success",
    "result" => {"migration-warnings" => []}
}

サーバー設定の移行が正常に完了したにも関わらず、すべての要素と属性を移行できなかった場合、ログに "migration-warnings" エントリーが表示されます。"migration-warnings" が示す提案に従い、追加の管理 CLI コマンドを実行してこれらの設定を編集する必要があります。"migration-warnings" を返す migrate 操作の例を以下に示します。

例: 警告のある migrate 操作. 

[standalone@localhost:9999 /] /subsystem=messaging:migrate
{
    "outcome" => "success",
    "result" => {"migration-warnings" => [
        "WFLYMSG0080: Could not migrate attribute group-address from resource [
    (\"subsystem\" => \"messaging-activemq\"),
    (\"server\" => \"default\"),
    (\"broadcast-group\" => \"groupB\")
]. Use instead the socket-binding attribute to configure this broadcast-group.",
        "WFLYMSG0080: Could not migrate attribute group-port from resource [
    (\"subsystem\" => \"messaging-activemq\"),
    (\"server\" => \"default\"),
    (\"broadcast-group\" => \"groupB\")
]. Use instead the socket-binding attribute to configure this broadcast-group.",
        "WFLYMSG0080: Could not migrate attribute local-bind-address from resource [
    (\"subsystem\" => \"messaging-activemq\"),
    (\"server\" => \"default\"),
    (\"broadcast-group\" => \"groupA\")
]. Use instead the socket-binding attribute to configure this broadcast-group.",
        "WFLYMSG0080: Could not migrate attribute local-bind-port from resource [
    (\"subsystem\" => \"messaging-activemq\"),
    (\"server\" => \"default\"),
    (\"broadcast-group\" => \"groupA\")
]. Use instead the socket-binding attribute to configure this broadcast-group.",
        "WFLYMSG0080: Could not migrate attribute group-address from resource [
    (\"subsystem\" => \"messaging-activemq\"),
    (\"server\" => \"default\"),
    (\"broadcast-group\" => \"groupA\")
]. Use instead the socket-binding attribute to configure this broadcast-group.",
        "WFLYMSG0080: Could not migrate attribute group-port from resource [
    (\"subsystem\" => \"messaging-activemq\"),
    (\"server\" => \"default\"),
    (\"broadcast-group\" => \"groupA\")
]. Use instead the socket-binding attribute to configure this broadcast-group."
    ]}
}

注記

各サブシステムの migrate および describe-migration 警告のリストは、本ガイドの最後にあるリファレンス資料 に記載されています。

Jacorb サブシステム移行操作の警告

メッセージングサブシステム移行操作の警告

Web サブシステム移行操作の警告

サーバー設定ファイルを確認し、拡張、サブシステム、および名前空間が更新され、既存のサブシステム設定が JBoss EAP 7 に移行されたことを確認します。

注記

この手順は、以下のコマンドを使用して jacorb、messaging、および web の各サブシステムに対して繰り返す必要があります。

/subsystem=jacorb:migrate
/subsystem=messaging:migrate
/subsystem=web:migrate

cmp、jaxr、および threads サブシステムおよび拡張をサーバー設定から削除します。

管理 CLI プロンプトで以下のコマンドを実行し、廃止された cmp、jaxr、および threads サブシステムを削除します。

/subsystem=cmp:remove
/extension=org.jboss.as.cmp:remove
/subsystem=jaxr:remove
/extension=org.jboss.as.jaxr:remove
/subsystem=threads:remove
/extension=org.jboss.as.threads:remove

重要

サーバーを再起動する前に messaging、jacorb、および web サブシステムを移行し、cmp、jaxr、および threads 拡張およびサブシステムを削除する必要があります。この作業の完了前にサーバーを再起動する必要がある場合は、サーバー起動のコマンドラインで --admin-only 引数を使用するようにしてください。これにより、サーバーの変更を継続できます。

ロギングメッセージの接頭辞の変更

ログメッセージには、メッセージを報告するサブシステムのプロジェクトコードが接頭辞として付けられます。JBoss EAP 7 では、すべてのログメッセージの接頭辞が変更になりました。

JBoss EAP 7 で使用されるログメッセージの新しいプロジェクトコード接頭辞の完全リストは、JBoss EAP Development Guide の Project Codes Used in JBoss EAP を参照してください。

Web サーバー設定の変更

Undertow による Web サブシステムの置換

JBoss EAP 7 の web サーバーは、JBoss Web から Undertow に変更になりました。そのため、web サブシステム設定を新しい JBoss EAP 7 undertow サブシステム設定に移行する必要があります。

サーバー設定ファイルの urn:jboss:domain:web:2.2 サブシステム設定ネームスペースは urn:jboss:domain:undertow:3.1 ネームスペースに置き換えられました。

EAP_HOME/modules/system/layers/base/ にあった org.jboss.as.web 拡張モジュールは、org.wildfly.extension.undertow 拡張モジュールに置き換えられました。

管理 CLI migrate 操作を使うと、 web サブシステムをサーバー設定ファイル内の undertow に移行することができます。ただし、この操作では JBoss Web サブシステムのすべての設定が移行できるわけではないことに注意してください。"migration-warning" エントリーが表示される場合は、追加の管理 CLI コマンドを実行して設定を Undertow に移行する必要があります。管理 CLI migrate 操作についての詳細情報は、管理 CLI の移行操作 を参照してください。

以下の例は、JBoss EAP 6 のデフォルトの web サブシステム設定を示しています。

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
    <virtual-server name="default-host" enable-welcome-root="true">
        <alias name="localhost"/>
        <alias name="example.com"/>
    </virtual-server>
</subsystem>

以下の例は、JBoss EAP 7 のデフォルトの undertow サブシステム設定を示しています。

<subsystem xmlns="urn:jboss:domain:undertow:3.1">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <filter-ref name="server-header"/>
            <filter-ref name="x-powered-by-header"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <filters>
        <response-header name="server-header" header-name="Server" header-value="JBoss-EAP/7"/>
        <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
    </filters>
</subsystem>

JBoss Web リライト条件の移行

管理 CLI の migrate 操作はリライト条件を自動的に移行できません。"migration-warnings" として報告され、手作業で移行する必要があります。Undertow の述語属性およびハンドラーを使用すると (Undertow Predicates Attributes and Handlers を参照)、JBoss EAP 7 で同等の設定を作成できます。

以下の例は、rewrite 設定を含む JBoss EAP 6 の web サブシステム設定を示しています。

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default" native="false">
    <virtual-server name="default" enable-welcome-root="true">
        <alias name="localhost"/>
        <rewrite name="test" pattern="(.*)/toberewritten/(.*)" substitution="$1/rewritten/$2" flags="NC"/>
        <rewrite name="test2" pattern="(.*)" substitution="-" flags="F">
            <condition name="get" test="%{REQUEST_METHOD}" pattern="GET"/>
            <condition name="andCond" test="%{REQUEST_URI}" pattern=".*index.html" flags="NC"/>
        </rewrite>
    </virtual-server>
</subsystem>

管理 CLI の移行操作 にある手順にしたがってサーバーと管理 CLI を開始し、以下のコマンドを使用して web サブシステム設定ファイルを移行します。

/subsystem=web:migrate

上記の設定で migrate 操作を実行すると、以下の "migration-warnings" がレポートされます。

/subsystem=web:migrate
{
    "outcome" => "success",
    "result" => {"migration-warnings" => [
        "WFLYWEB0002: Could not migrate resource {
    \"pattern\" => \"(.*)\",
    \"substitution\" => \"-\",
    \"flags\" => \"F\",
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\")
    ]
}",
        "WFLYWEB0002: Could not migrate resource {
    \"test\" => \"%{REQUEST_METHOD}\",
    \"pattern\" => \"GET\",
    \"flags\" => undefined,
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\"),
        (\"condition\" => \"get\")
    ]
}",
        "WFLYWEB0002: Could not migrate resource {
    \"test\" => \"%{REQUEST_URI}\",
    \"pattern\" => \".*index.html\",
    \"flags\" => \"NC\",
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\"),
        (\"condition\" => \"andCond\")
    ]
}"
    ]}
}

サーバー設定ファイルを確認すると、undertow サブシステムが以下の設定になっています。

注記

リライト設定は削除されています。

<subsystem xmlns="urn:jboss:domain:undertow:3.1">
     <buffer-cache name="default"/>
     <server name="default-server">
         <http-listener name="http" socket-binding="http"/>
         <host name="default-host" alias="localhost, example.com">
             <location name="/" handler="welcome-content"/>
         </host>
     </server>
     <servlet-container name="default">
         <jsp-config/>
     </servlet-container>
     <handlers>
         <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
     </handlers>
 </subsystem>

管理 CLI を使用してフィルターを作成し、undertow サブシステムのリライト設定を置き換えます。各コマンドで "{"outcome" ⇒ "success"}" が表示されるはずです。

# Create the filters
/subsystem=undertow/configuration=filter/expression-filter="test1":add(expression="path('(.*)/toberewritten/(.*)') -> rewrite('$1/rewritten/$2')")
/subsystem=undertow/configuration=filter/expression-filter="test2":add(expression="method('GET') and path('.*index.html') -> response-code(403)")

# Add the filters to the default server
/subsystem=undertow/server=default-server/host=default-host/filter-ref="test1":add
/subsystem=undertow/server=default-server/host=default-host/filter-ref="test2":add

更新されたサーバー設定ファイルを確認します。JBoss Web サブシステムは完全に移行され、undertow サブシステムに設定されます。

<subsystem xmlns="urn:jboss:domain:undertow:3.1">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="http" socket-binding="http"/>
        <host name="default-host" alias="localhost, example.com">
            <location name="/" handler="welcome-content"/>
            <filter-ref name="test1"/>
            <filter-ref name="test2"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <filters>
        <expression-filter name="test1" expression="path('(.*)/toberewritten/(.*)') -> rewrite('$1/rewritten/$2')"/>
        <expression-filter name="test2" expression="method('GET') and path('.*index.html') -> response-code(403)"/>
    </filters>
</subsystem>

管理 CLI を使用してフィルターとハンドラーを設定する方法については、JBoss EAP 7 Configuration Guide の Configuring the Web Server を参照してください。

グローバルバルブの移行

以前のリリースの JBoss EAP ではバルブがサポートされました。バルブとは、リクエストの変更や追加処理を実行するために、サーブレットフィルターの前にアプリケーションのリクエスト処理パイプラインへ挿入されるカスタムクラスのことです。

グローバルバルブは、デプロイされたすべてのアプリケーションのリクエスト処理パイプラインへ挿入され、サーバー設定ファイルで設定されます。

オーセンティケーターバルブはリクエストのクレデンシャルを認証します。

カスタムアプリケーションバルブは、org.apache.catalina.valves.ValveBase クラスを拡張して作成され、jboss-web.xml 記述子ファイルの <valve> 要素で設定されます。これらのバルブは手作業で移行する必要があります。

この項では、グローバルバルブの移行方法について説明します。カスタムおよびオーセンティケーターバルブの移行については、本ガイドのカスタムアプリケーションバルブの移行を参照してください。

JBoss EAP 7 で JBoss Web の代わりに導入された Undertow はグローバルバルブをサポートしませんが、Undertow ハンドラーを使用すると同様の機能を実現できます。Undertow には共通の機能を提供する複数のビルトインハンドラーが含まれています。また、カスタムハンドラーを作成する機能も含まれ、カスタムバルブの機能を置き換えるために使用することができます。

アプリケーションがバルブを使用する場合、JBoss EAP 7 へ移行するときに適切な Undertow ハンドラーコードに置き換え、同様の機能を実現する必要があります。

ハンドラーを設定する方法については、JBoss EAP 7 Configuration Guide の Configuring Handlers を参照してください。

フィルターを設定する方法については、JBoss EAP 7 Configuration Guide の Configuring Filters を参照してください。

JBoss Web バルブの移行

以下の表では、JBoss EAP の前リリースで JBoss Web が提供していたバルブとそれに対応する Undertow ビルトインハンドラーを示しています。JBoss Web バルブは、org.apache.catalina.valves パッケージにあります。

表4.2 バルブとハンドラーのマッピング

バルブ
ハンドラー

AccessLogValve

io.undertow.server.handlers.accesslog.AccessLogHandler

CrawlerSessionManagerValve

io.undertow.servlet.handlers.CrawlerSessionManagerHandler

ExtendedAccessLogValve

io.undertow.server.handlers.accesslog.AccessLogHandler

JDBCAccessLogValve

手順については JDBCAccessLogValve の手動移行の手順を参照してください。

RemoteAddrValve

io.undertow.server.handlers.IPAddressAccessControlHandler

RemoteHostValve

io.undertow.server.handlers.AccessControlListHandler

RemoteIpValve

io.undertow.server.handlers.ProxyPeerAddressHandler

RequestDumperValve

io.undertow.server.handlers.RequestDumpingHandler

RewriteValve

これらのバルブを手作業で移行する手順は、JBoss Web リライト条件の移行 を参照してください。

StuckThreadDetectionValve

io.undertow.server.handlers.StuckThreadDetectionHandler

管理 CLI の migrate 操作を使用すると、以下の基準を満たすグローバルバルブを自動的に移行できます。

前述の表にリストされている、手動処理の必要がないバルブに限定されます。

サーバー設定ファイルの web サブシステムに定義されている必要があります。

管理 CLI の migrate 操作の詳細は、管理 CLI の移行操作 を参照してください。

JDBCAccessLogValve の手動移行の手順

org.apache.catalina.valves.JDBCAccessLogValve バルブはルールの例外で、io.undertow.server.handlers.JDBCLogHandler へ自動的に移行することができません。以下の手順に従って、次のバルブ例を移行します。

<valve name="jdbc" module="org.jboss.as.web" class-name="org.apache.catalina.valves.JDBCAccessLogValve">
    <param param-name="driverName" param-value="com.mysql.jdbc.Driver" />
    <param param-name="connectionName" param-value="root" />
    <param param-name="connectionPassword" param-value="password" />
    <param param-name="connectionURL" param-value="jdbc:mysql://localhost:3306/wildfly?zeroDateTimeBehavior=convertToNull" />
    <param param-name="format" param-value="combined" />
</valve>

ログエントリーを保存するデータベースのドライバーモジュールを作成します。

データベースのデータソースを設定し、ドライバーを datasources サブシステムの利用可能なドライバーのリストに追加します。

<datasources>
    <datasource jndi-name="java:jboss/datasources/accessLogDS" pool-name="accessLogDS" enabled="true" use-java-context="true">
        <connection-url>jdbc:mysql://localhost:3306/wildfly?zeroDateTimeBehavior=convertToNull</connection-url>
        <driver>mysql</driver>
        <security>
           <user-name>root</user-name>
           <password>Password1!</password>
        </security>
    </datasource>
    ...
    <drivers>
        <driver name="mysql" module="com.mysql">
            <driver-class>com.mysql.jdbc.Driver</driver-class>
        </driver>
    ...
    </drivers>
</datasources>

式 jdbc-access-log(datasource=DATASOURCE_JNDI_NAME) を使用して、undertow サブシステムの expression-filter を設定します。

<filters>
    <expression-filter name="jdbc-access" expression="jdbc-access-log(datasource='java:jboss/datasources/accessLogDS')" />
    ...
</filters>

JGroups サーバー設定の変更

JGroups はデフォルトでプライベートネットワークインターフェースを使用

JBoss EAP 6 のデフォルト設定では、JGroups はサーバー設定ファイルの <interfaces> セクションに定義された public インターフェースを使用しました。

専用のネットワークインターフェースを使用することが推奨されるため、JBoss EAP 7 では JGroups はサーバー設定ファイルの <interfaces> セクションに定義された新しい private インターフェースを使用するようになりました。

JGroups チャネルの変更

JGroups は JGroups チャネルで HA サービスのグループ通信サポートを提供します。JBoss EAP 7 では、サーバー設定ファイルの jgroups サブシステムに <channel> 要素が導入されました。管理 CLI を使用して JGroups チャネル設定を追加、削除、および変更できます。

JGroups の設定方法の詳細は、JBoss EAP Configuration Guide の Cluster Communication with JGroups を参照してください。

Infinispan サーバー設定の変更

Infinispan のデフォルトキャッシュ設定の変更

JBoss EAP 6 では、Web セッションレプリケーションおよび EJB レプリケーションのデフォルトのクラスター化キャッシュは ASYNC キャッシュでレプリケートされましたが、これが JBoss EAP 7 では変更になりました。レプリケートされたキャッシュはデフォルトでは設定されません。レプリケートされたキャッシュの追加方法とレプリケートされたキャッシュをデフォルトにする方法はについては、JBoss EAP Configuration Guide の Configure the Cache Mode を参照してください。

これは、新しい JBoss EAP 7 のデフォルト設定を使用する場合のみ影響します。JBoss EAP 6 から設定を移行する場合は、infinispan サブシステムの設定は保持されます。

Infinispan のキャッシュストラテジーの変更

ASYNC キャッシュストラテジーの動作が JBoss EAP 7 では変更になりました。

JBoss EAP 6 では、ASYNC キャッシュの読み取りにロックはありませんでした。ブロックは発生しませんでしたが、フェイルオーバーなどで陳腐データのダーティーリードが発生する傾向にありました。これは、リクエストの完了前に同じユーザーの次のリクエストを開始できたためです。これは、クラスタートポロジーの変更がセッションアフィニティーに影響し、容易にデータが陳腐化することがあるため、分散モードを使用するときは許可されません。

JBoss EAP 7 では、ASYNC キャッシュの読み取りにロックが必要になりました。レプリケーションが終了するまで同じユーザーの新しいリクエストをブロックするようになったため、ダーティーリードが発生しないようになりました。

メッセージングサーバー設定の変更

JBoss EAP 7 では、JMS サポートプロバイダーが HornetQ から ActiveMQ Artemis に変更になりました。ここでは、設定と関連するメッセージングデータの移行方法を説明します。

メッセージングサブシステムサーバー設定の変更

EAP_HOME/modules/system/layers/base/ にあった org.jboss.as.messaging モジュール拡張は、 org.wildfly.extension.messaging-activemq 拡張モジュールに置き換えられました。

urn:jboss:domain:messaging:3.0 サブシステム設定ネームスペースは urn:jboss:domain:messaging-activemq:1.0 ネームスペースに置き換えられました。

管理モデル

ほとんどの場合で、要素名と属性名は以前のリリースとできる限り同じになるよう努力しています。以下の表は変更の一部を表しています。

表4.3 メッセージング属性のマッピング

HornetQ での名前
ActiveMQ での名前 ﻿

hornetq-server

server

hornetq-serverType

serverType

connectors

connector

discovery-group-name

discovery-group

新しい messaging-activemq サブシステム上で呼び出される管理操作は、/subsystem=messaging/hornetq-server= から /subsystem=messaging-activemq/server= に変更になりました。

migrate 操作を呼び出すと、既存の JBoss EAP 6 の messaging サブシステム設定を JBoss EAP 7 の messaging-activemq サブシステムに移行できます。

/subsystem=messaging:migrate

migrate 操作を実行する前に describe-migration 操作を呼び出して、既存の JBoss EAP 6 の messaging サブシステム設定から JBoss EAP 7 サーバーの messaging-activemq サブシステムへの移行を実行する管理操作のリストを確認するとよいでしょう。

/subsystem=messaging:describe-migration

migrate および describe-migration 操作は、自動的に移行されないリソースや属性の migration-warnings のリストも表示します。

Messaging サブシステムの移行および前方互換性

messaging サブシステムの describe-migration およびmigrate 操作は、追加の設定引数を提供します。メッセージングを設定してレガシー JBoss EAP 6 クライアントが JBoss EAP 7 サーバーに接続できるようにするには、以下のようにブール値の add-legacy-entries 引数を describe-migration または migrate 操作に追加します。

/subsystem=messaging:describe-migration(add-legacy-entries=true)
/subsystem=messaging:migrate(add-legacy-entries=true)

ブール値の引数 add-legacy-entries が true に設定されていると、messaging-activemq サブシステムが legacy-connection-factory リソースを作成し、legacy-entries を jms-queue および jms-topic リソースに追加します。

ブール値の引数 add-legacy-entries が false に設定されていると、messaging-activemq サブシステムにはレガシーリソースが作成されず、レガシー JMS クライアントは JBoss EAP 7 サーバーと通信できません。これがデフォルト値になります。

前方互換性および後方互換性に関する詳細は、JBoss EAP Configuring Messaging の Backward and Forward Compatibility を参照してください。

管理 CLI の migrate および describe-migration 操作の詳細は、管理 CLI の移行操作を参照してください。

Messaging サブシステムの XML 設定

新しい messaging-activemq サブシステムによって、他の JBoss EAP サブシステムとより一貫性のある XML スキームが提供されるようになり、XMLの設定は大幅に変更されました。

新しい messaging-activemq サブシステムに準拠するために JBoss EAP messaging サブシステムの XML 設定を変更しないでください。この代わりに、レガシーサブシステムの migrate 操作を呼び出してください。この操作は、実行の一部として新しい messaging-activemq の XML 設定を書き込みます。

メッセージングログの変更

messaging サブシステムのログメッセージに付けられる接頭辞が JBAS から WFLYMSGAMQ に変更になりました。JBoss EAP 7 で使用されるログメッセージの新しいプロジェクトコード接頭辞の完全リストは、JBoss EAP Development Guide の Project Codes Used in JBoss EAP を参照してください。

メッセージングデータの移行

JMS サポートプロバイダーが HornetQ から ActiveMQ Artemis に変更になったため、JBoss EAP 7 ではメッセージングデータの形式と場所が変更になりました。

以下の 2 つの方法のいずれかを使用してデータを移行できます。

管理 CLI のimport-journal 操作を使用すると、以前のリリースから HornetQ のメッセージングデータをエクスポートし、インポートすることができます。詳細は、エクスポートおよびインポートを使用したメッセージングデータの移行を参照してください。

JMS ブリッジを設定すると、以前のリリースからデータを移行できます。この手順は、JMS ブリッジを使用したメッセージングデータの移行に記載されています。

リリース間で行われたメッセージングデータフォルダー名の変更についての詳細は、メッセージングフォルダー名のマッピングを参照してください。

エクスポートおよびインポートを使用したメッセージングデータの移行

この方法では、HornetQ の exporter ユーティリティーを使用して以前のリリースからデータをエクスポートします。その後、import-journal 操作を使用して XML 形式の出力ファイルをインポートします。

警告

現在、この方法には既知の問題が存在します。この問題の最新状況を確認するには、 JBEAP-4407 - Consumer crashes with IndexOutOfBoundsException when reading large messages from imported journal (インポートされたジャーナルから大型のメッセージを読み取ると、IndexOutOfBoundsException によってコンシューマーがクラッシュする) を参照してください。

前リリースからのメッセージングデータのエクスポート

重要

メッセージングデータをエクスポートする前に、JBoss EAP 6 サーバーを停止する必要があります。

HornetQ exporter ユーティリティーは、メッセージングデータを生成し、JBoss EAP 6 から XML 形式のファイルへエクスポートします。このコマンドでは、JBoss EAP 6 に同梱されている必須の HornetQ JAR へのパスを指定し、以前のリリースからの messagingbindings/、messagingjournal/、messagingpaging/、および messaginglargemessages/ フォルダーへのパスを引数として渡し、エクスポートされる XML データを書き込む出力ファイルを指定する必要があります。

以下は HornetQ exporter ユーティリティーで必要となる構文です。

java -jar -mp MODULE_PATH org.hornetq.exporter  MESSAGING_BINDINGS_DIRECTORY MESSAGING_JOURNAL_DIRECTORY MESSAGING_PAGING_DIRECTORY MESSAGING_LARGE_MESSAGES_DIRECTORY > OUTPUT_DATA.xml

カスタムモジュールを作成し、パッチやアップグレードでインストールされた JAR を含む HornetQ JAR の正しいバージョンがロードされ、exporter ユーティリティーで利用可能になるようにします。好みのエディターを使用して、EAP6_HOME/modules/org/hornetq/exporter/main/ ディレクトリー内に module.xml ファイルを作成し、以下のコンテンツをコピーします。

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.hornetq.exporter">
    <main-class name="org.hornetq.jms.persistence.impl.journal.XmlDataExporter"/>
    <properties>
        <property name="jboss.api" value="deprecated"/>
    </properties>
    <dependencies>
        <module name="org.hornetq"/>
    </dependencies>
</module>

注記

カスタムモジュールは modules/system/layers/base/ ディレクトリーではなく、modules/ ディレクトリー内に作成します。

以下の手順に従い、データをエクスポートします。

JBoss EAP 6 サーバーを停止します。

上記の説明にあるようにカスタムモジュールを作成します。

以下のコマンドを実行してデータをエクスポートします。

$ java -jar jboss-modules.jar -mp modules/ org.hornetq.exporter standalone/data/messagingbindings/ standalone/data/messagingjournal/ standalone/messagingpaging standalone/data/messaginglargemessages/ > OUTPUT_DIRECTORY/OldMessagingData.xml

コマンド完了後に、ログにエラーや警告メッセージがないことを確認します。

使用中のオペレーティングシステムで利用可能なツールを使用して、生成された出力ファイルの XML を検証します。

XML 形式のメッセージングデータのインポート

その後は、以下のように import-journal 操作で XML 形式の出力ファイルをインポートします。

/subsystem=messaging-activemq/server=default:import-journal(file=OUTPUT_DIRECTORY/OldMessagingData.xml)

JMS ブリッジを使用したメッセージングデータの移行

この方法では、JBoss EAP 6 の HornetQ キューから JBoss EAP 7 の ActiveMQ Artemis キューへメッセージを移行する JMS ブリッジを JBoss EAP 7 サーバーに設定およびデプロイします。

JMS ブリッジはソースの JMS キューまたはトピックからメッセージを消費し、通常は異なるサーバーにあるターゲットの JMS キューまたはトピックへ送信します。JMS 1.1 に準拠する JMS サーバーの間でメッセージをブリッジするために使用できます。送信元および宛先の JMS リソースは、JNDI を使用してルックアップされ、JNDI ルックアップのクライアントクラスはモジュールでバンドルされる必要があります。モジュール名は JMS ブリッジ設定で宣言されます。

ここでは、メッセージングデータを JBoss EAP 6 から JBoss EAP 7 に移動するためにサーバーを設定し、JMS ブリッジをデプロイする方法を説明します。

JBoss EAP 6 サーバーの設定

JBoss EAP 6 サーバーを停止します。

HornetQ のジャーナルおよび設定ファイルをバックアップします。

デフォルトでは、HornetQ ジャーナルは EAP6_HOME/standalone/data/ ディレクトリーにあります。

各リリースにおけるメッセージングフォルダーのデフォルトの場所は、メッセージングフォルダー名のマッピングを参照してください。

JMS メッセージが含まれる InQueue JMS キューが JBoss EAP 6 サーバーで定義されていることを確認してください。

messaging サブシステムの設定に以下と似た RemoteConnectionFactory のエントリーが含まれていることを確認してください。

<connection-factory name="RemoteConnectionFactory">
    <entries>
        <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
    </entries>
    ...
</connection-factory>

エントリーが含まれていない場合は、以下の管理 CLI コマンドを使用して作成します。

/subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:add(factory-type=XA_GENERIC, connector=[netty], entries=[java:jboss/exported/jms/RemoteConnectionFactory],ha=true,block-on-acknowledge=true,retry-interval=1000,retry-interval-multiplier=1.0,reconnect-attempts=-1)

JBoss EAP 7 サーバーの設定

以前のリリースでは、JMS ブリッジ設定が HornetQ サーバーに接続するには、org.hornetq モジュールが必要です。このモジュールと直接の依存関係は JBoss EAP 7 では存在しないため、以前のリリースから以下のモジュールをコピーする必要があります。

org.hornetq モジュールを JBoss EAP 7 EAP_HOME/modules/org/ ディレクトリーにコピーします。

このモジュールにパッチを適用していない場合は、JBoss EAP 6.4 サーバーの EAP6_HOME/modules/system/layers/base/org/hornetq/ フォルダーをコピーします。

このモジュールにパッチを適用した場合は、JBoss EAP 6.4 サーバーの EAP6_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.x.CP/org/hornetq/ フォルダーをコピーします。

注記

パッチが適用されたバージョンでは、以下の行を JBoss EAP 7 の modules/system/layers/base/org/hornetq/main/module.xml ファイルから削除する必要があります。

<resource-root path="../../../../../org/hornetq/main/lib"/>

org.jboss.netty モジュールを JBoss EAP 7 の EAP_HOME/modules/org/jboss/ ディレクトリーへコピーします。

このモジュールにパッチを適用していない場合は、JBoss EAP 6.4 サーバーの EAP6_HOME/modules/system/layers/base/org/jboss/netty/ フォルダーをコピーします。

このモジュールにパッチを適用した場合は、JBoss EAP 6.4 サーバーの EAP6_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.x.CP/org/jboss/netty フォルダーをコピーします。

JBoss EAP 6 サーバーから受信したメッセージを格納するために JSM キューを作成します。以下は、MigratedMessagesQueue JMS キューを作成してメッセージを受信する管理 CLI コマンドの例になります。

jms-queue add --queue-address=MigratedMessagesQueue --entries=[jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue]

このコマンドにより、JBoss EAP 7 サーバーの messaging-activemq サブシステムに以下のデフォルトサーバー用の jms-queue 設定が作成されます。

<jms-queue name="MigratedMessagesQueue" entries="jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue"/>

messaging-activemq サブシステムの default サーバーに以下と似た InVmConnectionFactory connection-factory の設定が含まれるようにしてください。

<connection-factory name="InVmConnectionFactory" factory-type="XA_GENERIC" entries="java:/ConnectionFactory" connectors="in-vm"/>

エントリーが含まれていない場合は、以下の管理 CLI コマンドを使用して作成します。

/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:add(factory-type=XA_GENERIC, connectors=[in-vm], entries=[java:/ConnectionFactory])

JBoss EAP 6 サーバーで設定された InQueue JMS キューからメッセージを読み取る JMS ブリッジを作成およびデプロイし、JBoss EAP 7 サーバーで設定された MigratedMessagesQueue に転送します。

/subsystem=messaging-activemq/jms-bridge=myBridge:add(add-messageID-in-header=true,max-batch-time=100,max-batch-size=10,max-retries=-1,failure-retry-interval=1000,quality-of-service=AT_MOST_ONCE,module=org.hornetq,source-destination=jms/queue/InQueue,source-connection-factory=jms/RemoteConnectionFactory,source-context=[("java.naming.factory.initial"=>"org.jboss.naming.remote.client.InitialContextFactory"),("java.naming.provider.url"=>"remote://127.0.0.1:4447")],target-destination=jms/queue/MigratedMessagesQueue,target-connection-factory=java:/ConnectionFactory)

これにより、JBoss EAP 7 サーバーの messaging-activemq サブシステムに以下の jms-bridge 設定が作成されます。

<jms-bridge name="myBridge" add-messageID-in-header="true" max-batch-time="100" max-batch-size="10" max-retries="-1" failure-retry-interval="1000" quality-of-service="AT_MOST_ONCE" module="org.hornetq">
    <source destination="jms/queue/InQueue" connection-factory="jms/RemoteConnectionFactory">
        <source-context>
            <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
            <property name="java.naming.provider.url" value="remote://127.0.0.1:4447"/>
        </source-context>
    </source>
    <target destination="jms/queue/MigratedMessagesQueue" connection-factory="java:/ConnectionFactory"/>
</jms-bridge>

また、セキュリティーが JBoss EAP 6 に設定されている場合、接続の作成時に JNDI ルックアップで使用される正しいユーザー名およびパスワードを指定する source-context が含まれるよう、JMS ブリッジ設定 <source> 要素を設定する必要もあります。

データの移行

以下の設定に提供する情報が正しいことを確認します。

キューおよびトピック名

JUDI ルックアップの java.naming.provider.url

ターゲットの JMS 宛先が JBoss EAP 7 サーバーにデプロイされているようにしてください。

JBoss EAP 6 サーバーと JBoss EAP 7 サーバーを両方起動します。

メッセージングフォルダー名のマッピング

以下の表では、JBoss EAP の以前および現在のリリースで対応するメッセージングディレクトリーの名前を示しています。ディレクトリーは jboss.server.data.dir ディレクトリーに相対的で、指定がない場合はデフォルトで EAP_HOME/standalone/data/ になります。

jBoss EAP 6 の ディレクトリー名
JBoss EAP 7 のディレクトリー名

messagingbindings/

activemq/bindings/

messagingjournal/

activemq/journal/

messaginglargemessages/

activemq/largemessages/

messagingpaging/

activemq/paging/

注記

大型のメッセージがない場合や、ページングが無効になっている場合は、 messaginglargemessages/ および messagingpaging/ ディレクトリーが存在しないことがあります。

JMS 宛先の移行

JBoss EAP のこれまでのリリースでは、JMS 宛先キューは messaging サブシステムの <hornetq-server> 要素下にある <jms-destinations> 要素に設定されました。

<hornetq-server>
  ...
  <jms-destinations>
     <jms-queue name="testQueue">
        <entry name="queue/test"/>
         <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
  </jms-destinations>
  ...
</hornetq-server>

JBoss EAP 7 では、JMS 宛先キューは messaging-activemq サブシステムのデフォルトの <server> 要素に設定されます。

<server name="default">
  ...
  <jms-queue name="testQueue" entries="queue/test java:jboss/exported/jms/queue/test"/>
  ...
</server>

メッセージングインターセプターの移行

JBoss EAP 7 では、JMS メッセージングプロバイダーが HornetQ から ActiveMQ Artemis に変更されたため、メッセージングインターセプターが大幅に変更されました。

以前の JBoss EAP リリースに含まれていた HornetQ messaging サブシステムでは、HornetQ インターセプターを JAR に追加し、HornetQ module.xml ファイルを修正するというインストール方法が必要でした。

JBoss EAP 7 に含まれる messaging-activemq サブシステムは、module.xml ファイルの修正を必要としません。Apache ActiveMQ Artemis Interceptor インターフェースを実装するユーザーインターセプタークラスは、どのサーバーモジュールからでもロードすることが可能です。インターセプターのロード先となるモジュールは、サーバー設定ファイルの messaging-activemq サブシステムで指定します。

インターセプター設定の例. 

<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
  <server name="default">
    ...
    <incoming-interceptors>
      <class name="com.mycompany.incoming.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.incoming.myOtherInterceptor" module="com.othercompany" />
    </incoming-interceptors>
    <outgoing-interceptors>
      <class name="com.mycompany.outgoing.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.outgoing.myOtherInterceptor" module="com.othercompany" />
    </outgoing-interceptors>
  </server>
</subsystem>

Netty サーブレット設定の変更

JBoss EAP 6 では、Netty サーブレットトランスポートと動作するようサーブレットエンジンを設定することができました。JBoss EAP 7 では、ビルトインメッセージングプロバイダーが HornetQ から ActiveMQ Artemis に変更になったため、この設定は使用できなくなりました。新しいビルトインメッセージング HTTP コネクターおよび HTTP アクセプターを使用するよう、サーブレット設定を変更する必要があります。

ORB サーバー設定の変更

JBoss EAP 7 では、JacORB 実装が OpenJDK ORB のダウンストリームブランチに変更になりました。

EAP_HOME/modules/system/layers/base/ にあった org.jboss.as.jacorb 拡張モジュールは、org.wildfly.iiop-openjdk 拡張モジュールに置き換えられました。

サーバー設定ファイルの urn:jboss:domain:jacorb:1.4 サブシステム設定ネームスペースは urn:jboss:domain:iiop-openjdk:1.0 ネームスペースに置き換えられました。

以下の例は、JBoss EAP 6 のデフォルトの jacorb システム設定を示しています。

<subsystem xmlns="urn:jboss:domain:jacorb:1.4">
    <orb socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
        <initializers security="identity" transactions="spec"/>
    </orb>
</subsystem>

以下の例は、JBoss EAP 7 のデフォルトの iiop-openjdk サブシステム設定を示しています。

<subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
    <orb socket-binding="jacorb" ssl-socket-binding="jacorb-ssl" />
    <initializers security="identity" transactions="spec" />
</subsystem>

新しい iiop-openjdk サブシステム設定は、レガシー要素および属性のサブセットのみを受け入れます。以下は、有効な要素および属性がすべて含まれる、前リリースの JBoss EAP の jacorbサブシステム設定例になります。

<subsystem xmlns="urn:jboss:domain:jacorb:1.4">
   <orb name="JBoss" print-version="off" use-imr="off" use-bom="off"  cache-typecodes="off"
       cache-poa-names="off" giop-minor-version="2" socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
       <connection retries="5" retry-interval="500" client-timeout="0" server-timeout="0"
           max-server-connections="500" max-managed-buf-size="24" outbuf-size="2048"
           outbuf-cache-timeout="-1"/>
       <initializers security="off" transactions="spec"/>
   </orb>
   <poa monitoring="off" queue-wait="on" queue-min="10" queue-max="100">
       <request-processors pool-size="10" max-threads="32"/>
   </poa>
   <naming root-context="JBoss/Naming/root" export-corbaloc="on"/>
   <interop sun="on" comet="off" iona="off" chunk-custom-rmi-valuetypes="on"
       lax-boolean-encoding="off" indirection-encoding-disable="off" strict-check-on-tc-creation="off"/>
   <security support-ssl="off" add-component-via-interceptor="on" client-supports="MutualAuth"
       client-requires="None" server-supports="MutualAuth" server-requires="None"/>
   <properties>
       <property name="some_property" value="some_value"/>
   </properties>
</subsystem>

以下の要素属性はサポート対象外になったため、削除する必要があります。

表4.4 削除する属性

要素
サポートされない属性

<orb>

client-timeout

max-managed-buf-size

max-server-connections

outbuf-cache-timeout

outbuf-size

connection retries

retry-interval

name

server-timeout

<poa>

queue-min

queue-max

pool-size

max-threads

以下の on/off 属性はサポート対象外となり、管理 CLI の migrate 操作を実行しても移行されません。これらの属性が on に設定されていると移行の警告が表示されます。<security support-ssl="on|off"> などの、この表に記載されていない on/off 属性のサポートは継続され、正常に移行されます。唯一の違いは、値が on/off から true/false に変更されることです。

表4.5 off に設定するまたは削除する属性

要素
off に設定する属性

<orb>

cache-poa-names

cache-typecodes

print-version

use-bom

use-imr

<interop>

(sun 以外すべて)

comet

iona

chunk-custom-rmi-valuetypes

indirection-encoding-disable

lax-boolean-encoding

strict-check-on-tc-creation

<poa/>

monitoring

queue-wait

threads サブシステム設定の移行

JBoss EAP 6 のサーバー設定には、サーバーの異なるサブシステムにまたがってスレッドプールを管理するために使用される threads が含まれていました。

threads サブシステムは JBoss EAP 7 では利用できないようになりました。この代わりに、各サブシステムが独自のスレッドプールを管理します。

infinispan サブシステムのスレッドプールを設定する方法は、 JBoss EAP Configuration Guide の Configure Infinispan Thread Pools を参照してください。

jgroups サブシステムのスレッドプールを設定する方法は、JBoss EAP Configuration Guide の Configure JGroups Thread Pools を参照してください。

JBoss EAP 6 では、threads サブシステムに定義された executorを参照して web サブシステムのコネクターおよびリスナーのスレッドプールを設定しました。JBoss EAP 7 では、io サブシステムに定義された worker を参照して undertow サブシステムのスレッドプールを設定します。詳細は、JBoss EAP Configuration Guide の Configuring the IO Subsystem を参照してください。

remoting サブシステムのスレッドプール設定の変更に関する詳細は、本ガイドの Remoting サブシステム設定の移行 と、JBoss EAP Configuration Guide の Configuring the Endpoint を参照してください。

Remoting サブシステム設定の移行

JBoss EAP 6 では、複数の worker-* 属性を設定して remoting サブシステムのスレッドプールを設定しました。JBoss EAP 7 では remoting サブシステムでワーカースレッドプールを設定しないようになりました。既存の設定を変更しようとすると、以下のメッセージが表示されます。

WFLYRMT0022: Worker configuration is no longer used, please use endpoint worker configuration

JBoss EAP 7 では、ワーカースレッドプールは、io サブシステムで定義される worker を参照するエンドポイント設定に置き換えられました。

エンドポイントの設定方法については、JBoss EAP Configuration Guide の Configuring the Endpoint を参照してください。

WebSocket サーバー設定の変更

JBoss EAP 6 で WebSockets を使用するには、以下と同様のコマンドを使用して JBoss EAP サーバー設定ファイルの web サブシステムにある http コネクターに対して非ブロッキング Java NIO2 コネクターを有効にする必要がありました。

/subsystem=web/connector=http/:write-attribute(name=protocol,value=org.apache.coyote.http11.Http11NioProtocol)

アプリケーションで WebSockets を使用するには、アプリケーションの WEB-INF/jboss-web.xml ファイル内で <enable-websockets> 要素を作成し、これを true に設定する必要もありました。

JBoss EAP 7 では、デフォルトの WebSocket サポートに対してサーバーを設定したり、アプリケーションがそれを使用するように設定したりする必要がなくなりました。WebSocket は Java EE 7 では必須で、必要なプロトコルはデフォルトで設定されています。さらに複雑な WebSocket の設定は、JBoss EAP サーバー設定ファイルの undertow サブシステムにある servlet-container で行います。以下のコマンドを実行すると、使用できる設定を表示できます。

/subsystem=undertow/servlet-container=default/setting=websockets:read-resource(recursive=true)
{
   "outcome" => "success",
   "result" => {
       "buffer-pool" => "default",
       "dispatch-to-worker" => true,
       "worker" => "default"
   }
}

また、WebSocket のコードサンプルは JBoss EAP に同梱されるクイックスタートに含まれています。

シングルサインオンサーバーの変更

JBoss EAP 7 でも、Infinispan サブシステムによって HA サービスの分散キャッシングサポートが Infinispan キャッシュの形式で提供されます。しかし、認証情報のキャッシングおよび分散の処理方法はこれまでのリリースとは異なります。

JBoss EAP 6 では、シングルサインオン (SSO) が Infinispan キャッシュに提供されないと、キャッシュが分散されませんでした。

JBoss EAP 7 では、HA プロファイルを選択すると SSO が自動的に分散されるようになりました。HA プロファイルを実行している場合、各ホストは web キャッシュコンテナーのデフォルトキャッシュを基にした独自の Infinispan キャッシュを持ちます。このキャッシュは関連するセッションとホストの SSO クッキーの情報を格納します。JBoss EAP は、各キャッシュ情報をすべてのホストに伝搬する処理を行います。JBoss EAP 7 では、明確に Infinispan キャッシュを SSO に割り当てる方法はありません。

JBoss EAP 7 では、SSO はサーバー設定ファイルの undertow サブシステムで設定されます。

JBoss EAP 7 に移行する際、アプリケーションコードを変更する必要はありません。

データソース設定の変更

JBDC データソースドライバー名

以前のリリースの JBoss EAP でデータソースを設定した場合、ドライバー名に指定される値は JDBC ドライバー JAR に含まれる META-INF/services/java.sql.Driver ファイルにリストされたクラスの数によって決まりました。

単一クラスを含むドライバー

META-INF/services/java.sql.Driver ファイルで指定されたクラスが 1 つのみであった場合、ドライバー名は単に JDBC ドライバー JAR の名前でした。これは JBoss EAP 7 でも変更ありません。

複数クラスを含むドライバー

JBoss EAP 6 では、META-INF/services/java.sql.Driver ファイルに複数のクラスが記載されている場合、以下の形式で JAR 名にドライバークラスにするクラスの名前とメジャーおよびマイナーバージョンを追加してクラスを指定していました。

JAR_NAME + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION

JBoss EAP 7 ではこれが変更され、以下の形式でドライバー名を指定します。

JAR_NAME + "_" + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION

注記

JAR_NAME と DRIVER_CLASS_NAME の間にアンダースコアが加えられています。

2 つのクラスが含まれるドライバーの例としては、MySQL 5.1.31 JDBC ドライバーが挙げられます。このドライバークラス名は com.mysql.jdbc.Driver となります。以下の 2 つの例では、JBoss EAP の以前のリリースと現行リリースにおけるドライバー名の指定方法の違いが示されています。

JBoss EAP 6 ドライバー名の例. 

mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1

JBoss EAP 7 ドライバー名の例. 

mysql-connector-java-5.1.31-bin.jar_com.mysql.jdbc.Driver_5_1

セキュリティーサーバー設定の変更

Java Security Manager のサーバー設定の変更に関する詳細は、JBoss EAP How To Configure Server Security の Considerations Moving from Previous Versions を参照してください。

トランザクションサブシステムの変更

JBoss EAP 6 の transactions サブシステムで使用できた Transaction Manager 設定属性の一部が JBoss EAP 7 で変更になりました。

削除されたトランザクションサブシステム属性

以下の表は、JBoss EAP 7 の transactions サブシステムから削除された JBoss EAP 6 の属性と、それらの代替となる同等の属性を示しています。

JBoss EAP 6 の属性
JBoss EAP 7 で代替となる属性

パス

object-store-path

relative-to

object-store-relative-to

非推奨となったトランザクションサブシステム属性

JBoss EAP 6 の transactions サブシステムで使用できた以下の属性は、JBoss EAP 7 では非推奨となりました。非推奨となった属性は将来のリリースで削除される可能性があります。以下の表はそれらの代替となる同等の属性を示しています。

JBoss EAP 6 の属性
JBoss EAP 7 で代替となる属性

use-hornetq-store

use-journal-store

hornetq-store-enable-async-io-to

journal-store-enable-async-io

enable-statistics

statistics-enabled

mod_cluster 設定の変更

JBoss EAP 7 では、mod_cluster の静的プロキシーの設定が変更になりました。

JBoss EAP 6 では、hostname:port の形式で指定された httpd プロキシーアドレスのカンマ区切りリストである proxy-list 属性を設定しました。

proxy-list 属性は JBoss EAP 7 では非推奨になりました。この属性は、アウトバウンドソケットバインディング名のリストである proxies 属性に置き換えられました。

この変更は、mod_cluster のアドバタイズを無効にするときなど、静的プロキシーリストを定義する方法に影響します。mod_cluster のアドバタイズを無効化する方法の詳細は、JBoss EAP Configuration Guide の Disable Advertising for mod_cluster を参照してください。

mod_cluster 属性の詳細は、 JBoss EAP Configuration Guide の mod_cluster Subsystem Attributes を参照してください。

第5章 アプリケーション移行の変更

Web サービスアプリケーションの変更

主に Apache CXF、Apache WSS4J、および Apache Santuario コンポーネントがアップグレードされ、JBossWS 5 は JBoss EAP 7 の Web サービスに新機能と改良されたパフォーマンスを提供します。

JAX-RPC サポートの変更

XML ベースの RPC (JAX-RPC) は Java EE 6 で非推奨となり、Java EE 7 ではオプションとなりました。JAX-RPC は JBoss EAP 7 では使用できず、サポートされません。JAX-RPC を使用するアプリケーションは、現在の Java EE 標準の Web サービスフレームワークである JAX-WS に移行する必要があります。

JAX-RPC web サービスの使用は、以下のいずれかの方法で特定できます。

JAX-RPC マッピングファイルの存在。これは、root 要素 <java-wsdl-mapping> のある XML ファイルです。

webservices.xml XML 記述子ファイルの存在。このファイルには <jaxrpc-mapping-file> 子要素が含まれる <webservice-description> 要素があります。以下に JAX-RPC Web サービスを定義する webservices.xml 記述子ファイルの例を示します。

<webservices xmlns="http://java.sun.com/xml/ns/j2ee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://www.ibm.com/webservices/xsd/j2ee_web_services_1_1.xsd" version="1.1">
  <webservice-description>
    <webservice-description-name>HelloService</webservice-description-name>
    <wsdl-file>WEB-INF/wsdl/HelloService.wsdl</wsdl-file>
    <jaxrpc-mapping-file>WEB-INF/mapping.xml</jaxrpc-mapping-file>
    <port-component>
      <port-component-name>Hello</port-component-name>
      <wsdl-port>HelloPort</wsdl-port>
      <service-endpoint-interface>org.jboss.chap12.hello.Hello</service-endpoint-interface>
      <service-impl-bean>
        <servlet-link>HelloWorldServlet</servlet-link>
      </service-impl-bean>
    </port-component>
  </webservice-description>
</webservices>

ejb-jar.xml ファイルの存在。これには、JAX-RPC マッピングファイルを参照する <service-ref> が含まれます。

Apache CXF Spring Web サービスの変更

以前のリリースの JBoss EAP では、エンドポイントデプロイメントアーカイブを jbossws-cxf.xml 設定ファイルに含め、JBossWS と Apache CXF の統合をカスタマイズすることができました。このユースケースの 1 つが、Apache CXF バスで Web サービスクライアントおよびサーバーエンドポイントのインターセプターチェインを設定することでした。この統合には、JBoss EAP サーバーに Spring をデプロイする必要がありました。

JBoss EAP 7 では、Spring の統合がサポートされないようになりました。jbossws-cxf.xml 記述子設定ファイルが含まれるアプリケーションを編集し、このファイルに定義されているカスタム設定を置き換える必要があります。JBoss EAP 7 でも Apache CXF API に直接アクセスすることはできますが、アプリケーションは移植できないことに注意してください。

可能な場合は、Spring のカスタム設定を新しい JBossWS 記述子設定オプションに置き換えることが推奨されます。この JBossWS 記述子ベースの方法では、クライアントエンドポイントコードを編集する必要がなく、同様の機能を提供できます。場合によっては、Spring を Context and Dependency Injection (コンテキストと依存性の注入、CDI) に置き換えることができます。

Apache CXF インターセプター

JBossWS 記述子は、クライアントエンドポイントコードを編集せずにインターセプターを宣言できる新しい設定オプションを提供します。 cxf.interceptors.in および cxf.interceptors.out プロパティーのインターセプタークラス名のリストを指定して、事前定義されたクライアントおよびエンドポイント設定内でインターセプターを宣言します。

以下は、これらのプロパティーを使用してインターセプターを宣言する jaxws-endpoint-config.xml ファイルの例です。

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointImpl</config-name>
    <property>
      <property-name>cxf.interceptors.in</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointInterceptor,org.jboss.test.ws.jaxws.cxf.interceptors.FooInterceptor</property-value>
    </property>
    <property>
      <property-name>cxf.interceptors.out</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointCounterInterceptor</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

Apache CXF の機能

JBossWS 記述子を使用すると、cxf.features プロパティーの機能クラス名のリストを指定して、事前定義のクライアントおよびエンドポイント設定内で機能を宣言できます。

以下は、このプロパティーを使用して機能を宣言する jaxws-endpoint-config.xml ファイルの例です。

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>Custom FI Config</config-name>
    <property>
      <property-name>cxf.features</property-name>
      <property-value>org.apache.cxf.feature.FastInfosetFeature</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

Apache CXF HTTP トランスポート

Apache CXF では、org.apache.cxf.transport.http.HTTPConduit オプションを指定すると HTTP トランスポートの設定を実行できます。JBossWS の統合により、以下のように Apache CXF API を使用して conduit がプログラム的に編集されます。

import org.apache.cxf.frontend.ClientProxy;
import org.apache.cxf.transport.http.HTTPConduit;
import org.apache.cxf.transports.http.configuration.HTTPClientPolicy;

// Set chunking threshold before using a JAX-WS port client
...
HTTPConduit conduit = (HTTPConduit)ClientProxy.getClient(port).getConduit();
HTTPClientPolicy client = conduit.getClient();

client.setChunkingThreshold(8192);
...

また、システムプロパティーを設定すると Apache CXF HTTPConduit のデフォルト値を制御および上書きできます。

プロパティー
タイプ
説明

cxf.client.allowChunking

ブール値

チャンキングを使用してリクエストを送信するかどうかを指定します。

cxf.client.chunkingThreshold

整数

非チャンキングからチャンキングモードに切り替えるしきい値を設定します。

cxf.client.connectionTimeout

Long

接続タイムアウトをミリ秒単位で設定します。

cxf.client.receiveTimeout

Long

受信タイムアウトをミリ秒単位で設定します。

cxf.client.connection

文字列

Keep-Alive または close 接続タイプを使用するかどうかを指定します。

cxf.tls-client.disableCNCheck

ブール値

CN ホスト名チェックを無効化するかどうかを指定します。

WS-Security の変更

アプリケーションに、org.apache.ws.security.WSPasswordCallback クラスにアクセスするカスタムコールバックハンドラーが含まれている場合、このクラスは org.apache.wss4j.common.ext パッケージに移動されたため注意してください。

ほとんどの SAML Bean オブジェクトは org.apache.ws.security.saml.ext パッケージから org.apache.wss4j.common.saml package に移動されました。

RSA v1.5キートランスポートおよび関連するすべてのアルゴリズムの使用はデフォルトで禁止されています。

これまで、セキュリティートークンサービス (STS) は onBehalfOf トークンのみを検証しましたが、ActAs トークンも検証するようになりました。そのため、ActAs トークンに提供される UsernameToken に有効なユーザー名とパスワードを指定する必要があります。

SAML Bearer トークンには内部署名が必要になりました。署名の検証を有効または無効にするため、org.apache.wss4j.dom.validate.SamlAssertionValidatorクラスに setRequireBearerSignature() メソッドが含まれるようになりました。

JBoss モジュール構造の変更

cxf-api および cxf-rt-core JAR が 1つの cxf-core JAR に統合されました。そのため、JBoss EAP の org.apache.cxf モジュールに cxf-core JAR が含まれるようになり、これまでのリリースよりも多いクラスが公開されました。

Bouncy Castle の要件の変更

XML/WS-Security での対称暗号化で Galois/Counter Mode (GCM) を用いた AES 暗号化を使用したい場合、BouncyCastle Security Provider が必要になります。

JBoss EAP 7 には org.bouncycastle モジュールが同梱されているため、JBossWS はそのクラスローダーに依存して BouncyCastle Security Provider を入手および使用できるようになりました。そのため、現在の JVM に BouncyCastle を静的にインストールする必要がなくなりました。コンテナーの外部で実行しているアプリケーションの場合、BouncyCastle ライブラリーをクラスパスに追加すると JBossWS はこのセキュリティープロバイダーを使用できます。

この動作を無効にするには、jaxws-endpoint-config.xml デプロイメント記述子ファイル (サーバーの場合) または jaxws-client-config.xml 記述子ファイル (クライアントの場合) で org.jboss.ws.cxf.noLocalBC プロパティーの値を true に設定します。

JBoss EAP に同梱されるバージョンでないものを使用したい場合は、BouncyCastle を静的に JVM にインストールできます。この場合、静的にインストールされた BouncyCastle Security Provider はクラスパスに存在するプロバイダーよりも優先的に選択されます。この問題を回避するには、BouncyCastle 1.49、1.51、またはそれ以降のバージョンを使用する必要があります。

Apache CXF バス選択ストラテジー

コンテナー内で実行されているクライアントのデフォルトのバス選択ストラテジーが THREAD_BUS から TCCL_BUS に変更されました。コンテナー外部で実行されているクライアントのデフォルトストラテジーは THREAD_BUS で、変更はありません。以下の方法の 1 つを使用すると、以前のリリースでの動作を復元できます。

org.jboss.ws.cxf.jaxws-client.bus.strategy システムプロパティーの値を THREAD_BUS に設定して JBoss EAP サーバーを起動します。

クライアントコードで選択ストラテジーを明示的に設定します。

WebServiceRef の JAX-WS 2.2 要件

コンテナーは WebServiceFeature を使用して JAX-WS 2.2 スタイルのコンストラクターを使用し、Web サービス参照へインジェクトされるクライアントを構築する必要があります。よって、コンテナーによってインジェクトされるユーザー提供のサービスクラスは JAX-WS 2.2 以上を実装する必要があります。

IgnoreHttpsHost CN チェックの変更

以前のリリースでは、システムプロパティー org.jboss.security.ignoreHttpsHost を true に設定すると、証明書にあるサービスの一般名 (CN) に対する HTTPS URL ホスト名チェックを無効にすることができました。このシステムプロパティー名は cxf.tls-client.disableCNCheck に置き換えられました。

サーバー側設定およびクラスローディング

サービスエンドポイントおよびサービスクライアントハンドラーへのインジェクションが有効になったため、org.jboss.as.webservices.server.integration JBoss モジュールから自動的にハンドラークラスをロードすることができなくなりました。アプリケーションが事前定義の設定に依存する場合、デプロイメントの新しいモジュール依存関係を明示的に定義する必要があることがあります。詳細は明示的なモジュール依存関係の移行を参照してください。

Java Endorsed Standards Override Mechanism の非推奨

Java Endorsed Standards Override Mechanism は JDK 1.8_40 では非推奨になり、JDK 9 では削除される予定です。これは、JAR を JRE 内の endorsed ディレクトリーに置くことで、デプロイされたアプリケーションすべてがライブラリーを利用できるメカニズムです。

アプリケーションが Apache CXF の JBossWS 実装を使用する場合、JBoss EAP 7 では必要な依存関係が正しい順序で追加されるため、この変更による影響はないはずです。 アプリケーションが Apache CXF に直接アクセスする場合、アプリケーションデプロイメントの一部として JBossWS の依存関係の後に Apache CXF の依存関係を提供する必要があります。

EAR アーカイブでの記述子の仕様

以前のリリースの JBoss EAP では、EJB Web サービスデプロイメントの jboss-webservices.xml デプロイメント記述子ファイルを JAR アーカイブの META-INF/ ディレクトリーまたは POJO Web サービスデプロイメントの WEB-INF/ ディレクトリーと、WAR アーカイブにバンドル化された EJB Web サービスエンドポイントに設定することができました。

JBoss EAP 7 では、jboss-webservices.xml デプロイメント記述子ファイルを EAR アーカイブの META-INF/ ディレクトリーで設定できるようになりました。jboss-webservices.xml ファイルが EAR アーカイブと JAR (または WAR) アーカイブの両方で見つかった場合、JAR または WAR の jboss-webservices.xml ファイルにある設定データによって EAR 記述子ファイルの対応するデータが上書きされます。

リモート URL コネクターおよびポートの更新

JBoss EAP 7 では、デフォルトのコネクターが remote から http-remoting に変更になり、デフォルトのリモート接続ポートが 4447 から 8080 に変更になりました。デフォルト設定の JNDI プロバイダー URL は remote://localhost:4447 から http-remoting://localhost:8080 に変更になりました。

JBoss EAP 7 の migrate 操作を使用して設定を更新すると、移行操作によってサブシステム設定の JBoss EAP 6 remoting コネクターおよび 4447 ポート設定が保持されるため、リモートコネクター、リモートポート、または JNDI プロバイダー URL を変更する必要がありません。migrate 操作の詳細は、管理 CLI の移行操作を参照してください。

migrate 操作を使用せずに、新しい JBoss EAP 7 のデフォルト設定を使用して実行する場合は、新しい設定を使用するようにリモートコネクター、リモートポート、および JNDI プロバイダー URL を変更する必要があります。

メッセージングアプリケーションの変更

JMS デプロイメント記述子の置き換えおよび更新

ネーミングパターン -jms.xml によって識別されたプロプラエタリーの JMS リソースデプロイメント記述子ファイルは JBoss EAP 7 で非推奨になりました。以下は、JBoss EAP 6 での JMSリソースデプロイメント記述子ファイルの例になります。

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0">
  <hornetq-server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </hornetq-server>
</messaging-deployment>

以前のリリースで -jms.xml JMS デプロイメント記述子をアプリケーションで使用した場合、 Java EE 7 仕様の EE.5.18 で指定されたとおりに標準の Java EE 7 デプロイメント記述子を使用するようアプリケーションを変換するか、JBoss EAP 7 の messaging-activemq サブシステムを使用するようデプロイメント記述子を更新してください。

記述子の更新を選択した場合、以下の変更を加える必要があります。

ネームスペースを "urn:jboss:messaging-deployment:1.0" から "urn:jboss:messaging-activemq-deployment:1.0" に変更します。

<hornetq-server> 要素名を <server> に変更します。

編集後のファイルは以下の例のようになるはずです。

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-activemq-deployment:1.0">
  <server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </server>
</messaging-deployment>

メッセージングに関するサーバー設定の変更については、 メッセージングサーバー設定の変更を参照してください。

外部 JMS クライアントの更新

JBoss EAP 7 は JMS 1.1 API をサポートするため、コードを変更する必要はありません。

JBoss EAP 7 ではデフォルトのリモートコネクターおよびポートが変更になりました。この変更の詳細は リモート URL コネクターおよびポートの更新を参照してください。

migrate 操作を使用してサーバー設定を移行する場合、これまでの設定は保持され、PROVIDER_URL を更新する必要はありません。しかし、新しい JBoss EAP 7 のデフォルト設定を使用して実行する場合は、新しい http-remoting://localhost:8080 設定を使用するよう PROVIDER_URL を変更する必要があります。詳細はリモートネーミングクライアントコードの移行を参照してください。

JMS 2.0 API を使用するためにコードを移行する計画がある場合は、作業例を helloworld-jms クイックスタートで確認してください。

HornetQ API の置換

JBoss EAP 6 には org.hornetq モジュールが含まれ、これによりアプリケーションソースコードで HornetQ API が使用できました。

JBoss EAP 7 では HornetQ が Apache ActiveMQ Artemis に置き換えられたため、HornetQ API を使用したコードは Apache ActiveMQ Artemis API を使用するように移行する必要があります。この API のライブラリーは、org.apache.activemq.artemis モジュールに含まれています。

ActiveMQ Artemis は HornetQ の進化版なので、概念の多くは継続して適用されます。

JAX-RS および RESTEasy アプリケーションの変更

JBoss EAP の以前のリリースでは、JAX-RS 1.x の実装である RESTEasy 2 がバンドルされていました。JBoss EAP 7 には、JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services 仕様で定義されている JAX-RS 2.0 の実装となる RESTEasy 3 が含まれています。RESTful Web サービスの Java API に関する詳細情報は、JAX-RS 2.0 API Specification を参照してください。

JBoss EAP に含まれる Jackson のバージョンは変更されました。JBoss EAP の以前のリリースに含まれていた Jackson は 1.9.9 でしたが、JBoss EAP 7 には Jackson 2.6.3 またはそれ以降が含まれています。

本セクションでは、RESTEasy または JAX-RS を使用するアプリケーションにこれらの変更が及ぼす影響について説明します。

非推奨の RESTEasy クラス

インターセプターおよび MessageBody クラス

JSR 311: JAX-RS: The Java™ API for RESTful Web Services にはインターセプターフレームワークが含まれていなかったため、RESTEasy 2 によって提供されました。JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services では正式なインターセプターとフィルターフレームワークが導入されたため、RESTEasy 2 に含まれていたインターセプターフレームワークは非推奨となり、RESTEasy 3.x. の JAX-RS 2.0 準拠のインターセプターファシリティーに置き換えられました。関連するインターフェースは、jaxrs-api モジュールの javax.ws.rs.ext パッケージに定義されます。

RESTEasy 3.x では、以下のインターセプターインターフェースが非推奨になりました。

org.jboss.resteasy.spi.interception.PreProcessInterceptor

org.jboss.resteasy.spi.interception.PostProcessInterceptor

org.jboss.resteasy.spi.interception.ClientExecutionInterceptor

org.jboss.resteasy.spi.interception.ClientExecutionContext

org.jboss.resteasy.spi.interception.AcceptedByMethod

org.jboss.resteasy.spi.interception.PreProcessInterceptor インターフェースは RESTEasy 3.x の javax.ws.rs.container.ContainerRequestFilter インターフェースに置き換えられました。

RESTEasy 3.x では、以下のインターフェースとクラスも非推奨になりました。

org.jboss.resteasy.spi.interception.MessageBodyReaderInterceptor

org.jboss.resteasy.spi.interception.MessageBodyWriterInterceptor

org.jboss.resteasy.spi.interception.MessageBodyWriterContext

org.jboss.resteasy.spi.interception.MessageBodyReaderContext

org.jboss.resteasy.core.interception.InterceptorRegistry

org.jboss.resteasy.core.interception.InterceptorRegistryListener

org.jboss.resteasy.core.interception.ClientExecutionContextImpl

The org.jboss.resteasy.spi.interception.MessageBodyWriterInterceptor インターフェースは javax.ws.rs.ext.WriterInterceptor インターフェースに置き換えられました。

さらに、javax.ws.rs.ext.MessageBodyWriter インターフェースの一部の変更は JAX-RS 1.x に対して後方互換性がない可能性があります。アプリケーションが JAX-RS 1.x を使用した場合はアプリケーションコードを確認し、エンドポイントに @Produces または @Consumes を定義するようにしてください。この定義を怠ると、以下のようなエラーが発生することがあります。

org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: <OBJECT> of media type:

以下に、このエラーの原因となる REST エンドポイントの例を示します。

@Path("dates")
public class DateService {

    @GET
    @Path("daysuntil/{targetdate}")
    public long showDaysUntil(@PathParam("targetdate") String targetDate) {
        DateLogger.LOGGER.logDaysUntilRequest(targetDate);
        final long days;

        try {
            final LocalDate date = LocalDate.parse(targetDate, DateTimeFormatter.ISO_DATE);
            days = ChronoUnit.DAYS.between(LocalDate.now(), date);
        } catch (DateTimeParseException ex) {
          // ** DISCLAIMER **. This example is contrived.
          throw new WebApplicationException(Response.status(400).entity(ex.getLocalizedMessage()).type(MediaType.TEXT_PLAIN)
              .build());
        }
        return days;
    }
}

この問題を修正するには、次のように javax.ws.rs.Produces のインポートと @Produces アノテーションを追加します。

...
import javax.ws.rs.Produces;
...

@Path("dates")
public class DateService {

    @GET
    @Path("daysuntil/{targetdate}")
    @Produces(MediaType.TEXT_PLAIN)
    public long showDaysUntil(@PathParam("targetdate") String targetDate) {
        DateLogger.LOGGER.logDaysUntilRequest(targetDate);
        final long days;

        try {
            final LocalDate date = LocalDate.parse(targetDate, DateTimeFormatter.ISO_DATE);
            days = ChronoUnit.DAYS.between(LocalDate.now(), date);
        } catch (DateTimeParseException ex) {
          // ** DISCLAIMER **. This example is contrived.
          throw new WebApplicationException(Response.status(400).entity(ex.getLocalizedMessage()).type(MediaType.TEXT_PLAIN)
              .build());
        }
        return days;
    }
}

注記

RESTEasy の以前のリリースからのインターセプターはすべて、新規の JAX-RS 2.0 フィルターおよびインターセプターインターフェースと並行して実行することが可能です。

インターセプターについての詳細情報は、JBoss EAP Developing Web Services Applications の RESTEasy Interceptors を参照してください。

新しい代替の API については、RESTEasy JAX-RS 3.0.13.Final API もしくはそれ以降を参照してください。

クライアント API

resteasy-jaxrs の RESTeasy クライアントフレームワークは、JAX-RS 2.0 準拠の resteasy-client モジュールに置き換えられました。そのため、RESTEasy クライアント API クラスおよびメソッドの中には非推奨となっているものもあります。

以下のクラスは非推奨になりました。

org.jboss.resteasy.client.ClientRequest

org.jboss.resteasy.client.ClientRequestFactory

org.jboss.resteasy.client.ClientResponse

org.jboss.resteasy.client.ProxyBuilder

org.jboss.resteasy.client.ProxyConfig

org.jboss.resteasy.client.ProxyFactory

org.jboss.resteasy.client.ClientResponseFailure 例外、org.jboss.resteasy.client.ClientExecutor インターフェースおよび org.jboss.resteasy.client.EntityTypeFactory インターフェースも非推奨になりました。

org.jboss.resteasy.client.ClientRequest および org.jboss.resteasy.client.ClientResponse クラスを、それぞれ org.jboss.resteasy.client.jaxrs.ResteasyClient および javax.ws.rs.core.Response に置き換える必要があります。

以下は RESTEasy 2.3.x の RESTEasy クライアントでリンクヘッダーを送信する例です。

ClientRequest request = new ClientRequest(generateURL("/linkheader/str"));
request.addLink("previous chapter", "previous", "http://example.com/TheBook/chapter2", null);
ClientResponse response = request.post();
LinkHeader header = response.getLinkHeader();

以下は RESTEasy 3 の RESTEasy クライアントで上記と同じタスクを実行する例です。

ResteasyClient client = new ResteasyClientBuilder().build();
Response response = client.target(generateURL("/linkheader/str")).request()
    .header("Link", "<http://example.com/TheBook/chapter2>; rel=\"previous\";
title=\"previous chapter\"").post(Entity.text(new String()));
javax.ws.rs.core.Link link = response.getLink("previous");

JAX-RS Web サービスと対話する外部 JAX-RS RESTEasy クライアントの例は、resteasy-jaxrs-client クイックスタートを参照してください。

org.jboss.resteasy.client.cache パッケージのクラスおよびインターフェースも非推奨になりました。これらのクラスとインターフェースは、org.jboss.resteasy.client.jaxrs.cache パッケージの同等のクラスおよびインターフェースに置き換えられました。

注記

org.jboss.resteasy.client.jaxrs API クラスの詳細については、The RESTEasy JAX-RS JavaDoc を参照してください。

StringConverter

org.jboss.resteasy.spi.StringConverter クラスは RESTEasy 3.x では非推奨になりました。この機能は JAX-RS 2.0 の jax.ws.rs.ext.ParamConverterProvider クラスを使用して置き換えできます。

削除または保護されている RESTEasy クラス

ResteasyProviderFactory Add メソッド

org.jboss.resteasy.spi.ResteasyProviderFactory add() メソッドのほとんどは、RESTEasy 3.0 で削除または保護されました。たとえば、addBuiltInMessageBodyReader() および addBuiltInMessageBodyWriter() メソッドは削除され、 addMessageBodyReader() および addMessageBodyWriter() メソッドは保護されました。

現時点では、registerProvider() と registerProviderInstance() のメソッドを使用してください。

RESTEasy 3 から削除された他のクラス

@org.jboss.resteasy.annotations.cache.ServerCached アノテーションは、JAX-RS メソッドへの応答をサーバーでキャッシュすることを指定するものでしたが、これは RESTEasy 3 から削除されたので、アプリケーションコードから削除する必要があります。

他の RESTEasy 変更点

SignedInput および SignedOuput

resteasy-crypto の SignedInput および SignedOutput は、Content-Type を Request または Response オブジェクトのいずれかから multipart/signed に設定する必要があります。そうでない場合は、@Consumes または @Produces アノテーションを使用する必要があります。

SignedOutput および SignedInput を使用すると、@Produces または @Consumes アノテーションで application/pkcs7-signature MIME タイプを設定して、そのタイプの形式をバイナリ形式で返すことができます。

@Produces または @Consumes が text/plain MIME タイプの場合、SignedOutput は base64 でエンコードされ、文字列として送信されます。

セキュリティーフィルター

@RolesAllowed、@PermitAll、および @DenyAll のセキュリティーフィルターは、"401 Unauthorized" ではなく "403 Forbidden" を返すようになりました。

クライアント側のフィルター

以前のリリースからの RESTEasy クライアント API を使用している場合は、新しい JAX-RS 2.0 クライアント側のフィルターはバインドされず、実行されません。

非同期 HTTP サポート

JAX-RS 2.0 仕様は、@Suspended アノテーションと AsynResponse インターフェースを使用した非同期 HTTP サポートを追加するので、非同期 HTTP の RESTEasy 専用 API は非推奨となっており、RESTEasy 3.1 にしてからできるだけ早く削除することが望まれます。非同期 Tomcat と非同期 JBoss Web モジュールもサーバーインストールから削除されています。Servlet 3.0 コンテナーまたはそれ以降を使用している場合以外は、非同期 HTTP サーバー側の処理がシミュレートされ、同一リクエストスレッドで同期的に実行されます。

サーバー側のキャッシュ

サーバー側のキャッシュ設定が変更されました。詳細は、RESTEasy Documentation を参照してください。

RESTEasy SPI の変更点

SPI 例外

すべての SPI 失敗例外は非推奨となり、内部的には使用されません。これらは対応する JAX-RS 2.0 例外に置き換えられました。

非推奨の例外
jaxrs-api モジュールでの代替の例外

org.jboss.resteasy.spi.ForbiddenException

javax.ws.rs.ForbiddenException

org.jboss.resteasy.spi.MethodNotAllowedException

javax.ws.rs.NotAllowedException

org.jboss.resteasy.spi.NotAcceptableException

javax.ws.rs.NotAcceptableException

org.jboss.resteasy.spi.NotFoundException

javax.ws.rs.NotFoundException

org.jboss.resteasy.spi.UnauthorizedException

javax.ws.rs.NotAuthorizedException

org.jboss.resteasy.spi.UnsupportedMediaTypeException

javax.ws.rs.NotSupportedException

InjectorFactory および Registry

InjectorFactory および Registry SPI が変更されました。ドキュメントおよびサポートに沿って RESTEasy を使用してる場合は、問題はありません。

Jackson プロバイダーの変更

JBoss EAP に含まれる Jackson のバージョンは変更されました。JBoss EAP の以前のリリースに含まれていた Jackson は 1.9.9 でしたが、JBoss EAP 7 には Jackson 2.6.3 またはそれ以降が含まれています。このため、Jackson プロバイダーは resteasy-jackson-provider から resteasy-jackson2-provider に変更されました。

resteasy-jackson2-provider へのアップグレードにはいくつかのパッケージ変更が必要になります。たとえば、Jackson アノテーションパッケージは org.codehaus.jackson.annotate から com.fasterxml.jackson.annotation に変更されました。

JBoss EAP の以前のリリースに含まれていたデフォルトのプロバイダーを使用するようにアプリケーションを切り替えるには、JBoss EAP Developing Web Services Applications の Switching the Default Jackson Provider を参照してください。

Spring RESTEasy 統合の変更

Spring 4.0 フレームワークは、Java 8 のサポートを導入しました。Spring と RESTEasy 3.x 統合を使用する場合は、使用するデプロイメントで最小 Spring バージョンに 4.2.x を指定してください。これは JBoss EAP 7 がサポートする安定性のある最も早期のバージョンです。

RESTEasy Jettison JSON プロバイダーの変更

RESTEasy Jettison JSON プロバイダーは JBoss EAP 7 では非推奨となり、デフォルトでデプロイメントに追加されなくなりました。推奨される RESTEasy Jackson プロバイダーに切り替えるようにしてください。Jettison プロバイダーの使用継続を希望する場合は、以下の例で示すように jboss-deployment-descriptor.xml ファイルでその明示的な依存関係を定義する必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <deployment>
    <exclusions>
      <module name="org.jboss.resteasy.resteasy-jackson2-provider"/>
      <module name="org.jboss.resteasy.resteasy-jackson-provider"/>
    </exclusions>
    <dependencies>
      <module name="org.jboss.resteasy.resteasy-jettison-provider" services="import"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

明示的な依存関係の定義方法については、JBoss EAP Development Guide の Add an Explicit Module Dependency to a Deployment を参照してください。

CDI 1.2 アプリケーションの変更

JBoss EAP 7 には CDI 1.2 のサポートが含まれています。このため、CDI 1.0 を使って書かれたアプリケーションは、JBoss EAP 7 に移行すると動作が異なる場合があります。本セクションでは、これらの変更点のいくつかのみをまとめています。

Weld および CDI 1.2 についての追加情報は、以下の参照先で確認できます。

Contexts and Dependency Injection for the Java EE platform

CDI 1.2 Javadoc

Weld 2.3.3.Final - CDI Reference Implementation

Bean アーカイブ

CDI によってスキャンされ、bean クラスを検索および処理するようにするため、有効な bean の bean クラスを bean アーカイブにデプロイする必要があります。

CDI 1.0 では、アプリケーションクライアント、EJB、またはライブラリー JAR の META-INF/ ディレクトリーに beans.xml ファイルが含まれた場合や、WAR の WEB-INF/ ディレクトリーに beans.xml ファイルが含まれた場合には、アーカイブが 明示的 bean アーカイブとして定義されました。

CDI 1.1 には 暗黙的 bean アーカイブが導入されました。これは bean を定義するアノテーションを持つ bean クラスが 1 つ以上またはセッション bean が 1 つ以上含まれるアーカイブです。 暗黙的な bean アーカイブは CDI によってスキャンされ、型検索中に bean を定義するアノテーションを持つクラスのみが検出されます。詳細は、Contexts and Dependency Injection for the Java EE platform の Type and Bean Discovery を参照してください。

bean アーカイブは all、annotated、または none の bean 検索モードを持ちます。バージョンのない beans.xml ファイルが含まれる bean アーカイブは、デフォルトの bean 検索モード all を持ちます。バージョンが 1.1 以上の beans.xml ファイルが含まれる bean アーカイブは bean-discovery-mode 属性を指定する必要があります。この属性のデフォルト値は annotated です。

以下の場合、アーカイブは bean アーカイブではありません。

bean-discovery-mode が none である beans.xml ファイルが含まれる場合。

beans.xml ファイルがない CDI 拡張が含まれる場合。

以下の場合、アーカイブは 明示的 bean アーカイブになります。

バージョン番号が 1.1 以上で、bean-discovery-mode が all の beans.xml ファイルがアーカイブに含まれる場合。

アーカイブにバージョン番号のない beans.xml ファイルが含まれる場合。

アーカイブに空の beans.xml ファイルが含まれる場合。

以下の場合、アーカイブは 暗黙的 bean アーカイブになります。

アーカイブに beans.xml ファイルが含まれなくても、bean を定義するアノテーションを持つ bean クラスが 1 つ以上含まれるか、セッション bean が 1 つ以上含まれる場合。

アーカイブに bean-discovery-mode が annotated beans.xml ファイルが含まれる場合。

CDI 1.2 は bean を定義するアノテーション を以下に限定します。

@ApplicationScoped、@SessionScoped、 @ConversationScoped、および @RequestScoped アノテーション

その他すべての通常スコープタイプ

@Interceptor および @Decorator アノテーション

@Stereotype アノテーションが付けられた stereotype アノテーションすべて

@Dependent スコープアノテーション

bean アーカイブの詳細は、 Contexts and Dependency Injection for the Java EE platform の Bean Archives を参照してください。

会話解決の明確化

会話コンテキストのライフサイクルは、CDI Specification Issue CDI-411 で説明されていサーブレット仕様との競合を回避するために変更されました。会話スコープはすべてのサーブレットリクエストの間はアクティブで、他のサーブレットやサーブレットフィルターによるリクエストボディーや文字エンコードの設定を妨げないはずです。

オブザーバー解決

イベント解決は、CDI 1.2 で部分的に書き換えられました。CDI 1.0 では、オブザーバーメソッドにすべてのイベント修飾子がある場合にイベントはオブザーバーメソッドに配信されました。CDI 1.2 では、オブザーバーメソッドにイベント修飾子がないかイベント修飾子のサブセットがある場合にイベントがオブザーバーメソッドに配信されます。

明示的なモジュール依存関係の移行

前リリースの JBoss EAP ではモジュラークラスローディングシステムと JBoss モジュールが導入され、アプリケーションが使用できるクラスを細かに制御することができました。この機能によって、アプリケーションの MANIFEST.MF ファイルまたは jboss-deployment-structure.xml デプロイメント記述子ファイルを使用して暗示的なモジュール依存関係を設定できました。

アプリケーションで明示的なモジュール依存関係を定義した場合、JBoss EAP 7 で変更になった以下の項目に注意してください。

利用可能な依存関係の確認

JBoss EAP に含まれるモジュールが変更されました。アプリケーションを JBoss EAP 7 に移行する場合、MANIFEST.MF および jboss-deployment-structure.xml ファイルエントリーを確認し、これらのエントリーが本リリースで削除されたモジュールを参照しないようにしてください。

アノテーションのスキャンに必要な依存関係

以前のリリースの JBoss EAP では、EJB インターセプターの宣言時など、アノテーションのスキャン中に処理される必要があるアノテーションが依存関係に含まれていると、Jandex インデックスを生成して新しい JAR ファイルに含まれるようにし、MANIFEST.MF または jboss-deployment-structure.xml デプロイメント記述子ファイルにフラグを設定する必要がありました。

JBoss EAP 7 では、静的モジュールに対するアノテーションインデックスの自動ランタイム生成が提供されるため、手動で生成する必要がなくなりました。しかし、JBoss EAP 7 でも以下のように annotations フラグを MANIFEST.MF ファイルまたは jboss-deployment-structure.xml デプロイメント記述子ファイルに追加する必要があります。

MANIFEST.MF ファイルのアノテーションフラグの例. 

Dependencies: com.company.my-ejb annotations, com.company.other

jboss-deployment-structure.xml ファイルのアノテーションフラグの例. 

<jboss-deployment-structure>
  <deployment>
    <dependencies>
      <module name="com.company.my-ejb" annotations="true"/>
      <module name="com.company.other"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

Hibernate および JPA の移行の変更

Hibernate ORM 5.0

アプリケーションに persistence.xml ファイルが含まれる場合や、コードが @PersistenceContext または @PersistenceUnit アノテーションを使用する場合、JBoss EAP 7 はデプロイメント中にこれを検出し、アプリケーションは JPA を使用すると仮定します。Hibernate ORM 5.O ライブラリーとその他の依存関係の一部が暗黙的にアプリケーションのクラスパスに追加され、デフォルトでこれらのライブラリーが使用されます。

Hibernate ORM 4.0 - 4.3

アプリケーションが 2 次キャッシュの有効化を必要とする場合、Infinispan 8.0 と統合されている Hibernate ORM 5.0 に移行してください。

Hibernate ORM 4.x で書かれているアプリケーションは今後も Hibernate 4.x を使用できます。Hibernate 4.x JAR のカスタム JBoss モジュールを定義し、アプリケーションから Hibernate 5 クラスを除外する必要があります。しかし、Hibernate 5 を使用するようアプリケーションコードを書き直すことが強く推奨されます。

Hibernate 4 と Hibernate 5 で変更になった内容に関する詳細は Hibernate ORM 5.0 Migration Guide を参照してください。

Hibernate ORM 3.0

前リリースで Hibernate 3 の使用を容易にした統合クラスは JBoss EAP 7 から削除されました。大きく手を加えないと Hibernate 3 は JBoss EAP では動作しないため、アプリケーションが Hibernate 3 ライブラリーを使用する場合は、Hibernate 5 を使用するようアプリケーションを移行することが強く推奨されます。Hibernate 5 に移行できない場合、Hibernate 3 JAR のカスタム JBoss Module を定義し、アプリケーションから Hibernate 5 クラスを除外する必要があります。

Hibernate Search の変更

JBoss EAP 7 に同梱される Hibernate Search のバージョンが変更になりました。以前のリリースの JBoss EAP には Hibernate Search 4.6.x が含まれていましたが、JBoss EAP 7 には Hibernate Search 5.5.x が同梱されます。

Hibernate Search 5.5 は Apache Lucene 5.3.1 に構築されます。ネイティブ Lucene API を使用する場合は、必ずこのバージョンに合わせてください。Hibernate Search 5.5 API は、バージョン 3 からバージョン 5 の間に加えられた複雑な Lucene API の変更の多くをラップし、隠していますが、クラスの一部は非推奨となったり、名前変更または再パッケージされています。ここでは、これらの変更がアプリケーションコードに与える影響について説明します。

Hibernate Search マッピングの変更

埋め込み関係の ID フィールドのインデックス化

@IndexedEmbedded アノテーションを使用して関連エントリーからのフィールドを含む場合、関連エントリーの id が含まれなくなりました。id が含まれるようにするには、@IndexedEmbedded アノテーションの includeEmbeddedObjectId 属性を使用します。

@IndexedEmbedded(includeEmbeddedObjectId=true)

番号および日付のインデックス形式の変更

番号や日付はデフォルトで数字フィールドとしてインデックス化されるようになりました。タイプ int、long、float、double のプロパティーおよびこれらのラッパークラスは文字列としてインデックス化されないようになりました。代わりに、これらは Lucene の適切な数字エンコーディングを使用してインデックス化されるようになりました。id フィールドはこのルールの例外で、 数字タイプによって表されても、デフォルトで文字列キーワードとしてインデックス化されます。@NumericField の使用は、数字エンコーディングのカスタム精度を指定する場合以外は廃止されました。文字列エンコーディングフィールドブリッジを明示的に指定すると、これまでの文字列ベースのインデックス形式を保持できます。整数の場合は org.hibernate.search.bridge.builtin.IntegerBridge になります。公開されているその他の使用可能なフィールドブリッジは、org.hibernate.search.bridge.builtin パッケージを確認してください。

Date および Calendar は文字列としてインデックス化されないようになりました。代わりに、インスタンスは 1970 年 1 月 1 日グリニッジ標準時 00:00:00 からの期間 (ミリ秒) を表す長整数としてエンコードされます。新しい EncodingType 列挙を使用するとインデックス形式を切り替えできます。以下に例を示します。

@DateBridge(encoding=EncodingType.STRING)
@CalendarBridge(encoding=EncodingType.STRING)

数字と日付のエンコーディングの変更は重要で、アプリケーションの動作に大きく影響する可能性があります。以前は文字列にエンコードされ、現在は数字にエンコードされるフィールドをターゲットとするクエリーがある場合、クエリーを更新する必要があります。NumericRangeQuery で数字フィールドを検索する必要があります。また、ファセッティングがターゲットとするすべてのフィールドが文字列でエンコードされるようにする必要があります。Search クエリー DSL を使用する場合、適切なクエリーが自動的に作成されるはずです。

その他の Hibernate Search の変更

ソートオプションが改良され、ソートオプションに対してフィールドエンコーディングが誤って指定されるとランタイム例外が発生するようになりました。また、あらかじめソートに使用されるフィールドが分かる場合、Lucene によってより高性能なソート機能が提供されます。Hibernate Search 5.5 は新しい @SortableField および @SortableFields アノテーションを提供します。詳細は、Migration Guide from Hibernate Search 5.4 to 5.5 を参照してください。

Lucene の SortField API には、以下のアプリケーションコードの変更を適用する必要があります。

以前のリリースの JBoss EAP では、以下のようにクエリーでソートフィールドのタイプを設定しました。

fulltextQuery.setSort(new Sort(new SortField("title", SortField.STRING)));

JBoss EAP 7 での設定例は次のとおりです。

fulltextQuery.setSort(new Sort(new SortField("title", SortField.Type.STRING)));

SearchFactory は ORM の統合でのみ使用される必要があるため、hibernate-search-engine モジュールから hibernate-search-orm モジュールに移動されました。他のインタグレーターは SearchIntegrator のみに依存する必要があります。SearchIntegrator は、非推奨となった SearchFactoryIntegrator の代わりに使用されます。

列挙値 SpatialMode.GRID の名前が SpatialMode.HASH に変更になりました。

FullTextIndexEventListener が最終クラスになりました。現在このクラスを拡張する場合、同じ機能を実現できる他の方法を見つける必要があります。

hibernate-search-analyzers モジュールが削除されました。org.apache.lucene:lucene-analyzers-common などの適切な Lucene アーティファクトを直接使用する方法が推奨されます。

JMS コントロール API が変更になりました。他の ORM 環境で使用できるようにするため、Hibernate ORM の JMS バックエンド依存関係が削除されました。そのため、 org.hibernate.search.backend.impl.jms.AbstractJMSHibernateSearchController のインプリメンターを新しい署名に応じて調整する必要があります。このクラスは内部クラスで、拡張せずに例として使用することが推奨されます。

org.hibernate.search.spi.ServiceProvider SPI がリファクターされました。古いサービスコントラクトで統合している場合は、ServiceManager、 Service、 Startable、および Stoppable の Hibernate Search 5.5 Javadoc で新しいコントラクトの詳細を確認してください。

Lucene 3.x によって生成されたインデックスを保持し、これらのインデックスを Hibernate Search 5.0 以上で再構築していない場合、IndexFormatTooOldException が発生します。マスインデクサーでインデックスを再構築することが推奨されます。再構築できない場合は、ILucene の IndexUpgrader を使用してください。デフォルトの動作が変更になった場合があるため、注意して Hibernate Search のマッピングを更新する必要があります。詳細は Apache Lucene Migration Guide を参照してください。

JBoss EAP 7 では、Apache Lucene が 3.6 から 5.3 にアップグレードされました。ご使用のコードが 直接 Lucene のコードをインポートする場合は、Apache Lucene Migration Guide で変更の詳細を確認してください。Lucene Change Log にも追加の情報が記載されています。

@Field(indexNullAs=) を使用してインデックスの null マーカー値をエンコードする場合、同じフィールドでインデックス化されるその他の値すべてに適合するマーカーのタイプである必要があります。たとえば、これまでは文字列「null」を使用して数字フィールドの null 値 をエンコードすることが可能でしたが、本リリースではこれができないようになりました。この代わりに、-1 などの null 値を表す数字を選択する必要があります。

ファセッティングエンジンに大幅な改良が加えられました。ほとんどの変更は API には影響しませんが、ファセッティングに使用する予定のフィールドすべてに @Facet または @Facets アノテーションを付ける必要があります。

Hibernate Search の名前変更および再パッケージされたクラス

以下は、名前変更または再パッケージされた Hibernate Search クラスのリストになります。

以前のパッケージおよびクラス
新しいパッケージおよびクラス

org.hibernate.search.Environment

org.hibernate.search.cfg.Environment

org.hibernate.search.FullTextFilter

org.hibernate.search.filter.FullTextFilter

org.hibernate.search.ProjectionConstants

org.hibernate.search.engine.ProjectionConstants

org.hibernate.search.SearchException

org.hibernate.search.exception.SearchException

org.hibernate.search.Version

org.hibernate.search.engine.Version

Lucene - 名前変更および再パッケージされたクラス

クエリーパーサーが新しいモジュールに移動されたため、パッケージが org.apache.lucene.queryParser.QueryParser から org.apache.lucene.queryparser.classic.QueryParser に変更になりました。

Lucene アナライザーの多くがリファクターされたため、パッケージが変更になりました。Apache Lucene Documentation を参照してください。

TokenizerFactory や TokenFilterFactory などの Apache Solr ユーティリティークラスの一部が Apache Lucene に移動されました。これらのユーティリティーやカスタムアナライザーがアプリケーションによって使用される場合は、Apache Lucene で新パッケージ名を探す必要があります。

詳細は Apache Lucene Migration Guide を参照してください。

Hibernate Search で非推奨となった API

Hibernate Search で非推奨となったインターフェース、クラス、列挙、アノテーションタイプ、メソッド、コンストラクター、および列挙定数の完全リストは、Hibernate Search Deprecated API ドキュメントを参照してください。

Hibernate Search で非推奨となったインターフェース

インターフェース
説明

org.hibernate.search.store.IndexShardingStrategy

Hibernate Search 4.4 で非推奨となりました。Hibernate Search 5 で削除される可能性があります。代わりに ShardIdentifierProvider を使用してください。

org.hibernate.search.store.Workspace

このインターフェースは削除され、非公開 API [HSEARCH-1915] として考慮される必要があります。

Hibernate Search で非推奨となったクラス

クラス
説明

org.hibernate.search.filter.FilterKey

カスタムフィルターキーは非推奨となり、Hibernate Search 6 で削除される予定です。Hibernate Search 5.1 では、Lucene フィルターをキャッシュするキーは指定のフィルターパラメーターを基に自動的に算出されます。

org.hibernate.search.filter.StandardFilterKey

カスタムフィルターキーは非推奨となり、Hibernate Search 6 で削除される予定です。Hibernate Search 5.1 では、Lucene フィルターをキャッシュするキーは指定のフィルターパラメーターを基に自動的に算出されます。

Hibernate Search で非推奨となった列挙

列挙
説明

org.hibernate.search.annotations.FieldCacheType

非推奨となったため CacheFromIndex アノテーションを削除します。Hibernate Search Deprecated Annotations を参照してください。

Hibernate Search で非推奨となったアノテーション

アノテーション
説明

org.hibernate.search.annotations.CacheFromIndex

アノテーションを削除してください。代替は必要ありません。

org.hibernate.search.annotations.Key

カスタムフィルターキャッシュキーは非推奨機能となり、Hibernate Search 6 で削除される予定です。Hibernate Search 5.1 では、フィルターキャッシュキーはフィルターパラメーターを基に自動的に判断されるため、キーオブジェクトを提供する必要がなくなりました。

Hibernate Search で非推奨となったメソッド

メソッド
説明

org.hibernate.search.FullTextSharedSessionBuilder.autoClose()

代替はありません。

org.hibernate.search.FullTextSharedSessionBuilder.autoClose(boolean)

代替はありません。

org.hibernate.search.cfg.IndexedMapping.cacheFromIndex(FieldCacheType…​)

今後削除される予定で、代替はありません。

org.hibernate.search.cfg.EntityDescriptor.getCacheInMemory()

今後削除される予定で、代替はありません。

org.hibernate.search.cfg.ContainedInMapping.numericField()

代わりに、field().numericField() を呼び出します。

org.hibernate.search.cfg.EntityDescriptor.setCacheInMemory(Map<String, Object>)

今後削除される予定で、代替はありません。

org.hibernate.search.MassIndexer.threadsForSubsequentFetching(int)

このメソッドは削除される予定です。

org.hibernate.search.query.dsl.FuzzyContext.withThreshold(float)

FuzzyContext.withEditDistanceUpTo(int) を使用します。

Hibernate Search で非推奨となったコンストラクター

コンストラクター
説明

org.hibernate.search.cfg.NumericFieldMapping(PropertyDescriptor, EntityDescriptor, SearchMapping)

代わりに NumericFieldMapping.NumericFieldMapping(String, PropertyDescriptor, EntityDescriptor, SearchMapping) を使用します。

上級インテグレーターに影響する変更

ここでは、パブリック API の一部ではない変更について説明します。これらのアーティファクトは、Hibernate Search フレームワークを拡張するインテグレーターのみがアクセスできる必要があるため、通常の開発者には影響はないはずです。

IndexWriterSetting.MAX_THREAD_STATES および IndexWriterSetting.TERM_INDEX_INTERVAL 列挙定数は非推奨になりました。これらは設定から読み取るプロパティーに影響します。実際にこれらの列挙定数がないと、 hibernate.search.Animals.2.indexwriter.term_index_interval = default などの設定プロパティーが無視されます。これによる影響は、プロパティーが適用されないことのみです。

SearchFactoryIntegrator インターフェースが非推奨になりました。SearchIntegrator を使用するよう、即座にすべてのコードを移行する必要があります。

SearchFactoryBuilder クラスが非推奨になりました。代わりに SearchIntegrationBuilder を使用してください。

HSQuery.getExtendedSearchIntegrator() メソッドが非推奨になりました。SearchIntegrator を使用できる可能性がありますが、このメソッドを削除することが推奨されます。

DocumentBuilderIndexedEntity.getFieldCacheOption() メソッドが非推奨になりました。代替メソッドはありません。

BuildContext.getIndexingStrategy() メソッドが非推奨になりました。代わりに BuildContext.getIndexingMode() を使用してください。

DirectoryHelper.getVerifiedIndexDir(String, Properties, boolean) メソッドが非推奨になりました。代わりに DirectoryHelper.getVerifiedIndexPath(java.lang.String, java.util.Properties, boolean) を使用してください。

以下は、名前変更または再パッケージされた Hibernate Search クラスのリストになります。

以前のパッケージおよびクラス
新しいパッケージおよびクラス

org.hibernate.search.engine.impl.SearchMappingBuilder

org.hibernate.search.engine.spi.SearchMappingHelper

org.hibernate.search.indexes.impl.DirectoryBasedIndexManager

org.hibernate.search.indexes.spi.DirectoryBasedIndexManager

org.hibernate.search.spi.MassIndexerFactory

org.hibernate.search.batchindexing.spi.MassIndexerFactory

org.hibernate.search.spi.SearchFactoryBuilder

org.hibernate.search.spi.SearchIntegratorBuilder

org.hibernate.search.spi.SearchFactoryIntegrator

org.hibernate.search.spi.SearchIntegrator

エンティティー Bean の JPA への移行

Java EE 7 では EJB エンティティー bean のサポートが任意となり、JBoss EAP 7 ではサポート対象外になりました。そのため、JBoss EAP 7 への移行時に CMP (Container-Managed Persistence) および BMP (Bean-Managed Persistence) エンティティー bean を書き直し、Java Persistence API (JPA) エンティティーを使用するようにする必要があります。

以前のリリースの JBoss EAP では、javax.ejb.EntityBean クラスを拡張し、必要なメソッドを実装してエンティティー bean がアプリケーションのソースコードに作成されました。作成後、エンティティー bean は ejb-jar.xml ファイルで設定されました。CMP エンティティー bean は、値が Container の <persistence-type> 子要素が含まれる <entity> 要素を使用して指定されました。BMP エンティティー bean は、値が Bean の <persistence-type> 子要素が含まれる <entity> 要素を使用して指定されました。

JBoss EAP 7 では、コードの CMP および BMP エンティティー bean を Java Persistence API (JPA) エンティティーに置き換える必要があります。JPA エンティティーは javax.persistence.* クラスを使用して作成され、persistence.xml ファイルに定義されます。

以下は JPA エンティティークラスの例になります。

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
// User is a keyword in some SQL dialects!
@Table(name = "MyUsers")
public class MyUser {
    @Id
    @GeneratedValue
    private Long id;

    @Column(unique = true)
    private String username;
    private String firstName;
    private String lastName;

    public Long getId() {
        return id;
    }
    public String getUsername() {
        return username;
    }
    public void setUsername(String username) {
        this.username = username;
    }
    public String getFirstName() {
        return firstName;
    }
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

以下は persistence.xml ファイルの例になります。

<persistence version="2.1"
      xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="
        http://xmlns.jcp.org/xml/ns/persistence
        http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
  <persistence-unit name="my-unique-persistence-unit-name">
    <properties>
      // properties...
    </properties>
  </persistence-unit>
</persistence>

JAP エンティティーの実施例は、JBoss EAP 7 に同梱される bmt、cmt、および hibernate5 クイックスタートを参照してください。

JPA 永続プロパティーの変更

これまでの JBoss EAP リリースでの永続性動作と互換性を維持するため、新しい永続プロパティー jboss.as.jpa.deferdetach が追加されました。

jboss.as.jpa.deferdetach プロパティーは、非 JTA トランザクションスレッドで使用されるトランザクションスコープの永続コンテキストが各 EntityManager 呼び出しの後にロードされたエントリーをデタッチするかどうか、または永続コンテキストが閉じられるまで待機するかどうか (セッション bean が終了するときなど) を制御します。このプロパティーのデフォルト値は false で、各 EntityManager 呼び出しの後にエンティティーがデタッチまたは消去されます。これは、JPA 仕様 で定義されている正しいデフォルト動作です。プロパティーの値が true に設定されると、永続コンテキストが閉じられるまでエンティティーはデタッチされません。

JBoss EAP 5 では、jboss.as.jpa.deferdetach プロパティーが true に設定された場合と同様に永続性が動作しました。JBoss EAP 5 から JBoss EAP 7 に移行するときにこの動作を保持するには、以下の例のように persistence.xml で jboss.as.jpa.deferdetach プロパティーの値を true に設定する必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
    <persistence-unit name="EAP5_COMPAT_PU">
    <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
    <properties>
         <property name="jboss.as.jpa.deferdetach" value="true" />
    </properties>
  </persistence-unit>
</persistence>

In JBoss EAP 6 では、jboss.as.jpa.deferdetach プロパティーが false に設定された場合と同様に永続性が動作しました。 これは JBoss EAP 7 での動作と同じであるため、アプリケーションの移行時に変更を加える必要はありません。

EJB クライアントコードの移行

JBoss EAP 7 ではデフォルトのリモートコネクターおよびポートが変更になりました。この変更の詳細は リモート URL コネクターおよびポートの更新を参照してください。

migrate 操作を使用してサーバー設定を移行した場合は、旧設定は保持されるため以下の変更を行う必要はありません。しかし、新しい JBoss EAP 7 のデフォルト設定で実行する場合は以下の変更を行う必要があります。

デフォルトのリモート接続ポートの更新

jboss-ejb-client.properties ファイルのリモート接続ポートの値を 4447 から 8080 に変更します。

以下は、前リリースと本リリースの jboss-ejb-client.properties ファイルの例になります。

例: JBoss EAP 6 の jboss-ejb-client.properties ファイル. 

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

例: JBoss EAP 7 の jboss-ejb-client.properties ファイル. 

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

デフォルトコネクターの更新

新しい JBoss EAP 7 設定で実行している場合、デフォルトのコネクターは remote から http-remoting に変更になりました。この変更は、使用するライブラリーと接続するサーバーの JBoss EAP リリースが異なるクライアントに影響します。

クライアントアプリケーションが JBoss EAP 6 の EJB クライアントライブラリーを使用し、JBoss EAP 7 サーバーへ接続する場合、8080 以外のポートで remote コネクターを公開するようサーバーを設定する必要があります。

JBoss EAP 7 の EJB クライアントライブラリーを使用し、JBoss EAP 6 サーバーへ接続するクライアントアプリケーションは、サーバーインスタンスによって http-remoting コネクターは使用されず、remote コネクターが使用されることを認識する必要があります。これは、新しいクライアント側接続プロパティーを定義することで実現されます。

remote.connection.default.protocol=remote

リモートネーミングクライアントコードの移行

新しいデフォルトの JBoss EAP 7 設定で実行している場合、新しいデフォルトのリモートポートおよびコネクターを使用するようクライアントコードを変更する必要があります。

以下の例は、リモートネーミングプロパティーが JBoss EAP 6 のクライアントコードでどのように指定されていたかを示しています。

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=remote://localhost:4447

以下は、JBoss EAP 7 のクライアントコードでリモートネーミングプロパティーを指定する方法の例になります。

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=http-remoting://localhost:8080

デプロイメント計画設定の移行

Java EE Application Deployment 仕様 (JSR-88) は、すべての Java EE プラットフォームの製品でアプリケーションを設定およびデプロイするため、複数のプロバイダーからツールを有効にする標準的なコントラクトを定義することが目的でした。コントラクトは、Java EE Product Provider が DeploymentManager を実装し、Tool Provider が他の javax.enterprise.deploy.spi インターフェースにアクセスすることを必要としました。JBoss EAP 6 の場合、デプロイメント計画は、ZIP または JAR アーカイブでバンドルされる deployment-plan.xml という XML 記述子によって識別されます。

ほとんどのアプリケーションサーバー製品は、より機能の充実した独自のデプロイメントソルーションを提供するため、この仕様の採用は限定的でした。そのため、JSR-88 のサポートは JBoss EE 7 より廃止されたため、JBoss EAP 7 でも廃止されました。

アプリケーションのデプロイに JSR-88 を使用した場合、他の方法を使ってアプリケーションをデプロイする必要があります。JBoss EAP 管理 CLI の deploy コマンドを使用すると、アーカイブをスタンドアロンサーバーや管理対象ドメインのサーバーグループにデプロイする標準的な方法を実行できます。管理 CLI についての詳細情報は、Management CLI Guide を参照してください。

カスタムアプリケーションバルブの移行

カスタムバルブまたは jboss-web.xml XML ファイルで定義されたバルブは、手動で移行する必要があります。これには、org.apache.catalina.valves.ValveBase クラスを拡張して作成されたバルブや、jboss-web.xml 記述子ファイルの <valve> 要素で設定されたバルブが含まれます。

重要

jboss-web.xml ファイルに定義されたカスタムバルブおよびバルブは、対応する Undertow のビルトインハンドラーで書き直すか、置き換える必要があります。Undertow ハンドラーへのバルブのマッピングに関する詳細はJBoss Web バルブの移行 を参照してください。

認証バルブは、Undertow ビルトイン認証メカニズムを使用して手動で置き換える必要があります。

デプロイメントで設定されたバルブの移行

JBoss EAP 6 では、カスタムバルブを jboss-web.xml web アプリケーション記述子ファイルで設定するとアプリケーションレベルで定義することができました。JBoss EAP 7 では、Undertow ハンドラーを使用して定義することもできます。

以下は、JBoss EAP 6 の jboss-web.xml ファイルに設定されたバルブの例になります。

<jboss-web>
    <valve>
        <class-name>org.jboss.examples.MyValve</class-name>
​        <param>
    ​        <param-name>myParam</param-name>
​            <param-value>foobar</param-value>
    ​    </param>
    </valve>
</jboss-web>

JBoss EAP でカスタムハンドラーを作成および設定する方法の詳細は、JBoss EAP Development Guide の Creating Custom Handlers を参照してください。

カスタムオーセンティケーターバルブの移行

オーセンティケーターバルブを移行する方法については、セキュリティーアプリケーションの変更を参照してください。

セキュリティーアプリケーションの変更

JBoss Web を Undertow で置き換えるには、JBoss EAP 7 のセキュリティー設定における変更が必要になります。

オーセンティケーターバルブの移行

オーセンティケーターバルブは、Undertow ビルトイン認証メカニズムを使用して手動で置き換える必要があります。オーセンティケーターバルブを移行する方法は、以下の項を参照してください。

PicketLink の変更

SSO の SAML v2 設定で必要となる変更についての情報は、JBoss EAP の How to Set Up SSO with SAML v2 で Changes from Previous Versions of JBoss EAP を参照してください。

その他のセキュリティーアプリケーションの変更

Kerberos による SSO 設定についての相違点については、JBoss EAP の How to Set Up SSO with Kerberos で Differences from Configuring Previous Versions JBoss EAP を参照してください。

JBoss Logging の変更

アプリケーションが JBoss Logging を使用する場合、org.jboss.logging パッケージのアノテーションは JBoss EAP 7 では非推奨になったことに注意してください。アノテーションは org.jboss.logging.annotations パッケージに移動されたため、ソースコードを更新して新しいパッケージをインポートする必要があります。

また、アノテーションは個別の Maven groupId:artifactId:version (GAV) ID に移動されたため、プロジェクトの pom.xml ファイルで org.jboss.logging:jboss-logging-annotations の新しいプロジェクト依存関係を追加する必要があります。

注記

ロギングアノテーションのみが移動されました。 org.jboss.logging.BasicLogger および org.jboss.logging.Logger は、これまでどおり org.jboss.logging パッケージにあります。

非推奨となったアノテーションクラスと代替クラスを以下の表に示します。

表5.1 非推奨となったロギングアノテーションの代替

非推奨となったクラス
代替クラス

org.jboss.logging.Cause

org.jboss.logging.annotations.Cause

org.jboss.logging.Field

org.jboss.logging.annotations.Field

org.jboss.logging.FormatWith

org.jboss.logging.annotations.FormatWith

org.jboss.logging.LoggingClass

org.jboss.logging.annotations.LoggingClass

org.jboss.logging.LogMessage

org.jboss.logging.annotations.LogMessage

org.jboss.logging.Message

org.jboss.logging.annotations.Message

org.jboss.logging.MessageBundle

org.jboss.logging.annotations.MessageBundle

org.jboss.logging.MessageLogger

org.jboss.logging.annotations.MessageLogger

org.jboss.logging.Param

org.jboss.logging.annotations.Param

org.jboss.logging.Property

org.jboss.logging.annotations.Property

JavaServer Faces (JSF) のコード変更

JSF 1.2 のサポート停止

JBoss EAP 6 では、jboss-deployment-structure.xml ファイルを作成して、アプリケーションデプロイメントで JSF 1.2 の使用を継続することができました。

JBoss EAP 7 には JSF 2.2 が含まれ、JSF 1.2 API はサポート対象外になりました。アプリケーションが JSF 1.2 を使用する場合、JSF 2.2 を使用するようアプリケーションを書き直す必要があります。

JSF 2.1 および JSF 2.2 の互換性の問題

JSF 2.1 API と JSF 2.2 API は完全に互換性があるわけではありません。リリース間で、FACELET_CONTEXT_KEY 定数値が com.sun.faces.facelets.FACELET_CONTEXT から javax.faces.FACELET_CONTEXT に変更されました。この値はコンパイラーによってインライン化され、どちらかのリリースに対してコンパイルされたコードは他のリリースでは動作しません。

以下の例に似たコードが含まれ、JSF 2.1 API でコンパイルされたアプリケーションが JSF 2.2 API を使用する JBoss EAP 7 で実行されると、NullPointerException が発生します。この問題を修正するには、アプリケーションを JSF 2.2 API に対してコンパイルする必要があります。

Object obj = FacesContext.getCurrentInstance().getAttributes().get(FaceletContext.FACELET_CONTEXT_KEY);

詳細は、JAVASERVERFACES_SPEC_PUBLIC-1257 を参照してください。

モジュールクラスローティングの変更

JBoss EAP 7 では、複数のモジュールに同じクラスまたはパッケージが含まれる場合のクラスローディングの動作が変更になりました。

お互いに依存し、一部同じパッケージが含まれる MODULE_A と MODULE_B の 2 つのモジュールがあるとします。JBoss EAP 6 では、依存関係からロードされたクラスまたはパッケージは module.xml ファイルの resource-root に指定されたものよりも優先されました。これは、MODULE_A は MODULE_B のパッケージを認識し、MODULE_B は MODULE_A のパッケージを認識したことを意味しますが、この動作は複雑で競合が発生することがありました。この動作は JBoss EAP 7 では変更になり、module.xml ファイルの resource-root によって指定されたクラスまたはパッケージは依存関係によって指定されたものよりも優先されるようになりました。これは、MODULE_A は MODULE_A のパッケージを認識し、MODULE_B は MODULE_B のパッケージを認識することを意味します。これにより、競合の発生を防ぎ、より適切な動作を提供します。

resource-root ライブラリーが含まれるカスタムモジュールまたは複製されたクラスがモジュール依存関係に含まれるパッケージを定義した場合、JBoss EAP 7 へ移行するときに ClassCastException、LinkageError、クラスローディングエラー、またはその他の動作の変更が発生することがあります。この問題を解決するには、module.xml ファイルを設定して 1 つのバージョンのクラスのみが使用されるようにする必要があります。これは、以下の方法の 1 つを使用して実現できます。

モジュール依存関係のクラスを複製する resource-root を指定しないようにします。

imports および exports 要素の include および exclude サブ要素を使用して module.xml ファイルでクラスローディングを制御できます。以下は、指定されたパッケージでクラスを除外する export 要素になります。

<exports>
  <exclude path="com/mycompany/duplicateclassespath/"/>
</exports>

既存の動作を保持するには、filter 要素を使用して module.xml ファイルの依存する resource-root から依存パッケージをフィルターする必要があります。これにより、JBoss EAP 6 で見られる odd loop なしで既存の動作を保持できます。以下は、指定のパッケージのクラスをフィルターする root-resource の例になります。

<resource-root path="mycompany.jar">
  <filter>
    <exclude path="com/mycompany/duplicateclassespath"/>
  </filter>
</resource-root>

モジュールおよびクラスローディングの詳細は、JBoss EAP Development Guide の Class Loading and Modules を参照してください。

アプリケーションクラスタリングの変更

新しいクラスタリング機能の概要

以下のリストは、アプリケーションを JBoss EAP 6 から JBoss EAP 7 へ移行するときに注意する必要がある新しいクラスタリング機能の一部を示しています。

JBoss EAP 7 には、シングルトンサービスのビルドを大幅に簡易化する、新しいパブリック API が導入されました。詳細は JBoss EAP Developing EJB Applications の Implement an HA Singleton を参照してください。

一度にクラスターで単一のノードのみをデプロイおよび開始するよう、シングルトンデプロイメントを設定できます。詳細は、JBoss EAP Development Guide の HA Singleton Deployments を参照してください。

クラスター化されたシングルトン MDB を定義できるようになりました。詳細は、JBoss EAP Developing EJB Applications の Clustered Singleton MDBs を参照してください。

JBoss EAP 7 には、Undertow mod_cluster 実装が含まれています。これは、http web サーバーを必要としない純粋な Java ロードバランシングソリューションを提供します。詳細は、JBoss EAP Configuration Guide の Configuring JBoss EAP as a Front-end Load Balancer を参照してください。

本セクションの残りの部分では、クラスタリングの変更がアプリケーションの JBoss EAP 7 への移行に及ぼす影響について説明します。

Web セッションクラスタリングの変更

JBoss EAP 7 では、新しい Web セッションクラスタリング実装が導入されました。これは、レガシーの JBoss Web サブシステムソースコードに密に結合された以前の実装に代わる実装です。

新しい Web セッションクラスタリング実装は、JBoss プロプライエタリー Web アプリケーションの XML 記述子ファイルである jboss-web.xml にアプリケーションが設定される方法に影響します。以下は、このファイルのクラスタリング設定要素のみになります。

<jboss-web>
  ...
  <max-active-sessions>...</max-active-sessions>
  ...
  <replication-config>
    <replication-granularity>...</replication-granularity>
    <cache-name>...</cache-name>
  </replication-config>
  ...
</jboss-web>

以下の表は、jboss-web.xml ファイルの廃止された要素と同様の動作を実現する方法を説明しています。

設定要素
変更の説明

<max-active-sessions/>

これまでの実装では、アクティブなセッションの数が <max-active-sessions/> によって指定された値を超えるとセッションの作成に失敗しました。

新しい実装では、<max-active-sessions/> を使用してセッションパッシベーションが有効化されます。セッションの作成によって、アクティブなセッションの数が <max-active-sessions/> を超える場合、新しいセッションが作成されるよう、セッションマネージャーが認識する最も古いセッションがパッシベートされます。

<passivation-config/>

この設定要素とサブ要素は JBoss EAP 7 では使用されないようになりました。

<use-session-passivation/>

以前の実装では、この属性を使用してパッシベーションが有効化されました。

新しい実装では、<max-active-sessions/> に負でない値を指定するとパッシベーションが有効化されます。

<passivation-min-idle-time/>

以前の実装では、パッシベーションの候補となる前にセッションは最小時間アクティブである必要がありました。そのため、パッシベーションが有効であってもセッションの作成に失敗することがありました。

新しい実装はこの論理をサポートしないため、サービス拒否 (DoS) 攻撃の発生を防ぎます。

<passivation-max-idle-time/>

以前の実装では、セッションは指定期間アイドル状態であった後にパッシベートされました。

新しい実装はレイジー (Lazy) パッシベーションのみをサポートします。イーガー (Eager) パッシベーションはサポートしません。セッションは、<max-active-sessions/> に準拠する必要があるときのみパッシベートされます。

<replication-config/>

新しい実装では複数のサブ要素が非推奨になりました。

<replication-trigger/>

以前の実装では、この要素を使用してセッションレプリケーションがトリガーされるタイミングを決定しました。新しい実装では、この設定は単一の堅牢なストラテジーに変更されました。詳細は、JBoss EAP Development Guide の Immutable Session Attributes を参照してください。

<use-jk/>

以前の実装では、<use-jk/> に指定された値に応じて、指定のリクエストを処理するノードの instance-id が jsessionid の末尾に追加され、mod_jk、mod_proxy_balancer、mod_cluster などのロードバランサーによって使用されました。

新しい実装では、instance-id が定義されている場合は常に jsessionid の末尾に追加されるようになりました。

<max-unreplicated-interval/>

以前の実装では、この設定オプションは変更されたセッション属性がない場合にセッションのタイムスタンプがレプリケートされないようにする最適化を目的としていました。しかし、セッション属性が変更されたかどうかに関係なく、セッションのアクセスにはキャッシュトランザクション RPC が必要であるため、実際は RPC の実行を防ぐことはできません。

新しい実装では、リクエストごとにセッションのタイムスタンプがレプリケートされるようになりました。これにより、フェイルオーバーの後にセッションメタデータが陳腐化されないようにします。

<snapshot-mode/>

これまでの実装では、<snapshot-mode/> を INSTANT または INTERVAL として設定することができました。Infinispan のレプリケーションキューはこの設定オプションを廃止としてレンダーします。

<snapshot-interval/>

これは <snapshot-mode>INTERVAL</snapshot-mode> にのみ関係しました。<snapshot-mode/> は廃止されたため、このオプションも廃止されました。

<session-notification-policy/>

以前の実装では、この属性によって指定された値はセッションイベントをトリガーするポリシーを定義しました。

新しい実装ではこの動作は仕様に応じて判断されるようになり、設定不可能になりました。

ステートフルセッション EJB クラスタリングの変更

JBoss EAP 6 では、以下の方法の 1 つでステートフルセッション Bean (SFSB) のクラスタリング動作を有効化する必要がありました。

セッション Bean に org.jboss.ejb3.annotation.Clustered アノテーションを追加。

@Stateful
@Clustered
public class MyBean implements MySessionInt {

   public void myMethod() {
      //
   }
}

<clustered> 要素を jboss-ejb3.xml ファイルに追加。

<c:clustering>
  <ejb-name>DDBasedClusteredSFSB</ejb-name>
  <c:clustered>true</c:clustered>
</c:clustering>

JBoss EAP 7 では、クラスタリング動作を有効にする必要がなくなりました。デフォルトでは、HA プロファイルを使用してサーバーが起動された場合は SFSB の状態が自動的にレプリケートされます。

以下の方法の 1 つを使用すると、このデフォルト動作を無効にできます。

EJB 3.2 仕様に新たに導入された @Stateful(passivationCapable=false) を使用して単一のステートフルセッション Bean のデフォルト動作を無効化します。

サーバー設定の ejb3 サブシステムの設定で、この動作をグローバルに無効化します。

注記

@Clustered アノテーションがアプリケーションから削除されると、このアノテーションは無視され、アプリケーションのデプロイメントには影響しません。

クラスタリングサービスの変更

JBoss EAP 6 では、クラスタリングサービスの API はプライベートモジュールでサポートされませんでした。

JBoss EAP 7 には、アプリケーションによって使用されるパブリッククラスタリングサービス API が導入されました。新しいサービスは、ライトウェイトで簡単にインジェクトできるよう設計されています。外部の依存関係は必要ありません。

新しい org.wildfly.clustering.group.Group インターフェースを使用すると、現在のクラスター状態へアクセスでき、クラスターメンバーシップの変更をリッスンできます。

新しい org.wildfly.clustering.dispatcher.CommandDispatcher インターフェースを使用すると、すべてのノードまたはノードの選択されたサブセットのクラスターでコードを実行できます。

これらのサービスは、JBoss EAP 5 の HAPartition、JBoss EAP 6 の GroupCommunicationService、GroupMembershipNotifier、および GroupRpcDispatcher に代わるサービスです。これらの API は以前のリリースで利用できました。

詳細は、JBoss EAP Development Guide の Public API for Clustering Services を参照してください。

クラスタリング HA シングルトンの移行

JBoss EAP 6 では、クラスター全体の HA シングルトンサービスに使用できるパブリック API がありませんでした。プライベートの org.jboss.as.clustering.singleton.* クラスを使用した場合、アプリケーションを JBoss EAP 7 に移行するときに新しいパブリックの org.wildfly.clustering.singleton.* パッケージを使用するようコードを変更する必要があります。

HA シングルトンの実装方法に関する詳細は、JBoss EAP Developing EJB Applications の Implement an HA Singleton を参照してください。

第6章 その他の変更

JBoss EAP ネイティブおよび Apache HTTP Server の提供に関する変更

JBoss EAP 7 ネイティブは、これまでのリリースとは異なる方法で提供されます。一部のネイティブは、多くの Red Hat JBoss ミドルウェア製品に共通する補完ソフトウェアセットである、新規の Red Hat JBoss Core Services 製品に同梱されるようになりました。新製品では更新のより迅速な配布と一貫性のある更新が可能になります。JBoss Core Services 製品は、Red Hat カスタマーポータルの別の場所からダウンロードできます。

以下の表では、リリースごとの提供方法の違いを示しています。

パッケージ
JBoss EAP 6
JBoss EAP 7

メッセージング用 AIO ネイティブ

別個の "ネイティブユーティリティー" ダウンロードで製品とともに提供。

JBoss EAP ディストリビューションに含まれます。他のダウンロードは必要ありません。

Apache HTTP Server

別個の "Apache HTTP Server" ダウンロードで製品とともに提供。

新しい JBoss Core Services 製品とともに提供されます。

mod_cluster、mod_jk, isapi、および nsapi コネクター

別個の "Webserver コネクターネイティブ" ダウンロードで製品とともに提供。

新しい JBoss Core Services 製品とともに提供されます。

JSVC

別個の "ネイティブユーティリティー" ダウンロードで製品とともに提供。

新しい JBoss Core Services 製品とともに提供されます。

OpenSSL

別個の "ネイティブユーティリティー" ダウンロードで製品とともに提供。

これは JBoss EAP 7 では廃止されました

tcnatives

別個の "ネイティブコンポーネント" ダウンロードで製品とともに提供。

これは JBoss EAP 7 では廃止されました

以下の変更点にも注意してください。

Red Hat Enterprise Linux RPM チャンネルからの Apache HTTP Server と使用される mod_cluster および mod_jk コネクターのサポートは廃止されました。Red Hat Enterprise Linux RPM チャネルから Apache HTTP Server を実行し、JBoss EAP 7 サーバーの負荷分散を設定する必要がある場合は、以下の 1 つを行います。

JBoss Core Services によって提供される Apache HTTP Server を使用します。

フロントエンドロードバランサーとして動作するよう JBoss EAP 7 を設定できます。詳細は JBoss EAP Configuration Guide の Configuring JBoss EAP as a Front-end Load Balancer を参照してください。

認証済みのサポートされるマシンに Apache HTTP Server をデプロイした後、そのマシンでロードバランサーを実行することができます。サポートされる構成の一覧は、JBoss EAP Configuration Guide の Overview of HTTP Connectors を参照してください。

HP-UX Web Server Suites からの Apache HTTP Server と使用される mod_cluster および mod_jk コネクターのサポートは廃止されました。HP-UX Web Server Suites から Apache HTTP Server を実行し、JBoss EAP 7 サーバーの負荷分散を設定する必要がある場合は、以下の 1 つを行います。

フロントエンドロードバランサーとして動作するよう JBoss EAP 7 を設定できます。詳細は JBoss EAP Configuration Guide の Configuring JBoss EAP as a Front-end Load Balancer を参照してください。

認証済みのサポートされるマシンに Apache HTTP Server をデプロイした後、そのマシンでロードバランサーを実行することができます。サポートされる構成の一覧は、JBoss EAP Configuration Guide の Overview of HTTP Connectors を参照してください。

詳細は、Apache HTTP Server Installation Guide の JBoss Core Services を参照してください。

Amazon EC2 でのデプロイメントの変更

JBoss EAP 7 では、Amazon Machine Images (AMI) に複数の変更が加えられました。ここでは、これらの変更の一部を簡単に説明します。

非クラスターおよびクラスターの JBoss EAP インスタンスおよびドメインを Amazon EC2 で起動する方法が大幅に変更されました。

JBoss EAP 6 では JBoss EAP の設定に User Data: フィールドが使用されました。JBoss EAP 7 では、User Data: フィールドの設定を分析した AMI スクリプトと、インスタンスの起動時に自動的にサーバーを起動した AMI スクリプトが削除されました。

JBoss EAP のこれまでのリリースでは、Red Hat JBoss Operations Network エージェントがインストールされましたが、JBoss EAP 7 では個別にインストールする必要があります。

Amazon EC2 での JBoss EAP 7 のデプロイに関する詳細は、Deploying Red Hat JBoss Enterprise Application Platform on Amazon EC2 を参照してください。

付録A リファレンス資料

JacORB サブシステム移行操作の警告

migrate 操作はすべてのリソースや属性を処理することはできません。jacorb サブシステムの migrate または describe-migration 操作を実行すると表示される可能性がある警告の一部を以下に示します。

注記

migrate 操作の出力に「Could not migrate」または「Can not migrate」エントリーが記録された場合、サーバー設定の移行は正常に完了したにも関わらず、すべての要素および属性を自動的に移行できなかったことを表します。「migration-warnings」の提案に従ってこれらの設定を変更する必要があります。

警告メッセージ
メッセージの意味 / 修正方法

The iiop migration can be performed when the server is in admin-only mode (iiop の移行はサーバーが admin-only モードであるときに実行できます)

migrate 操作を実行するには、--admin-only パラメーターをサーバー起動コマンドに追加し、サーバーを admin-only モードで起動する必要があります。

$ EAP_HOME/bin/standalone.sh --admin-only

Properties X cannot be emulated using OpenJDK ORB and are not supported (プロパティー X は OpenJDK ORB を使用してエミュレートできず、サポートされていません)

指定プロパティーの設定はサポートされず、新しい iiop-openjdk サブシステム設定には含まれていません。以前のリリースの JBoss EAP でこのプロパティーによって示された動作は移行されないため、管理者は JBoss EAP 7 の新しい iiop-openjdk サブシステムがこの動作を示さずに正しく操作できることを検証する必要があります。

サポートされないプロパティーには以下が含まれます: cache-poa-names、 cache-typecodes、 chunk-custom-rmi-valuetypes、 client-timeout、 comet、 indirection-encoding-disable、 iona、 lax-boolean-encoding、 max-managed-buf-size、 max-server-connections、 max-threads、 outbuf-cache-timeout、 outbuf-size、 queue-max、 queue-min、 poa-monitoring、 print-version、 retries、 retry-interval、 queue-wait、 server-timeout、 strict-check-on-tc-creation、 use-bom、 use-imr。

The properties X use expressions. Configuration properties that are used to resolve those expressions should be transformed manually to the new iiop-openjdk subsystem format (プロパティー X は式を使用します。これらの式を解決するために使用される設定プロパティーは新しい iiop-openjdk サブシステム形式に手動で変換する必要があります)

式を使用するプロパティーは管理者が手作業で設定する必要があります。

たとえば、JBoss EAP 6 の jacorb サブシステムは giop-minor-version を定義しました。JBoss EAP 7 の iiop-openjdk サブシステムは giop-version プロパティーを定義します。jacorb サブシステムのマイナーバージョン属性が ${iiop-giop-minor-version} に設定され、システムプロパティーが -Diiop-giop-minor-version=1 ととして standalone.conf ファイルに設定されている場合、管理者は migrate 操作の後にシステムプロパティーの値を 1.1 に変更し、新しいサブシステムが適切に設定されるようにする必要があります。

Can not migrate: the new iiop-openjdk subsystem is already defined (移行できません: 新しい iiop-openjdk サブシステムはすでに定義されています)

メッセージには説明が含まれています。

Messaging サブシステム移行操作の警告

migrate 操作はすべてのリソースや属性を処理することはできません。messaging サブシステムの migrate または describe-migration 操作を実行すると表示される可能性がある警告の一部を以下に示します。

注記

migrate 操作の出力に「Could not migrate」または「Can not migrate」エントリーが記録された場合、サーバー設定の移行は正常に完了したにも関わらず、すべての要素および属性を自動的に移行できなかったことを表します。「migration-warnings」の提案に従ってこれらの設定を変更する必要があります。

警告メッセージ
メッセージの意味 / 修正方法

The migrate operation can not be performed: the server must be in admin-only mode (migrate 操作は実行できません。サーバーは admin-only モードである必要があります)

migrate 操作を実行するには、--admin-only パラメーターをサーバー起動コマンドに追加し、サーバーを admin-only モードで起動する必要があります。

$ EAP_HOME/bin/standalone.sh --admin-only

Can not migrate attribute local-bind-address from resource X. Use instead the socket-binding attribute to configure this broadcast-group. (リソース X から属性 local-bind-address を移行できません。代わりに socket-binding 属性を使用してこの broadcast-group を設定してください。)

メッセージには説明が含まれています。

Can not migrate attribute local-bind-port from resource X. Use instead the socket-binding attribute to configure this broadcast-group. (リソース X から属性 local-bind-port を移行できません。代わりに socket-binding 属性を使用してこの broadcast-group を設定してください。)

メッセージには説明が含まれています。

Can not migrate attribute group-address from resource X. Use instead the socket-binding attribute to configure this broadcast-group. (リソース X から属性 group-address を移行できません。代わりに socket-binding 属性を使用してこの broadcast-group を設定してください。)

メッセージには説明が含まれています。

Can not migrate attribute group-port from resource X. Use instead the socket-binding attribute to configure this broadcast-group. (リソース X から属性 group-port を移行できません。代わりに socket-binding 属性を使用してこの broadcast-group を設定してください。)

broadcast-group リソースは local-bind-address、local-bind-port、group-address、または group-port 属性を許可しないようになりました。このリソースは socket-binding 属性のみを許可します。この警告は、リソース X にサポートされない属性があることを通知します。 リソースの socket-binding 属性を手作業で設定し、定義された socket-binding リソースに対応するようにする必要があります。

Classes providing the X are discarded during the migration. To use them in the new messaging-activemq subsystem, you will have to extend the Artemis-based Interceptor. （移行中に X を提供するクラスは破棄されます。新しい messaging-activemq サブシステムでこれらを使用するには、Artemis ベースのインターセプターを拡張する必要があります。)

JBoss EAP 7 のメッセージングインターセプターのサポートは大幅に異なります。以前のバージョンのサブシステムに設定されたインターセプターはすべて移行中に破棄されます。詳細は メッセージングインターセプターの移行を参照してください。

Can not migrate the HA configuration of X. Its shared-store and backup attributes holds expressions and it is not possible to determine unambiguously how to create the corresponding ha-policy for the messaging-activemq’s server. (X の HA 設定は移行できません。 この shared-store および backup 属性は式を保持し、messaging-activemq のサーバーの対応する ha-policy を作成する方法を明確に決定することができません。)

これは、hornetq-server X の shared-store または backup 属性に ${xxx} などの式が含まれ、移行操作が具体的な式に解決できなかったことを意味します。値は破棄され、messaging-activemq の ha-policy を手作業で更新する必要があります。

Can not migrate attribute local-bind-address from resource X. Use instead the socket-binding attribute to configure this discovery-group. (リソース X から属性 local-bind-address を移行できません。代わりに socket-binding 属性を使用してこの discovery-group を設定してください。)

メッセージには説明が含まれています。

Can not migrate attribute local-bind-port from resource X. Use instead the socket-binding attribute to configure this discovery-group. (リソース X から属性 local-bind-port を移行できません。代わりに socket-binding 属性を使用してこのdiscovery-group を設定してください。)

メッセージには説明が含まれています。

Can not migrate attribute group-address from resource X. Use instead the socket-binding attribute to configure this discovery-group. (リソース X から属性 group-address を移行できません。代わりに socket-binding 属性を使用してこの discovery-group を設定してください。)

メッセージには説明が含まれています。

Can not migrate attribute group-port from resource X. Use instead the socket-binding attribute to configure this discovery-group. (リソース X から属性 group-port を移行できません。代わりに socket-binding 属性を使用してこの discovery-group を設定してください。)

discovery-group リソースは local-bind-address、local-bind-port、group-address、または group-port 属性を許可しないようになりました。socket-binding のみを許可します。この警告は、リソース X にサポートされない属性があることを通知します。リソースの socket-binding 属性を手作業で設定し、定義された socket-binding リソースに対応するようにする必要があります。

Can not create a legacy-connection-factory based on connection-factory X. It uses a HornetQ in-vm connector that is not compatible with Artemis in-vm connector (connection-factory X を基にしてlegacy-connection-factory を作成できません。これは Artemis in-vm コネクターと互換性のない HornetQ in-vm コネクターを使用します。)

JBoss EAP 6 クライアントが JBoss EAP 7 に接続できるようにするため、レガシーの HornetQ リモート connection-factory リソースは legacy-connection-factory リソースに移行されました。しかし、legacy-connection-factory リソースは connection-factory がリモートコネクターを使用しているときのみ作成されます。in-vm クライアントは JBoss EAP 6 ではなく JBoss EAP 7 をベースにしているため、in-vm を使用する connection-factory は移行されません。この警告は、in-vm connection-factory が移行されなかったことを通知します。

Can not migrate attribute X from resource Y. The attribute uses an expression that can be resolved differently depending on system properties. After migration, this attribute must be added back with an actual value instead of the expression. (リソース Y から属性 X を移行できません。属性はシステムプロパティーに応じて異なって解決される式を使用します。移行後、式の代わりに実際の値を用いてこの属性を戻す必要があります。)

この警告は、移行処理中に属性 X を具体的な値に解決できないときに表示されます。値は破棄され、属性を手作業で移行する必要があります。これは以下の場合に発生します。

cluster-connection forward-when-no-consumers:

このブール値属性は、列挙で OFF、STRICT、または ON_DEMAND を値として持つ message-load-balancing-type 属性に置き換えられました。

broadcast-group および discovery-group の jgroups-stack および jgroups-channel 属性

これらの属性は他のリソースを参照し、JBoss EAP 7 ではこれらの式が許可されないようになりました。

Can not migrate attribute X from resource Y. This attribute is not supported by the new messaging-activemq subsystem. (リソース Y から属性 X を移行できません。この属性は新しい messaging-activemq サブシステムによってサポートされません。)

一部の属性は新しい messaging-activemq サブシステムではサポート対象外となり、破棄されます。

hornetq-server の failback-delay

http-connector の use-nio 属性

http-acceptor の use-nio 属性

remote-connector の use-nio 属性

remote-acceptor の use-nio 属性

Can not migrate attribute failback-delay from resource X. Artemis detects failback deterministically and it no longer requires to specify a delay for failback to occur. (リソース X から 属性 failback-delay を移行できません。フェイルバックは Artemis によって確定的に検出され、フェイルバックの遅延を指定する必要がなくなりました。)

メッセージには説明が含まれています。

非推奨の broadcast-group または discovery-group 属性の置き換え

非推奨の broadcast-group または discovery-group 属性を socket-binding 属性に置き換えるよう通知された場合、管理 CLI を使用して socket-binding 属性を追加できます。

以下の例では、messaging サブシステムに以下の discovery-group 設定が含まれるスタンドアロンサーバーを移行することを前提とします。

<discovery-groups>
    <discovery-group name="my-discovery-group">
        <group-address>224.0.1.105</group-address>
        <group-port>56789</group-port>
    </discovery-group>
</discovery-groups>

messaging サブシステムに対して migrate 操作を実行すると、以下の出力および警告が表示されます。

[standalone@localhost:9999 /] /subsystem=messaging:migrate
{
    "outcome" => "success",
    "result" => {"migration-warnings" => [
        "WFLYMSG0084: Can not migrate attribute group-address from resource [
    (\"subsystem\" => \"messaging-activemq\"),
    (\"server\" => \"default\"),
    (\"discovery-group\" => \"my-discovery-group\")
]. Use instead the socket-binding attribute to configure this discovery-group.",
        "WFLYMSG0084: Can not migrate attribute group-port from resource [
    (\"subsystem\" => \"messaging-activemq\"),
    (\"server\" => \"default\"),
    (\"discovery-group\" => \"my-discovery-group\")
]. Use instead the socket-binding attribute to configure this discovery-group."
    ]}
}

migrate 操作によって、"my-discovery-group" という名前の discovery-group が新しい messaging-activemq サブシステムに作成され、以下のように設定されます。

<discovery-group name="my-discovery-group"/>

ここで、以下の管理 CLI コマンドを使用して、"my-discovery-group-socket-binding" という名前のサーバー設定ファイルに socket-binding 要素を作成する必要があります。

/socket-binding-group=standard-sockets/socket-binding=my-discovery-group-socket-binding:add(multicast-address=224.0.1.105, multicast-port=56789)

次に、以下の管理 CLI コマンドを使用して、新たに作成された socket-binding をサーバー設定ファイルにある messaging-activemq サブシステムの "my-discovery-group" という名前の discovery-group に追加します。

/subsystem=messaging-activemq/server=default/discovery-group=my-discovery-group:write-attribute(name=socket-binding,value=my-discovery-group-socket-binding)

これらのコマンドによって、サーバー設定ファイルに以下の XML が作成されます。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
    <server name="default">
        ...
        <discovery-group name="my-discovery-group" socket-binding="my-discovery-group-socket-binding"/>
        ...
    </server>
</subsystem>
...
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    ...
    <socket-binding name="my-discovery-group-socket-binding" multicast-address="224.0.1.105" multicast-port="56789"/>
    ...
</socket-binding-group>

Web サブシステム移行操作の警告

migrate 操作はすべてのリソースや属性を処理することはできません。web サブシステムの migrate または describe-migration 操作を実行すると表示される可能性がある警告の一部を以下に示します。

注記

migrate 操作の出力に「Could not migrate」または「Can not migrate」エントリーが記録された場合、サーバー設定の移行は正常に完了したにも関わらず、すべての要素および属性を自動的に移行できなかったことを表します。「migration-warnings」の提案に従ってこれらの設定を変更する必要があります。

警告メッセージ
メッセージの意味 / 修正方法

Migrate operation only allowed in admin only mode (移行操作は管理専用モードのみで許可されます)

migrate 操作を実行するには、--admin-only パラメーターをサーバー起動コマンドに追加し、サーバーを admin-only モードで起動する必要があります。

$ EAP_HOME/bin/standalone.sh --admin-only

Could not migrate resource X (リソース X を移行できませんでした)

以前のリリースの JBoss EAP でこのリソースによって示された動作は移行されませんでした。管理者は JBoss EAP 7 の新しい undertow サブシステムがこの動作を示さずに正しく操作できるかどうか、またはこの動作を手作業で移行する必要があるかどうかを検証する必要があります。

Could not migrate attribute X from resource Y. (リソース Y から属性 X を移行できません。)

以前のリリースの JBoss EAP でこのリソース属性によって示された動作は移行されませんでした。管理者は JBoss EAP 7 の新しい undertow サブシステムがこの動作を示さずに正しく操作できるかどうか、またはこの動作を手作業で移行する必要があるかどうかを検証する必要があります。

Could not migrate SSL connector as no SSL config is defined (定義された SSL 設定がないため SSL コネクターを移行できませんでした)

メッセージには説明が含まれています。

Could not migrate verify-client attribute X to the Undertow equivalent (verify-client 属性 X を Undertow の同等の属性に移行できませんでした)

メッセージには説明が含まれています。

Could not migrate verify-client expression X (verify-client 式 X を移行できませんでした)

メッセージには説明が含まれています。

Could not migrate valve X (バルブ X を移行できませんでした)

以前のリリースの JBoss EAP でこのバルブによって示された動作は移行されませんでした。管理者は JBoss EAP 7 の新しい undertow サブシステムがこの動作を示さずに正しく操作できるかどうか、またはこの動作を手作業で移行する必要があるかどうかを検証する必要があります。

この警告は以下のバルブに対して発生する可能性があります。

org.apache.catalina.valves.RemoteAddrValve

許可または拒否される値が 1 つ以上必要です。

org.apache.catalina.valves.RemoteHostValve

許可または拒否される値が 1 つ以上必要です。

org.apache.catalina.authenticator.BasicAuthenticator

org.apache.catalina.authenticator.DigestAuthenticator

org.apache.catalina.authenticator.FormAuthenticator

org.apache.catalina.authenticator.SSLAuthenticator

org.apache.catalina.authenticator.SpnegoAuthenticator

カスタムバルブ

Could not migrate attribute X from valve Y (バルブ Y から属性 X を移行できませんでした)

以前のリリースの JBoss EAP でこのバルブ属性によって示された動作は移行されませんでした。管理者は JBoss EAP 7 の新しい undertow サブシステムがこの動作を示さずに正しく操作できるかどうか、またはこの動作を手作業で移行する必要があるかどうかを検証する必要があります。この警告は、以下のバルブ属性に対して発生する可能性があります。

org.apache.catalina.valves.AccessLogValve

resolveHosts

fileDateFormat

renameOnRotate

encoding

locale

requestAttributesEnabled

buffered

org.apache.catalina.valves.ExtendedAccessLogValve

resolveHosts

fileDateFormat

renameOnRotate

encoding

locale

requestAttributesEnabled

buffered

org.apache.catalina.valves.RemoteIpValve

httpServerPort

httpsServerPort

remoteIpHeader

定義されていても "x-forwarded-for" に設定されていない場合

protocolHeader

定義されていても "x-forwarded-proto" に設定されていない場合

リリース間の互換性および相互運用性

ここでは、JBoss EAP 5、JBoss EAP 6、および JBoss EAP 7 リリース間での、クライアントおよびサーバー EJB とメッセージングコンポーネントの互換性および相互運用性について説明します。

IIOP 上の EJB リモーティング

以下の設定では問題が発生しません。

JBoss EAP 5 クライアントから JBoss EAP 7 サーバーへの接続

JBoss EAP 6 クライアントから JBoss EAP 7 サーバーへの接続

JBoss EAP 7 クライアントから JBoss EAP 6 サーバーへの接続

JBoss EAP 7 クライアントから JBoss EAP 5 サーバーへの接続

JNDI を使用した EJB リモーティング

以下の設定では問題が発生しません。

JBoss EAP 6 クライアントから JBoss EAP 7 サーバーへの接続

JBoss EAP 7 クライアントから JBoss EAP 6 サーバーへの接続

JBoss EAP 6 では、EJB 3.1 仕様のサポートが提供され、標準化されたグローバル JNDI ネームスペースが導入されました。JBoss EAP 7 でも標準化されたグローバル JNDI ネームスペースは使用されますが、JNDI ネームスペースの名前が変更になったため、以下の設定は互換性がありません。

JBoss EAP 5 クライアントから JBoss EAP 7 または JBoss EAP 6 サーバーへの接続

JBoss EAP 7 または JBoss EAP 6 クライアントから JBoss EAP 5 サーバーへの接続

標準化された JNDI ネームスペースの変更に関する詳細は、JBoss EAP 6 移行ガイドの JNDI の変更を参照してください。

@WebService を使用した EJB リモーティング

以下の設定では問題が発生しません。

JBoss EAP 5 クライアントから JBoss EAP 7 サーバーへの接続

JBoss EAP 6 クライアントから JBoss EAP 7 サーバーへの接続

JBoss EAP 7 クライアントから JBoss EAP 6 サーバーへの接続

JBoss EAP 7 クライアントから JBoss EAP 5 サーバーへの接続

メッセージングスタンドアロンクライアント

以下の設定では問題が発生しません。

JBoss EAP 6 クライアントから JBoss EAP 7 サーバーへの接続

JBoss EAP 7 クライアントから JBoss EAP 6 サーバーへの接続

以下の設定では、クライアントが汎用 JMS API ではなくメッセージングブローカー専用の HornetQ API を使用すれば接続が可能です。しかし、JBoss EAP 7 に同梱される JBoss EAP レガシー JNDI ネーミング拡張を使用して JNDI ルックアップに対応する必要があります。

JBoss EAP 5 クライアントから JBoss EAP 7 サーバーへの接続

プロトコル互換性の問題があるため、JBoss EAP 7 のビルトインメッセージングは JBoss EAP 5 に同梱された HornetQ 2.2.x へは接続できません。そのため、以下の設定は互換性がありません。

JBoss EAP 7 クライアントから JBoss EAP 5 サーバーへの接続

メッセージング MDB

以下の設定では問題が発生しません。

JBoss EAP 6 クライアントから JBoss EAP 7 サーバーへの接続

JBoss EAP 7 クライアントから JBoss EAP 6 サーバーへの接続

以下の設定では、クライアントが汎用 JMS API ではなくメッセージングブローカー専用の HornetQ API を使用すれば接続が可能です。しかし、JBoss EAP 7 に同梱される JBoss EAP レガシー JNDI ネーミング拡張を使用して JNDI ルックアップに対応する必要があります。

JBoss EAP 5 クライアントから JBoss EAP 7 サーバーへの接続

プロトコル互換性の問題があるため、JBoss EAP 7 のビルトインメッセージングは JBoss EAP 5 に同梱された HornetQ 2.2.x へは接続できません。そのため、以下の設定は互換性がありません。

JBoss EAP 7 クライアントから JBoss EAP 5 サーバーへの接続

JMS ブリッジ

以下の設定では問題が発生しません。

JBoss EAP 5 クライアントから JBoss EAP 7 サーバーへの接続

JBoss EAP 6 クライアントから JBoss EAP 7 サーバーへの接続

JBoss EAP 7 クライアントから JBoss EAP 6 サーバーへの接続

JBoss EAP 7 クライアントから JBoss EAP 5 サーバーへの接続