第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.jar
Copy 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.logging
Copy 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.logging
Copy 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 ResourceBundle プロパティーの場所変更
- 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/ $ cd EAP_HOME/modules/ $ cd EAP_HOME/modules/ $ mkdir -p myorg-conf/main/properties
Copy 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 --connect
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Windows の場合は、コマンドラインで以下を入力します。
C:\>EAP_HOME\bin\jboss-cli.bat --connect
C:\>EAP_HOME\bin\jboss-cli.bat --connect
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次の応答が表示されるはずです。Connected to standalone controller at localhost:9999
Connected to standalone controller at localhost:9999
Copy 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 などの一般的なサードパーティーフレームワークのロギング依存関係はデフォルトで追加されています。ほとんどの場合で、JBoss EAP コンテナによって提供されるロギングフレームワークを使用することが推奨されますが、サードパーティーのフレームワークによって提供される機能が必要な場合は、デプロイメントから対応する JBoss EAP モジュールを除外する必要があります。デプロイメントがサードパーティーのロギングフレームワークを使用する場合でも、サーバーログは継続して JBoss EAP ロギングサブシステムの設定を使用することに注意してください。
org.apache.log4j
モジュールをデプロイメントから除外する方法を示しています。最初の手順は、JBoss EAP 6 のすべてのリリースで動作します。2 つ目の手順は、JBoss EAP 6.3 およびそれ以降のリリースのみで使用できます。
手順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/
ディレクトリーに含まれるようにします。このファイルを WAR のlib/
ディレクトリーに置きたい場合は、jboss-deployment-structure.xml
ファイルに<resource-root>
パスを指定する必要があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 以下の引数を用いて JBoss EAP 6 サーバーを起動し、アプリケーションをデプロイするときに
ClassCastException
がコンソールに表示されないようにします。-Dorg.jboss.as.logging.per-deployment=false
-Dorg.jboss.as.logging.per-deployment=false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - アプリケーションをデプロイします。
手順3.6 JBoss EAP 6.3 またはそれ以降のバージョンでのロギング依存関係の設定
add-logging-api-dependencies
ロギングシステム属性を使用してサードパーティーロギングフレームワークの依存関係を除外できます。以下の手順は、JBoss EAP スタンドアロンサーバーでこのロギング属性を変更する方法を示しています。
- 以下の引数を用いて JBoss EAP 6 サーバーを起動し、アプリケーションをデプロイするときに
ClassCastException
がコンソールに表示されないようにします。-Dorg.jboss.as.logging.per-deployment=false
-Dorg.jboss.as.logging.per-deployment=false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ターミナルを開き、管理 CLI へ接続します。
- Linux の場合は、コマンドラインで以下を入力します。
EAP_HOME/bin/jboss-cli.sh --connect
$ EAP_HOME/bin/jboss-cli.sh --connect
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Windows の場合は、コマンドラインで以下を入力します。
C:\>EAP_HOME\bin\jboss-cli.bat --connect
C:\>EAP_HOME\bin\jboss-cli.bat --connect
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- ロギングサブシステムの
add-logging-api-dependencies
属性を編集します。この属性は、コンテナが暗黙的なロギング API の依存関係を追加するかどうかを制御します。- デフォルトの
true
に設定すると、暗黙的なロギング API の依存関係がすべて追加されます。 false
に設定すると、依存関係はデプロイメントへ追加されません。
サードパーティーロギングフレームワークの依存関係を除外するには、以下のコマンドを使用してこの属性をfalse
に設定する必要があります。/subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)
/subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、<add-logging-api-dependencies>
要素をstandalone.xml
設定ファイルのlogging
サブシステムに追加します。<subsystem xmlns="urn:jboss:domain:logging:1.4"> <add-logging-api-dependencies value="false"/> .... </subsystem>
<subsystem xmlns="urn:jboss:domain:logging:1.4"> <add-logging-api-dependencies value="false"/> .... </subsystem>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - アプリケーションをデプロイします。
3.1.4.3. 新しい JBoss ロギングフレームワークを使用したコードの変更 リンクのコピーリンクがクリップボードにコピーされました!
新しいフレームワークを使用するには、次のようにインポートとコードを変更します。
手順3.7 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.logging
Copy to Clipboard Copied! Toggle word wrap Toggle overflow モジュール依存関係の検索方法に関する詳細については、「クラスローディングの変更によるアプリケーション依存関係の更新」と「移行の問題のデバッグと解決」を参照してください。
3.1.5. アプリケーションパッケージの変更 リンクのコピーリンクがクリップボードにコピーされました!
3.1.5.1. EAR および WAR パッケージの編集 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションを移行する際、モジュラークラスローディングの変更に伴い、EAR または WAR のパッケージ構造を変更する必要がある場合があります。モジュール依存関係は次の順序でロードされます。
- システム依存関係
- ユーザー依存関係
- ローカルリソース
- デプロイメント間の依存性
手順3.8 アーカイブパッケージの編集
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.9 JDBC ドライバーのインストールと設定
JDBC ドライバーをインストールします。
JDBC ドライバーをデプロイメントとしてインストールします。
これはドライバーのインストールに推奨される方法です。JDBC ドライバーがデプロイメントとしてインストールされると、普通の JAR としてデプロイされます。JBoss EAP 6 インスタンスがスタンドアロンサーバーとして実行されている場合は、 JDBC 4.0 対応の JAR をEAP_HOME/standalone/deployments/
ディレクトリーへコピーします。管理対象ドメインの場合は、管理コンソールまたは管理 CLI を使用して JAR をサーバーグループにデプロイする必要があります。スタンドアロンサーバーにデプロイメントとしてインストールされた 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/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.Driver
Copy to Clipboard Copied! Toggle word wrap Toggle overflow java.sql.Driver
ファイルをデプロイメントディレクトリーに作成します。スタンドアロンサーバーとして実行されている JBoss EAP 6 のインスタンスの場合、このファイルをEAP_HOME/standalone/deployments/META-INF/services/java.sql.Driver
に置く必要があります。サーバーが管理ドメインで実行されている場合は、管理コンソールまたは管理 CLI を使用してファイルをデプロイする必要があります。
この方法の利点は次のとおりです。この方法の欠点は次のとおりです。- モジュールを定義する必要がないため、これが最も簡単な方法です。
- サーバーが管理対象ドメインで実行されている場合は、この方法を使用するデプロイメントがドメイン内のすべてのサーバーに自動的に伝播されます。つまり、管理者はドライバー 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/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/EAP_HOME/modules/com/ibm/db2/main/ $ cp db2jcc_license_cisuz.jar EAP_HOME/modules/com/ibm/db2/main/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
アプリケーションコードで JNDI 参照を更新します。
定義した新しい JNDI 標準データソース名を使用するには、アプリケーションソースコードの古い JNDI ルックアップ名を置き換える必要があります。詳細は、 「JNDI 名前空間の新ルールに準拠するようアプリケーションを変更」を参照してください。新しい JNDI 名を使用するには、データソースにアクセスする既存の@Resource
アノテーションも置き換える必要があります。例は次のとおりです。@Resource(name = "java:/YourDatasourceName").
@Resource(name = "java:/YourDatasourceName").
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.6.4. Hibernate または JPA 用のデータソースの設定 リンクのコピーリンクがクリップボードにコピーされました!
手順3.10 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
ファイルのリソースアダプターを設定します。両モードで共通であるスキーマ参照の情報は、IronJacamar の Web サイト http://www.ironjacamar.org/documentation.html の「Schemas」にあります。
重要
リソースアダプター記述子の情報は、サーバー設定ファイルの次のサブシステム要素下に定義されます。
<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.7.2. PicketLink STS および Web サービスを使用するアプリケーションの更新 リンクのコピーリンクがクリップボードにコピーされました!
JBoss EAP 6.1 のアプリケーションが PicketLink STS および Web サービスを使用する場合、JBoss EAP 6.2 またはそれ以降のバージョンへ移行するときに変更を加える必要があることがあります。CVE-2013-2133 に対処するために JBoss EAP に適用された修正により、EJB3 ベースの WS エンドポイントにアタッチする JAXWS ハンドラーを実行する前にコンテナによる承認チェックが実行されます。この結果、プロセスの後半で使用されるはずのセキュリティープリンシパルが PicketLink SAML2Handler
によって確立されるため、PicketLink STS の機能が影響を受けます。 HandlerAuthInterceptor
が SAML2Handler
にアクセスするときはプリンシパルが NULL
であるため、サーバーログに NullPointerException
が記録されることがあります。この問題を修正するには、このセキュリティーチェックを無効にする必要があります。
手順3.11 他の承認チェックの無効化
- 他の承認チェックを無効にし、既存の PicketLink デプロイメントを継続して使用するには、以下の方法の 1 つを使用します。
システム全体のプロパティーの設定
サーバーレベルで他の承認チェックを無効にするには、org.jboss.ws.cxf.disableHandlerAuthChecks
システムプロパティーの値をtrue
に設定します。この方法は、アプリケーションサーバーに対して作成されたすべてのデプロイメントに影響します。システムプロパティーの設定方法は、JBoss EAP 『管理および設定ガイド』の「管理 CLI を使用したシステムプロパティーの設定」を参照してください。デプロイメントの Web サービス記述子ファイルでのプロパティーの作成
デプロイメントレベルで他の承認チェックを無効にするには、jboss-webservices.xml
ファイルでorg.jboss.ws.cxf.disableHandlerAuthChecks
プロパティーの値をtrue
に設定します。この方法は、特定のデプロイメントのみに影響します。- 他の承認チェックを無効にしたいデプロイメントの
META-INF/
ディレクトリーでjboss-webservices.xml
ファイルを作成します。 - 以下の内容を追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
注記
org.jboss.ws.cxf.disableHandlerAuthChecks
プロパティーを有効にします。EJB メソッド上で宣言された制限が適用されることをアプリケーションが想定し、JAX-WS ハンドラーに独立して制限を適用しない場合、プロパティーを有効にしないでください。アプリケーションを破壊しないようにするため、後方互換性を維持するのに必要な場合のみこのプロパティーを使用してください。
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.12 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:app
JNDI 名前空間名であるjava:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager
が使用されます。 - ディペンデンシーインジェクション (依存性の注入)を使用したくない場合は、前述のとおりに 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 |