第3章 アプリケーションの移行
3.1. ほとんどのアプリケーションで必要な変更 リンクのコピーリンクがクリップボードにコピーされました!
3.1.1. ほとんどのアプリケーションで必要な変更の確認 リンクのコピーリンクがクリップボードにコピーされました!
3.1.2. クラスローディングの変更 リンクのコピーリンクがクリップボードにコピーされました!
3.1.2.1. クラスローディングの変更によるアプリケーションの更新 リンクのコピーリンクがクリップボードにコピーされました!
- 最初に、アプリケーションのパッケージと依存関係を確認します。詳細については、 「クラスローディングの変更によるアプリケーション依存関係の更新」を参照してください。
- アプリケーションがロギングを行う場合、正しいモジュールの依存関係を指定する必要があります。詳細については、 「ロギング依存関係の編集」を参照してください。
- モジュラークラスローディングの変更により、EAR または WAR のパッケージ構造を変更する必要がある場合があります。詳細については、 「EAR および WAR パッケージの編集」を参照してください。
3.1.2.2. モジュールの依存関係の理解 リンクのコピーリンクがクリップボードにコピーされました!
モジュールは独自のクラスと、明示的または暗黙的な依存関係を持つモジュールのクラスのみにアクセスすることが可能です。
手順3.1 モジュールの依存関係の理解
暗黙的な依存関係を理解する
サーバー内のデプロイヤーは、javax.apiやsun.jdkなどの一般的に使用されるモジュール依存関係を暗黙的かつ自動的に追加します。これにより、ランタイム時にデプロイメントに対してクラスを可視化でき、開発者が依存関係を明示的に追加する作業が軽減されます。暗黙的な依存関係がいつどのように追加されるかについては、https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ にある JBoss EAP 6 向け『開発ガイド『』』の章「クラスローディングとモジュール『』」に記載されている『暗黙的なモジュール依存関係』の説明を参照してください。明示的な依存関係の理解
その他のクラスに対してはモジュールを明示的に指定する必要があります。明示的に指定しないと、不明な依存関係が原因でデプロイメントエラーやランタイムエラーが発生します。依存関係が不明な場合は、サーバーログにClassNotFoundExceptionsトレースまたはNoClassDefFoundErrorsトレースが記録されます。複数のモジュールが同じ JAR をロードしたり、異なるモジュールによってロードされるクラスを拡張するクラスを 1 つのモジュールがロードしたりする場合は、サーバーログにClassCastExceptionsトレースが記録されます。依存関係を明示的に指定するには、MANIFEST.MFを変更するか、JBoss 固有のデプロイメント記述子ファイルjboss-deployment-structure.xmlを作成します。モジュール依存関係の詳細については、https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ にある JBoss EAP 6 向け『開発ガイド『』』の章「クラスローディングとモジュール『』」に記載されている『クラスローディングとモジュールの概要』を参照してください。
3.1.2.3. クラスローディングの変更によるアプリケーション依存関係の更新 リンクのコピーリンクがクリップボードにコピーされました!
JBoss EAP 6 のクラスローディングは、以前のバージョンの JBoss EAP とは大きく異なっています。JBoss EAP 6 のクラスローディングは、JBoss モジュールプロジェクトが基盤となっています。各ライブラリーは、すべての JAR をフラットなクラスパスにロードする単一の階層的なクラスローダーではなく、依存するモジュールに対してのみリンクするモジュールとなります。また、JBoss EAP 6 のデプロイメントもモジュールであり、クラスの依存関係が明示的に定義されていないと、アプリケーションサーバーの JAR に定義されているクラスへアクセスできません。アプリケーションサーバーによって定義されるモジュール依存関係の一部は自動的に設定されます。たとえば、Java EE アプリケーションをデプロイする場合、Java EE API の依存関係は自動的または暗黙的に追加されます。サーバーにより自動的に追加される依存関係の完全な一覧については、https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ にある JBoss EAP 6 用『開発ガイド』の章「『クラストーディングとモジュール』」に記載されている『暗黙的なモジュール依存関係』の説明を参照してください。
モジュラークラスローディングの変更に伴い、アプリケーションを JBoss EAP 6 に移行する際に以下のタスクを 1 つ以上実行する必要がある場合があります。
3.1.3. 設定ファイルの変更 リンクのコピーリンクがクリップボードにコピーされました!
3.1.3.1. JBoss EAP 6 のクラスローディングを制御するファイルの作成または変更 リンクのコピーリンクがクリップボードにコピーされました!
モジュラークラスローディングを使用する JBoss EAP 6 の変更に伴い、依存関係を追加したり、自動的に依存関係がロードされないようにしたりするために、1 つ以上のファイルを作成または変更する必要がある場合があります。クラスローディングとクラスローディングの優先度については、https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ にある JBoss EAP 6 向け『開発ガイド『』』の章「クラスローディングとモジュール『』」を参照してください。
- jboss-web.xml
jboss-web.xmlファイルに<class-loading>要素が定義されている場合はこれを削除する必要があります。JBoss EAP 5 でこの要素によって引き起こされた動作は、JBoss EAP 6 ではクラスローディングのデフォルト動作となったため、この要素を定義する必要がなくなりました。この要素を削除しないと、サーバーログに ParseError と XMLStreamException が記録されます。これは、コメントアウトされたjboss-web.xmlファイルの<class-loading>要素の例になります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - MANIFEST.MF
- 手作業による編集
- アプリケーションが使用するコンポーネントやモジュールによって異なりますが、このファイルに 1 つ以上の依存関係を追加する必要がある場合があります。依存関係は
DependenciesエントリーまたはClass-Pathエントリーとして追加できます。開発者によって編集されたMANIFEST.MFの例は次のとおりです。Manifest-Version: 1.0 Dependencies: org.jboss.logmanager Class-Path: OrderManagerEJB.jar
Manifest-Version: 1.0 Dependencies: org.jboss.logmanager Class-Path: OrderManagerEJB.jarCopy to Clipboard Copied! Toggle word wrap Toggle overflow このファイルを編集する場合、必ずファイルの最後にニューライン文字が含まれるようにしてください。 - Maven を使用した生成
- Maven を使用する場合、
pom.xmlファイルを編集してMANIFEST.MFファイルの依存関係を生成する必要があります。アプリケーションによって EJB 3.0 が使用される場合、pom.xmlファイルに次のようなセクションが含まれることがあります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow EJB 3.0 コードがorg.apache.commons.logを使用する場合、MANIFEST.MFファイルにこの依存関係が存在しなければなりません。この依存関係を生成するには、次のように<plugin>要素をpom.xmlファイルに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の例では、次の依存関係エントリのみがsrc/main/resources/META-INF/MANIFEST.MFファイルに含まれる必要があります。Dependencies: org.apache.commons.logging
Dependencies: org.apache.commons.loggingCopy to Clipboard Copied! Toggle word wrap Toggle overflow Maven は完全なMANIFEST.MFファイルを生成します。Manifest-Version: 1.0 Dependencies: org.apache.commons.logging
Manifest-Version: 1.0 Dependencies: org.apache.commons.loggingCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- jboss-deployment-structure.xml
- このファイルは、クラスローディングを細かく制御するために使用される JBoss 固有のデプロイメント記述子です。
MANIFEST.MFと同様に、このファイルを使用して依存関係を追加することが可能です。また、自動的な依存関係が追加されないようにしたり、追加のモジュールを定義することが可能で、EAR デプロイメントの分離されたクラスローディング動作を変更したり、追加のリソースルートをモジュールへ追加したりすることもできます。JSF 1.2 モジュールの依存関係を追加し、JSF 2.0 モジュールが自動的にローディングされないようにするjboss-deployment-structure.xmlファイルの例は次のとおりです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow このファイルに関する詳細については、 「jboss-deployment-structure.xml」を参照してください。 - application.xml
- 以前のバージョンの JBoss EAP では、
jboss-app.xmlファイルを使用して EAR 内でデプロイメントの順番を制御しました。本バージョンより、Java EE6 仕様によってapplication.xmlに<initialize-in-order>要素が提供されるようになり、EAR 内の Java EE モジュールがデプロイされる順番は、この要素によって制御されるようになりました。ほとんどの場合、デプロイメントの順番を指定する必要はありません。依存関係インジェクションと、外部モジュールのコンポーネントを参照する resource-refs がアプリケーションによって使用される場合、アプリケーションサーバーは適切で最適なコンポーネントの順番を暗黙的に決定できるため、ほとんどの場合で<initialize-in-order>要素は必要ありません。myApp.ear内にmyBeans.jarとmyApp.warを持つアプリケーションがあり、myApp.war@EJBのサーブレットがmyBeans.jarより Bean をインジェクトする場合、アプリケーションサーバーは必ずサーブレットの起動前に EJB コンポーネントを使用可能にします。<initialize-in-order>要素を使用する必要はありません。しかし、次のようなレガシーの JNDI ルックアップスタイルのリモート参照を使用し、Bean へアクセスする場合はモジュールの順番を指定する必要がある場合があります。この場合、EJB コンポーネントがinit() { Context ctx = new InitialContext(); ctx.lookup("TheBeanInMyBeansModule"); }init() { Context ctx = new InitialContext(); ctx.lookup("TheBeanInMyBeansModule"); }Copy to Clipboard Copied! Toggle word wrap Toggle overflow myBeans.jarにあることをサーバーが判断できないため、myBeans.jarのコンポーネントがmyApp.warのコンポーネントの前に初期化され開始されるよう強制する必要があります。これには、<initialize-in-order>要素をtrueに設定し、myBeans.jarモジュールとmyApp.warモジュールの順番をapplication.xmlファイルに指定します。以下は<initialize-in-order>要素を使用してデプロイメントの順番を制御する例になります。myBeans.jarはmyApp.warファイルの前にデプロイされます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow application.xmlファイルのスキーマは http://java.sun.com/xml/ns/javaee/application_6.xsd を参照してください。注記
<initialize-in-order>要素をtrueに設定するとデプロイメントの速度が遅くなることに注意してください。デプロイメントを最適化するときにコンテナの柔軟性が向上するため、依存関係インジェクションや resource-refs を使用して適切な依存関係を定義する方法が推奨されます。 - jboss-ejb3.xml
- Java Enterprise Edition (EE) が定義する
ejb-jar.xmlデプロイメント記述子によって提供される機能を上書きしたり追加したりするために、jboss.xmlはjboss-ejb3.xmlデプロイメント記述子に置き換えられました。この新しいファイルはjboss.xmlとの互換性がないため、jboss.xmlはデプロイメントで無視されます。 - login-config.xml
login-config.xmlファイルはセキュリティー設定で使用されないようになりました。セキュリティーはサーバー設定ファイルの<security-domain>要素に設定されるようになりました。スタンドアロンサーバーではstandalone/configuration/standalone.xmlファイルになります。管理対象ドメインでサーバーを実行している場合はdomain/configuration/domain.xmlファイルになります。
3.1.3.2. jboss-deployment-structure.xml リンクのコピーリンクがクリップボードにコピーされました!
jboss-deployment-structure.xml は JBoss EAP 6 の新しいオプションデプロイメント記述子です。このデプロイメント記述子を使用すると、デプロイメントのクラスローディングを制御できます。
EAP_HOME/docs/schema/jboss-deployment-structure-1_2.xsd にあります。
3.1.3.3. 新しいモジュラークラスローディングシステムのパッケージリソース リンクのコピーリンクがクリップボードにコピーされました!
以前のバージョンの JBoss EAP では、WEB-INF/ ディレクトリー内のすべてのリソースが WAR クラスパスに追加されました。JBoss EAP 6 では、Web アプリケーションのアーティファクトは WEB-INF/classes および WEB-INF/lib ディレクトリーからのみロードされます。指定の場所でアプリケーションアーティファクトのパッケージ化に失敗した場合、ClassNotFoundException や NoClassDefError などのランタイムエラーが発生します。
- リソースパッケージの編集
- アプリケーションのみがリソースを使用できるようにするには、プロパティーファイル、JAR、およびその他のアーティファクトを
WEB-INF/classes/またはWEB-INF/lib/ディレクトリーへ移動し、WAR とバンドルします。この方法の詳細については、 「ResourceBundle プロパティーの場所変更」 を参照してください。 - カスタムモジュールの作成
- JBoss EAP サーバー上で実行されているすべてのアプリケーションが、カスタムリソースを使用できるようにするには、カスタムモジュールを作成する必要があります。この方法の詳細については、 「カスタムモジュールの作成」を参照してください。
3.1.3.4. ResourceBundle プロパティーの場所変更 リンクのコピーリンクがクリップボードにコピーされました!
以前のバージョンの JBoss EAP では、EAP_HOME/server/SERVER_NAME/conf/ ディレクトリーはクラスパスに存在し、アプリケーションによる使用が可能でした。このプロパティーを JBoss EAP 6 のアプリケーションのクラスパスで使用できるようにするには、アプリケーション内でパッケージ化する必要があります。
手順3.2
- WAR アーカイブをデプロイする場合、これらのプロパティーを WAR の
WEB-INF/classes/フォルダーでパッケージ化する必要があります。 - これらのプロパティーを EAR のすべてのコンポーネントに対してアクセス可能にするには、JAR のルートでパッケージ化し、EAR の
lib/フォルダーに置く必要があります。
3.1.3.5. カスタムモジュールの作成 リンクのコピーリンクがクリップボードにコピーされました!
手順3.3 カスタムモジュールの作成
module/ディレクトリー構造を作成し、ファイルを追加します。EAP_HOME/moduleディレクトリー下にディレクトリー構造を作成し、ファイルや JAR が含まれるようにします。例は次のとおりです。cd EAP_HOME/modules/ $ mkdir -p myorg-conf/main/properties
$ cd EAP_HOME/modules/ $ mkdir -p myorg-conf/main/propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 作成した
EAP_HOME/modules/myorg-conf/main/properties/ディレクトリーにプロパティーファイルを移動します。 - 次の XML が含まれる
module.xmlファイルをEAP_HOME/modules/myorg-conf/main/ディレクトリーに作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- サーバー設定ファイルの
eeサブシステムを編集します。JBoss CLI を使用するか、手作業でファイルを編集します。- 次の手順に従って JBoss CLI を使用し、サーバー設定ファイルを編集します。
- サーバーを起動し、管理 CLI へ接続します。
- Linux の場合は、コマンドラインで以下を入力します。
EAP_HOME/bin/jboss-cli.sh --connect
$ EAP_HOME/bin/jboss-cli.sh --connectCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Windows の場合は、コマンドラインで以下を入力します。
C:\>EAP_HOME\bin\jboss-cli.bat --connect
C:\>EAP_HOME\bin\jboss-cli.bat --connectCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次の応答が表示されるはずです。Connected to standalone controller at localhost:9999
Connected to standalone controller at localhost:9999Copy to Clipboard Copied! Toggle word wrap Toggle overflow eeサブシステムにmyorg-conf<global-modules> 要素を作成するには、コマンドラインで以下を入力します。/subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])/subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の結果が表示されるはずです。{"outcome" => "success"}{"outcome" => "success"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- サーバー設定ファイルを手作業で編集する場合は、次の手順に従ってください。
- サーバーを停止し、テキストエディターでサーバー設定ファイルを開きます。スタンドアロンサーバーを実行している場合は、
EAP_HOME/standalone/configuration/standalone.xmlファイルになります。管理対象ドメインを実行している場合は、EAP_HOME/domain/configuration/domain.xmlファイルになります。 eeサブシステムを見つけ、myorg-confのグローバルモジュールを追加します。以下は、myorg-conf要素が含まれるように編集されたeeサブシステム要素の例になります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
my.propertiesという名前のファイルを正しいモジュールの場所にコピーした場合は、以下のようなコードを使用してプロパティーファイルをロードできるようになります。Thread.currentThread().getContextClassLoader().getResource("my.properties");Thread.currentThread().getContextClassLoader().getResource("my.properties");Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.4. ロギングの変更 リンクのコピーリンクがクリップボードにコピーされました!
3.1.4.1. ロギング依存関係の編集 リンクのコピーリンクがクリップボードにコピーされました!
JBoss LogManager はすべてのロギングフレームワークのフロントエンドをサポートするため、現在のロギングコードを保持することも、新しい JBoss のロギングインフラストラクチャーへ移行することも可能です。モジュラークラスローディングが変更されたため、いずれの場合でもアプリケーションを変更して必要な依存関係を追加する必要があるでしょう。
手順3.4 アプリケーションロギングコードの更新
3.1.4.2. サードパーティーロギングフレームワークのアプリケーションコードの更新 リンクのコピーリンクがクリップボードにコピーされました!
JBoss EAP 6 では、Apache Commons Logging、Apache log4j、SLF4J、Java Logging などの一般的なサードパーティーフレームワークのロギング依存関係はデフォルトで追加されています。ただし、log4j を使用し、ハンドラー (アペンダー) の設定にロギングサブシステムを使用しない場合は、JBoss EAP の log4j モジュールを除外する必要があります。
手順3.5 log4j.properties または log4j.xml ファイルを使用するよう JBoss EAP 6 を設定する
- 次の内容が含まれる
jboss-deployment-structure.xmlを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow jboss-deployment-structure.xmlファイルは、WAR をデプロイする場合はMETA-INF/ディレクトリーまたはWEB-INF/ディレクトリーに置き、EAR をデプロイする場合はMETA-INF/ディレクトリーに置きます。log4j.propertiesまたはlog4j.xmlファイルを、EAR のlib/ディレクトリーまたは WAR デプロイメントのWEB-INF/classes/ディレクトリーに含めます。- アプリケーションをデプロイします。
注記
3.1.4.3. 新しい JBoss ロギングフレームワークを使用したコードの変更 リンクのコピーリンクがクリップボードにコピーされました!
新しいフレームワークを使用するには、次のようにインポートとコードを変更します。
手順3.6 JBoss ロギングフレームワークを使用するようコードおよび依存関係を変更する
インポートとロギングコードの変更
新しい JBoss ロギングフレームワークを使用するコードの例は以下のとおりです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ロギング依存関係の追加
JBoss ロギングクラスが含まれる JAR はorg.jboss.loggingという名前のモジュールにあります。MANIFEST-MFファイルは次のようになるはずです。Manifest-Version: 1.0 Dependencies: org.jboss.logging
Manifest-Version: 1.0 Dependencies: org.jboss.loggingCopy to Clipboard Copied! Toggle word wrap Toggle overflow モジュール依存関係の検索方法に関する詳細については、「クラスローディングの変更によるアプリケーション依存関係の更新」と「移行の問題のデバッグと解決」を参照してください。
3.1.5. アプリケーションパッケージの変更 リンクのコピーリンクがクリップボードにコピーされました!
3.1.5.1. EAR および WAR パッケージの編集 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションを移行する際、モジュラークラスローディングの変更に伴い、EAR または WAR のパッケージ構造を変更する必要がある場合があります。モジュール依存関係は次の順序でロードされます。
- システム依存関係
- ユーザー依存関係
- ローカルリソース
- デプロイメント間の依存性
手順3.7 アーカイブパッケージの編集
WAR のパッケージ化
WAR は単一のモジュールで、WAR のすべてのクラスは同じクラスローダーでロードされます。そのためWEB-INF/lib/ディレクトリーにパッケージされるクラスは、WEB-INF/classesディレクトリーのクラスと同様に処理されます。EAR のパッケージ化
EAR は複数のモジュールによって構成されます。EAR/lib/ディレクトリーは単一のモジュールで、EAR 内の各 WAR や EJB jar サブデプロイメントは個別のモジュールになります。依存関係が明示的に定義された場合を除き、クラスは EAR 内の他のモジュールにあるクラスへアクセスすることはできません。サブデプロイメントは常に親モジュール上で自動的な依存関係を持ち、親モジュールはEAR/lib/ディレクトリーのクラスへのアクセスを許可します。しかし、サブデプロイメントはお互いのアクセスを許可するため常に自動的な依存関係を持っているわけではありません。この挙動は次のようにeeサブシステム設定の<ear-subdeployments-isolated>要素を設定すると制御することができます。<subsystem xmlns="urn:jboss:domain:ee:1.0" > <ear-subdeployments-isolated>false</ear-subdeployments-isolated> </subsystem>
<subsystem xmlns="urn:jboss:domain:ee:1.0" > <ear-subdeployments-isolated>false</ear-subdeployments-isolated> </subsystem>Copy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトでは false に設定され、EAR 内の他のサブデプロイメントに属するクラスがサブデプロイメントに対して可視化されます。クラスローディングの詳細については、https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ にある JBoss EAP 6 向け『開発ガイド『』』の章「クラスローディングとモジュール『』」を参照してください。
3.1.6. データソースおよびリソースアダプター設定の変更 リンクのコピーリンクがクリップボードにコピーされました!
3.1.6.1. 設定変更によるアプリケーションの更新 リンクのコピーリンクがクリップボードにコピーされました!
- アプリケーションがデータソースを使用する場合は、 「DataSource 設定の更新」を参照してください。
- アプリケーションが JPA を使用し、現在 Hibernate JAR をバンドルする場合は、 「Hibernate または JPA 用のデータソースの設定」を参照し、移行のオプションについて確認してください。
- アプリケーションがリソースアダプターを使用する場合は、 「リソースアダプター設定の更新」を参照してください。
- 「アプリケーションセキュリティーの変更設定」を参照し、基本的なセキュリティーの設定変更方法について確認してください。
3.1.6.2. DataSource 設定の更新 リンクのコピーリンクがクリップボードにコピーされました!
以前のバージョンの JBoss EAP では、ファイル名の最後に *-ds.xml が付くファイルに JCA データソースの設定が定義されていました。このファイルはサーバーの deploy/ ディレクトリーにデプロイされるか、アプリケーションによってパッケージ化されました。JDBC ドライバーは server/lib/ ディレクトリーにコピーされるか、アプリケーションの WEB-INF/lib/ ディレクトリーにパッケージ化されました。この設定方法は開発環境では今でもサポートされていますが、JBoss の管理ツールではサポートされていないため実稼働環境では推奨されません。
domain/configuration/domain.xml ファイルに設定されます。JBoss EAP 6 インスタンスがスタンドアロンサーバーとして実行されている場合、データソースは standalone/configuration/standalone.xml ファイルに設定されます。このように設定されたデータソースは、Web 管理コンソールやコマンドラインインターフェース (CLI) などが含まれる JBoss 管理インターフェースを使用して管理および制御されます。これらのツールはデプロイメントの管理や、管理対象ドメインで実行されている複数のサーバーの設定を容易にします。
JDBC 4.0 対応のドライバーはデプロイメントまたはコアモジュールとしてインストールすることができます。JDBC 4.0 対応のドライバーには、ドライバークラス名を指定する META-INF/services/java.sql.Driver ファイルが含まれています。JDBC 4.0 対応でないドライバーには追加の設定が必要となります。ドライバーを JDBC 4.0 対応にする方法や、現在のデータソース設定を Web 管理コンソールや CLI によって管理可能な設定に更新する方法の詳細については、 「JDBC ドライバーのインストールと設定」を参照してください。
IronJacamar ツールを使用するとデータソースおよびリソースアダプターの設定を移行できます。このツールは、*-ds.xml 形式の設定ファイルを JBoss EAP 6 が想定する形式に変換します。詳細は 「IronJacamar ツールを使用してデータソースとリソースアダプターの設定を移行する」を参照してください。
3.1.6.3. JDBC ドライバーのインストールと設定 リンクのコピーリンクがクリップボードにコピーされました!
次の 2 つの方法の 1 つを用いて JDBC ドライバーをコンテナにインストールできます。
- デプロイメントとしてのインストール
- コアモジュールとしてのインストール
domain/configuration/domain.xml ファイルに設定されます。JBoss EAP 6 インスタンスがスタンドアロンサーバーとして実行されている場合、データソースは standalone/configuration/standalone.xml ファイルに設定されます。両モードで共通のスキーマ参照情報は JBoss EAP 6 インストールの doc/schema/ ディレクトリーにあります。ここでは説明上、サーバーがスタンドアロンサーバーとして稼働し、データソースが standalone.xml ファイルに設定されていると仮定します。
手順3.8 JDBC ドライバーのインストールと設定
JDBC ドライバーのインストール
JDBC ドライバーのデプロイメントとしてのインストール
これはドライバーのインストールに推奨される方法です。JDBC ドライバーがデプロイメントとしてインストールされると、普通の JAR としてデプロイされます。JBoss EAP 6 インスタンスがスタンドアロンサーバーとして実行されている場合は、 JDBC 4.0 対応の JAR をEAP_HOME/standalone/deployments/ディレクトリーへコピーします。サーバーが管理対象ドメインとして実行されている場合は、JAR をEAP_HOME/domain/deployments/ディレクトリーへコピーします。スタンドアロンサーバーにデプロイメントとしてインストールされた MySQL JDBC ドライバーの例は次のとおりです。$cp mysql-connector-java-5.1.15.jar EAP_HOME/standalone/deployments/
$cp mysql-connector-java-5.1.15.jar EAP_HOME/standalone/deployments/Copy to Clipboard Copied! Toggle word wrap Toggle overflow JDBC 4.0 対応のドライバーは自動的に認識され、名前とバージョンによってシステムへインストールされます。JDBC 4.0 対応の JAR にはドライバーのクラス名を指定するMETA-INF/services/java.sql.Driverという名前のテキストファイルが含まれてます。ドライバーが 4.0 対応でない場合は、次の方法の 1 つを用いてデプロイ可能にすることができます。java.sql.Driverファイルを作成し、META-INF/services/パス下の JAR に追加します。このファイルには、次のようなドライバークラス名が含まれていなければなりません。com.mysql.jdbc.Driver
com.mysql.jdbc.DriverCopy to Clipboard Copied! Toggle word wrap Toggle overflow java.sql.Driverファイルをデプロイメントディレクトリーに作成します。スタンドアロンサーバーとして実行されている JBoss EAP 6 のインスタンスの場合、このファイルをEAP_HOME/standalone/deployments/META-INF/services/java.sql.Driverに置く必要があります。サーバーが管理ドメインで実行されている場合、EAP_HOME/domain/deployments/META-INF/services/java.sql.Driverに置く必要があります。
この方法の利点は次のとおりです。この方法の欠点は次のとおりです。- モジュールを定義する必要がないため、これが最も簡単な方法です。
- サーバーが管理対象ドメインで実行されている場合は、この方法を使用するデプロイメントがドメイン内のすべてのサーバーに自動的に伝播されます。つまり、管理者はドライバー JAR を手動で配布する必要がありません。
- JDBC ドライバーが複数の JAR (たとえば、ドライバー JAR および依存ライセンス JAR またはローカリゼーション JAR) から構成される場合、ドライバーをデプロイメントとしてインストールすることはできません。JDBC ドライバーは、コアモジュールとしてインストールする必要があります。
- ドライバーが JDBC 4.0 対応でない場合は、ドライバークラス名を含むファイルを作成し、JAR にインポートするか、
deployments/ディレクトリーにオーバーレイする必要があります。
コアモジュールとしての JDBC ドライバーのインストール
JDBC ドライバーをコアモジュールとしてインストールするには、EAP_HOME/modules/ディレクトリー下にファイルパス構造を作成する必要があります。この構造には、JDBC ドライバー JAR、任意の追加ベンダーライセンスまたはローカリゼーション JAR、およびモジュールを定義するmodule.xmlファイルが含まれます。MySQL JDBC ドライバーをコアモジュールとしてインストール
- ディレクトリー構造
EAP_HOME/modules/com/mysql/main/を作成します。 main/サブディレクトリーで、MySQL JDBC ドライバーに対する以下のモジュール定義を含むmodule.xmlファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow モジュール名 "com.mysql" はこのモジュールのディレクトリー構造と一致します。<dependencies>要素は、このモジュールの他のモジュールへの依存関係を指定するために使用されます。この場合、全 JDBC データソースの場合と同様に、javax.apiという名前の他のモジュールによって定義される Java JDBC API に依存します。このモジュールはmodules/system/layers/base/javax/api/main/ディレクトリーに存在します。注記
module.xmlファイルの最初に空白文字が存在しないようにしてください。空白文字が存在すると、このドライバーに対して 「New missing/unsatisfied dependencies」エラーが発生します。- MySQL JDBC ドライバー JAR を
EAP_HOME/modules/com/mysql/main/ディレクトリーへコピーします。cp mysql-connector-java-5.1.15.jar EAP_HOME/modules/com/mysql/main/
$ cp mysql-connector-java-5.1.15.jar EAP_HOME/modules/com/mysql/main/Copy to Clipboard Copied! Toggle word wrap Toggle overflow
IBM DB2 JDBC ドライバーおよびライセンス JAR をコアモジュールとしてインストール
この例は、 JDBC ドライバー JAR 以外に JAR が必要なドライバーをデプロイする方法を示すためにのみ提供されています。- ディレクトリー構造
EAP_HOME/modules/com/ibm/db2/main/を作成します。 main/サブディレクトリーで、IBM DB2 JDBC ドライバーとライセンスに対する以下のモジュール定義を含むmodule.xmlファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記
module.xmlファイルの最初に空白文字が存在しないようにしてください。空白文字が存在すると、このドライバーに対して 「New missing/unsatisfied dependencies」エラーが発生します。- JDBC ドライバーおよびライセンス JAR を
EAP_HOME/modules/com/ibm/db2/main/ディレクトリーにコピーします。cp db2jcc.jar EAP_HOME/modules/com/ibm/db2/main/ cp db2jcc_license_cisuz.jar EAP_HOME/modules/com/ibm/db2/main/
$ cp db2jcc.jar EAP_HOME/modules/com/ibm/db2/main/ $ cp db2jcc_license_cisuz.jar EAP_HOME/modules/com/ibm/db2/main/Copy to Clipboard Copied! Toggle word wrap Toggle overflow
この方法の利点は次のとおりです。この方法の欠点は次のとおりです。- これは、JDBC ドライバーが複数の JAR から構成される場合に有効な唯一の方法です。
- この方法では、JDBC 4.0 対応でないドライバーは、ドライバー JAR を変更したり、ファイルオーバーレイを作成したりせずにインストールできます。
- モジュールのセットアップはより困難になります。
- モジュールは、管理対象ドメインで実行されている各サーバーに手動でコピーする必要があります。
データソースの設定
データベースドライバーの追加
<driver>要素を同じファイルの<drivers>要素に追加します。以前*-ds.xmlファイルに定義されたデータソース情報と同じ情報が一部含まれます。最初にドライバー JAR が JDBC 4.0 対応であるか判断します。JDBC 4.0 対応の JAR にはドライバークラス名を指定するMETA-INF/services/java.sql.Driverファイルが含まれています。サーバーはこのファイルを使用して JAR のドライバークラス名を探します。JDBC 4.0 対応の ドライバーの JAR には既に<driver-class>要素が指定されているため、この要素は必要ありません。JDBC 4.0 対応 MySQL ドライバーのドライバー要素の例は次のとおりです。JDBC 4.0 対応でないドライバーには、ドライバークラスを指定する<driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"/>
<driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"/>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <driver-class>属性が必要です。これは、ドライバークラス名を指定するMETA-INF/services/java.sql.Driverファイルが存在しないためです。JDBC 4.0 対応でないドライバーのドライバー要素の例は、次のとおりです。<driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"><driver-class>com.mysql.jdbc.Driver</driver-class></driver>
<driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"><driver-class>com.mysql.jdbc.Driver</driver-class></driver>Copy to Clipboard Copied! Toggle word wrap Toggle overflow データソースの作成
standalone.xmlファイルの<datasources>セクションに<datasource>要素を作成します。このファイルには、以前に*-ds.xmlファイルに定義されたデータソース情報とほとんど同じ情報が含まれています。重要
変更がサーバーの再起動後にも維持されるようにするには、サーバー設定ファイルの編集前にサーバーを停止する必要があります。standalone.xmlファイルの MySQL データソース要素の例は次のとおりです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.6.4. Hibernate または JPA 用のデータソースの設定 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションが JPA を使用し、現在 Hibernate JAR をバンドルする場合、JBoss EAP 6 に含まれる Hibernate を使用した方がよいでしょう。このバージョンの Hibernate を使用するには、アプリケーションから古いバージョンの Hibernate バンドルを削除する必要があります。
手順3.9 Hibernate バンドルの削除
- アプリケーションライブラリーフォルダーより Hibernate JAR を削除します。
persistence.xmlファイルの<hibernate.transaction.manager_lookup_class>要素は必要がないため、削除またはコメントアウトします。
3.1.6.5. リソースアダプター設定の更新 リンクのコピーリンクがクリップボードにコピーされました!
以前のバージョンのアプリケーションサーバーでは、リソースアダプター設定は、ファイル名の最後に *-ds.xml が付くファイルで定義されました。JBoss EAP 6 では、リソースアダプターはサーバー設定ファイルで設定されます。管理対象ドメインで実行されている場合、設定ファイルは EAP_HOME/domain/configuration/domain.xml ファイルになります。スタンドアロンサーバーとして実行されている場合、EAP_HOME/standalone/configuration/standalone.xml ファイルのリソースアダプターを設定します。リソースアダプター記述子 にあるスキーマ参照情報は両モード共通です。
重要
リソースアダプター記述子の情報は、サーバー設定ファイルの次のサブシステム要素下に定義されます。
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1"/>
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1"/>
*-ds.xml ファイルに定義された情報と同じものの一部を使用します。
3.1.7. セキュリティーの変更 リンクのコピーリンクがクリップボードにコピーされました!
3.1.7.1. アプリケーションセキュリティーの変更設定 リンクのコピーリンクがクリップボードにコピーされました!
以前のバージョンの JBoss EAP では、EAP_HOME/server/SERVER_NAME/conf/ ディレクトリーに置かれたプロパティーファイルはクラスパス上にあり、UsersRolesLoginModule によって簡単に見つかりました。JBoss EAP 6 ではディレクトリー構造が変更されたため、プロパティーファイルをアプリケーション内でパッケージ化し、クラスパスで使用できるようにする必要があります。
重要
security-domains 下の新しいセキュリティードメインを standalone/configuration/standalone.xml または domain/configuration/domain.xml サーバー設定ファイルに追加します。
${jboss.server.config.dir} は EAP_HOME/standalone/configuration/ ディレクトリーを参照します。インスタンスが管理対象ドメインで実行されている場合、 ${jboss.server.config.dir} は EAP_HOME/domain/configuration/ ディレクトリーを参照します。
JBoss EAP 6 では、セキュリティードメインは名前で接頭辞 java:/jaas/ を使用しなくなりました。
- Web アプリケーションの場合は、
jboss-web.xmlのセキュリティードメイン設定からこの接頭辞を削除する必要があります。 - エンタープライズアプリケーションの場合は、
jboss-ejb3.xmlファイルのセキュリティードメイン設定からこの接頭辞を削除する必要があります。JBoss EAP 6 では、jboss.xmlはこのファイルに置き換えられました。
3.1.8. JNDI の変更 リンクのコピーリンクがクリップボードにコピーされました!
3.1.8.1. アプリケーションの JNDI 名前空間名の更新 リンクのコピーリンクがクリップボードにコピーされました!
EJB 3.1 には、標準化されたグローバル JNDI 名前空間や、Java EE アプリケーションのさまざまなスコープへマップする名前空間が導入されました。移植可能な EJB 名は、java:global、 java:module、 java:app の 3 つのみへバインドされます。EJB を用いるアプリケーションが JNDI を使用する場合、そのアプリケーションを変更し、新しい標準 JNDI 名前空間の慣例に従うようにする必要があります。
手順3.10 JNDI ルックアップの変更
- 「移植可能な EJB JNDI 名」を確認する
以前のリリースにおける JNDI 名前空間の例や、 JBoss EAP 6 で指定する方法については、 「以前のリリースでの JNDI 名前空間の例、および JBoss EAP 6 での名前空間の指定方法」を参照してください。
3.1.8.2. 移植可能な EJB JNDI 名 リンクのコピーリンクがクリップボードにコピーされました!
Java EE 6 仕様には、独自のスコープを持つ 4 つの論理的な名前空間が定義されていますが、移植可能な EJB 名はそのうちの 3 つの名前空間へのみバインドされます。下表は、各名前空間の使用方法と使用時の詳細を表しています。
| JNDI 名前空間 | 説明 |
|---|---|
| java:global |
この名前空間の名前は、アプリケーションサーバーインスタンスにデプロイされてたすべてのアプリケーションで共有されます。同じサーバーへデプロイされた EJB の外部アーカイブを検索するには、この名前空間の名前を使用します。
Java:global 名前空間の例は、
java:global/jboss-seam-booking/jboss-seam-booking-jar/HotelBookingAction です。
|
| java:module |
この名前空間の名前は、1 つの EJB モジュールにある全エンタープライズ Bean や Web モジュールにある全コンポーネントなど、モジュール内の全コンポーネントで共有されます。
java:module 名前空間の例は、
java:module/HotelBookingAction!org.jboss.seam.example.booking.HotelBooking です。
|
| java:app |
この名前空間の名前は、1つのアプリケーション内にある全モジュールのコンポーネントすべてで共有されます。例えば、同じ EAR ファイルにある WAR や EJB jar ファイルは java:app 名前空間のリソースにアクセスできます。
java:app 名前空間の例は、
java:app/jboss-seam-booking-jar/HotelBookingAction です。
|
3.1.8.3. JNDI 名前空間のルールの確認 リンクのコピーリンクがクリップボードにコピーされました!
JBoss EAP 6 では JNDI 名前空間の名前が改良され、アプリケーションにバインドされた名前に対して予測可能で一貫性のあるルールを提供するだけでなく、将来的に互換性の問題が起こらないよう対処されます。そのため、現在の名前空間が新ルールに準拠しない場合、問題が発生することがあります。
DefaultDSやjdbc/DefaultDSなどの不適切な相対名は、コンテキストに応じてjava:comp/env、java:module/env、またはjava:jboss/envに対して相対的に修飾する必要があります。/jdbc/DefaultDSなどの不適切なabsolute名は、java:jboss/root名に対して相対的に修飾する必要があります。java:/jdbc/DefaultDSなどの適切なabsolute名は、上記の不適切なabsolute名と同様に修飾する必要があります。- 特別な
java:jboss名前空間は、 AS サーバーインスタンス全体で共有されます。 java:接頭辞を持つrelative名は、comp、module、app、global、または商用のjbossの 5 つの名前空間のいずれかに属する必要があります。xxx がこの 5 つのいずれにも一致しないjava:xxxで始まる名前の場合は、無効な名前エラーが発生します。
3.1.8.4. JNDI 名前空間の新ルールに準拠するようアプリケーションを変更する リンクのコピーリンクがクリップボードにコピーされました!
- JBoss EAP 5.1 の JNDI ルックアップの例は次のとおりです。通常、このコードは初期化メソッドに存在します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルックアップ名はOrderManagerApp/ProductManagerBean/localになります。 - 次の例は、JBoss EAP 6 では同じルックアップがどのようにコード化されるかを表しています。
@EJB(lookup="java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager") private ProductManager productManager;
@EJB(lookup="java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager") private ProductManager productManager;Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルックアップ値はメンバー変数として定義され、新しい移植可能なjava:appJNDI 名前空間名であるjava:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManagerが使用されます。 - CDI を使用したくない場合は、前述のとおりに新しい InitialContext を作成し、新しい JNDI 名前空間名を使用するようにルックアップを編集します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.8.5. 以前のリリースでの JNDI 名前空間の例、および JBoss EAP 6 での名前空間の指定方法 リンクのコピーリンクがクリップボードにコピーされました!
| JBoss EAP 5.x の名前空間 | JBoss EAP 6 の名前空間 | 追加コメント |
|---|---|---|
| OrderManagerApp/ProductManagerBean/local | java:module/ProductManagerBean!services.ejb.ProductManager | Java EE 6 の標準バインディング。現在のモジュールへスコープ指定され、同じモジュール内でのみアクセス可能。 |
| OrderManagerApp/ProductManagerBean/local | java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager | Java EE 6 の標準バインディング。現在のアプリケーションへスコープ指定され、同じアプリケーション内でのみアクセス可能。 |
| OrderManagerApp/ProductManagerBean/local | java:global/OrderManagerApp/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager | Java EE 6 の標準バインディング。アプリケーションサーバーへスコープ指定され、グローバルにアクセス可能です。 |
| java:comp/UserTransaction | java:comp/UserTransaction | 名前空間は現在のコンポーネントへスコープ指定されます。アプリケーションによって直接作成されるスレッドなど、Java EE 6 でないスレッドはアクセスできません。 |
| java:comp/UserTransaction | java:jboss/UserTransaction | グローバルにアクセス可能です。java:comp/UserTransaction が使用できないときに使用します。 |
| java:/TransactionManager | java:jboss/TransactionManager | |
| java:/TransactionSynchronizationRegistry | java:jboss/TransactionSynchronizationRegistry |