第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>要素の例になります。<!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 4.2//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_4_2.dtd"> <jboss-web> <!-- <class-loading java2ClassLoadingCompliance="false"> <loader-repository> seam.jboss.org:loader=MyApplication <loader-repository-config>java2ParentDelegation=false</loader-repository-config> </loader-repository> </class-loading> --> </jboss-web>- MANIFEST.MF
- 手作業による編集
- アプリケーションが使用するコンポーネントやモジュールによって異なりますが、このファイルに 1 つ以上の依存関係を追加する必要がある場合があります。依存関係は
DependenciesエントリーまたはClass-Pathエントリーとして追加できます。開発者によって編集されたMANIFEST.MFの例は次のとおりです。Manifest-Version: 1.0 Dependencies: org.jboss.logmanager Class-Path: OrderManagerEJB.jar
このファイルを編集する場合、必ずファイルの最後にニューライン文字が含まれるようにしてください。 - Maven を使用した生成
- Maven を使用する場合、
pom.xmlファイルを編集してMANIFEST.MFファイルの依存関係を生成する必要があります。アプリケーションによって EJB 3.0 が使用される場合、pom.xmlファイルに次のようなセクションが含まれることがあります。<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-ejb-plugin</artifactId> <configuration> <ejbVersion>3.0</ejbVersion> </configuration> </plugin>EJB 3.0 コードがorg.apache.commons.logを使用する場合、MANIFEST.MFファイルにこの依存関係が存在しなければなりません。この依存関係を生成するには、次のように<plugin>要素をpom.xmlファイルに追加します。<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-ejb-plugin</artifactId> <configuration> <ejbVersion>3.0</ejbVersion> <archive> <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile> </archive> </configuration> </plugin>上記の例では、次の依存関係エントリのみがsrc/main/resources/META-INF/MANIFEST.MFファイルに含まれる必要があります。Dependencies: org.apache.commons.logging
Maven は完全なMANIFEST.MFファイルを生成します。Manifest-Version: 1.0 Dependencies: org.apache.commons.logging
- jboss-deployment-structure.xml
- このファイルは、クラスローディングを細かく制御するために使用される JBoss 固有のデプロイメント記述子です。
MANIFEST.MFと同様に、このファイルを使用して依存関係を追加することが可能です。また、自動的な依存関係が追加されないようにしたり、追加のモジュールを定義することが可能で、EAR デプロイメントの分離されたクラスローディング動作を変更したり、追加のリソースルートをモジュールへ追加したりすることもできます。JSF 1.2 モジュールの依存関係を追加し、JSF 2.0 モジュールが自動的にローディングされないようにするjboss-deployment-structure.xmlファイルの例は次のとおりです。<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0"> <deployment> <dependencies> <module name="javax.faces.api" slot="1.2" export="true"/> <module name="com.sun.jsf-impl" slot="1.2" export="true"/> </dependencies> </deployment> <sub-deployment name="jboss-seam-booking.war"> <exclusions> <module name="javax.faces.api" slot="main"/> <module name="com.sun.jsf-impl" slot="main"/> </exclusions> <dependencies> <module name="javax.faces.api" slot="1.2"/> <module name="com.sun.jsf-impl" slot="1.2"/> </dependencies> </sub-deployment> </jboss-deployment-structure>このファイルに関する詳細は、 「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 へアクセスする場合はモジュールの順番を指定する必要がある場合があります。init() { Context ctx = new InitialContext(); ctx.lookup("TheBeanInMyBeansModule"); }この場合、EJB コンポーネントがmyBeans.jarにあることをサーバーが判断できないため、myBeans.jarのコンポーネントがmyApp.warのコンポーネントの前に初期化され開始されるよう強制する必要があります。これには、<initialize-in-order>要素をtrueに設定し、myBeans.jarモジュールとmyApp.warモジュールの順番をapplication.xmlファイルに指定します。以下は<initialize-in-order>要素を使用してデプロイメントの順番を制御する例になります。myBeans.jarはmyApp.warファイルの前にデプロイされます。<application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="6" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_6.xsd"> <application-name>myApp</application-name> <initialize-in-order>true</initialize-in-order> <module> <ejb>myBeans.jar</ejb> </module> <module> <web> <web-uri>myApp.war</web-uri> <context-root>myApp</context-root> </web> </module> </application>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- 作成した
EAP_HOME/modules/myorg-conf/main/properties/ディレクトリーにプロパティーファイルを移動します。 - 次の XML が含まれる
module.xmlファイルをEAP_HOME/modules/myorg-conf/main/ディレクトリーに作成します。<module xmlns="urn:jboss:module:1.1" name="myorg-conf"> <resources> <resource-root path="properties"/> </resources> </module>
- サーバー設定ファイルの
eeサブシステムを編集します。JBoss CLI を使用するか、手作業でファイルを編集します。- 次の手順に従って JBoss CLI を使用し、サーバー設定ファイルを編集します。
- サーバーを起動し、管理 CLI へ接続します。
- Linux の場合は、コマンドラインで以下を入力します。
$ EAP_HOME/bin/jboss-cli.sh --connect
- Windows の場合は、コマンドラインで以下を入力します。
C:\>EAP_HOME\bin\jboss-cli.bat --connect
次の応答が表示されるはずです。Connected to standalone controller at localhost:9999
eeサブシステムにmyorg-conf<global-modules> 要素を作成するには、コマンドラインで以下を入力します。/subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])次の結果が表示されるはずです。{"outcome" => "success"}
- サーバー設定ファイルを手作業で編集する場合は、次の手順に従ってください。
- サーバーを停止し、テキストエディターでサーバー設定ファイルを開きます。スタンドアロンサーバーを実行している場合は、
EAP_HOME/standalone/configuration/standalone.xmlファイルになります。管理対象ドメインを実行している場合は、EAP_HOME/domain/configuration/domain.xmlファイルになります。 eeサブシステムを見つけ、myorg-confのグローバルモジュールを追加します。以下は、myorg-conf要素が含まれるように編集されたeeサブシステム要素の例になります。<subsystem xmlns="urn:jboss:domain:ee:1.0" > <global-modules> <module name="myorg-conf" slot="main" /> </global-modules> </subsystem>
my.propertiesという名前のファイルを正しいモジュールの場所にコピーした場合は、以下のようなコードを使用してプロパティーファイルをロードできるようになります。Thread.currentThread().getContextClassLoader().getResource("my.properties");
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を作成します。<jboss-deployment-structure> <deployment> <!-- Exclusions allow you to prevent the server from automatically adding some dependencies --> <exclusions> <module name="org.apache.log4j" /> </exclusions> </deployment> </jboss-deployment-structure> 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>パスを指定する必要があります。<jboss-deployment-structure> <deployment> <!-- Exclusions allow you to prevent the server from automatically adding some dependencies --> <exclusions> <module name="org.apache.log4j" /> </exclusions> <resources> <resource-root path="lib" /> </resources> </deployment> </jboss-deployment-structure>- 以下の引数を用いて JBoss EAP 6 サーバーを起動し、アプリケーションをデプロイするときに
ClassCastExceptionがコンソールに表示されないようにします。-Dorg.jboss.as.logging.per-deployment=false
- アプリケーションをデプロイします。
手順3.6 JBoss EAP 6.3 またはそれ以降のバージョンでのロギング依存関係の設定
add-logging-api-dependencies ロギングシステム属性を使用してサードパーティーロギングフレームワークの依存関係を除外できます。以下の手順は、JBoss EAP スタンドアロンサーバーでこのロギング属性を変更する方法を示しています。
- 以下の引数を用いて JBoss EAP 6 サーバーを起動し、アプリケーションをデプロイするときに
ClassCastExceptionがコンソールに表示されないようにします。-Dorg.jboss.as.logging.per-deployment=false
- ターミナルを開き、管理 CLI へ接続します。
- Linux の場合は、コマンドラインで以下を入力します。
$ EAP_HOME/bin/jboss-cli.sh --connect
- Windows の場合は、コマンドラインで以下を入力します。
C:\>EAP_HOME\bin\jboss-cli.bat --connect
- ロギングサブシステムの
add-logging-api-dependencies属性を編集します。この属性は、コンテナが暗黙的なロギング API の依存関係を追加するかどうかを制御します。- デフォルトの
trueに設定すると、暗黙的なロギング API の依存関係がすべて追加されます。 falseに設定すると、依存関係はデプロイメントへ追加されません。
サードパーティーロギングフレームワークの依存関係を除外するには、以下のコマンドを使用してこの属性をfalseに設定する必要があります。/subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)このコマンドは、<add-logging-api-dependencies>要素をstandalone.xml設定ファイルのloggingサブシステムに追加します。<subsystem xmlns="urn:jboss:domain:logging:1.4"> <add-logging-api-dependencies value="false"/> .... </subsystem> - アプリケーションをデプロイします。
3.1.4.3. 新しい JBoss ロギングフレームワークを使用したコードの変更
新しいフレームワークを使用するには、次のようにインポートとコードを変更します。
手順3.7 JBoss ロギングフレームワークを使用するようコードおよび依存関係を変更する
インポートとロギングコードの変更
新しい JBoss ロギングフレームワークを使用するコードの例は以下のとおりです。import org.jboss.logging.Level; import org.jboss.logging.Logger; private static final Logger logger = Logger.getLogger(MyClass.class.toString()); if(logger.isTraceEnabled()) { logger.tracef("Starting...", subsystem); }ロギング依存関係の追加
JBoss ロギングクラスが含まれる JAR はorg.jboss.loggingという名前のモジュールにあります。MANIFEST-MFファイルは次のようになるはずです。Manifest-Version: 1.0 Dependencies: org.jboss.logging
モジュール依存関係の検索方法に関する詳細については、「クラスローディングの変更によるアプリケーション依存関係の更新」と「移行の問題のデバッグと解決」を参照してください。
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>
デフォルトでは 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/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.Driverjava.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ファイルを作成します。<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.0" name="com.mysql"> <resources> <resource-root path="mysql-connector-java-5.1.15.jar"/> </resources> <dependencies> <module name="javax.api"/> </dependencies> </module>モジュール名 "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/
IBM DB2 JDBC ドライバーとライセンス JAR をコアモジュールとしてインストールします。
この例は、 JDBC ドライバー JAR 以外に JAR が必要なドライバーをデプロイする方法を示すためにのみ提供されています。- ディレクトリー構造
EAP_HOME/modules/com/ibm/db2/main/を作成します。 main/サブディレクトリーで、IBM DB2 JDBC ドライバーとライセンスに対する以下のモジュール定義を含むmodule.xmlファイルを作成します。<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.1" name="com.ibm.db2"> <resources> <resource-root path="db2jcc.jar"/> <resource-root path="db2jcc_license_cisuz.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>注記
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.jarEAP_HOME/modules/com/ibm/db2/main/
この方法の利点は次のとおりです。この方法の欠点は次のとおりです。- これは、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 ドライバーのドライバー要素の例は次のとおりです。<driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"/>
JDBC 4.0 対応でないドライバーには、ドライバークラスを指定する<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>
データソースを作成します。
standalone.xmlファイルの<datasources>セクションに<datasource>要素を作成します。このファイルには、以前に*-ds.xmlファイルに定義されたデータソース情報とほとんど同じ情報が含まれています。重要
サーバーの再起動後も変更が維持されるようにするには、サーバーを停止してからサーバー設定ファイルを編集する必要があります。standalone.xmlファイルの MySQL データソース要素の例は次のとおりです。<datasource jndi-name="java:/YourDatasourceName" pool-name="YourDatasourceName"> <connection-url>jdbc:mysql://localhost:3306/YourApplicationURL</connection-url> <driver>mysql-connector-java-5.1.15.jar</driver> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation> <pool> <min-pool-size>100</min-pool-size> <max-pool-size>200</max-pool-size> </pool> <security> <user-name>USERID</user-name> <password>PASSWORD</password> </security> <statement> <prepared-statement-cache-size>100</prepared-statement-cache-size> <share-prepared-statements/> </statement> </datasource>
アプリケーションコードで JNDI 参照を更新します。
定義した新しい JNDI 標準データソース名を使用するには、アプリケーションソースコードの古い JNDI ルックアップ名を置き換える必要があります。詳細は、 「JNDI 名前空間の新ルールに準拠するようアプリケーションを変更」を参照してください。新しい JNDI 名を使用するには、データソースにアクセスする既存の@Resourceアノテーションも置き換える必要があります。例は次のとおりです。@Resource(name = "java:/YourDatasourceName").
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"/>以前にリソースアダプター
*-ds.xml ファイルに定義された情報と同じものの一部を使用します。
<resource-adapters>
<resource-adapter>
<archive>multiple-full.rar</archive>
<config-property name="Name">ResourceAdapterValue</config-property>
<transaction-support>NoTransaction</transaction-support>
<connection-definitions>
<connection-definition
class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleManagedConnectionFactory1"
enabled="true" jndi-name="java:/eis/MultipleConnectionFactory1"
pool-name="MultipleConnectionFactory1">
<config-property name="Name">MultipleConnectionFactory1Value</config-property>
</connection-definition>
<connection-definition
class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleManagedConnectionFactory2"
enabled="true" jndi-name="java:/eis/MultipleConnectionFactory2"
pool-name="MultipleConnectionFactory2">
<config-property name="Name">MultipleConnectionFactory2Value</config-property>
</connection-definition>
</connection-definitions>
<admin-objects>
<admin-object
class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleAdminObject1Impl"
jndi-name="java:/eis/MultipleAdminObject1">
<config-property name="Name">MultipleAdminObject1Value</config-property>
</admin-object>
<admin-object class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleAdminObject2Impl"
jndi-name="java:/eis/MultipleAdminObject2">
<config-property name="Name">MultipleAdminObject2Value</config-property>
</admin-object>
</admin-objects>
</resource-adapter>
</resource-adapters>
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 サーバー設定ファイルに追加します。
<security-domain name="example">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties"
value="${jboss.server.config.dir}/example-users.properties"/>
<module-option name="rolesProperties"
value="${jboss.server.config.dir}/example-roles.properties"/>
</login-module>
</authentication>
</security-domain>
${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ファイルを作成します。 - 以下の内容を追加します。
<?xml version="1.1" encoding="UTF-8"?> <webservices xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee"> <property> <name>org.jboss.ws.cxf.disableHandlerAuthChecks</name> <value>true</value> </property> </webservices>
注記
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 つの名前空間へのみバインドされます。下表は、各名前空間の使用方法と使用時の詳細を表しています。
表3.1 移植可能な JNDI 名前空間
| 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 ルックアップの例は次のとおりです。通常、このコードは初期化メソッドに存在します。
private ProductManager productManager; try { context = new InitialContext(); productManager = (ProductManager) context.lookup("OrderManagerApp/ProductManagerBean/local"); } catch(Exception lookupError) { throw new ServletException("Unable to find the ProductManager bean", lookupError); }ルックアップ名はOrderManagerApp/ProductManagerBean/localになります。 - 以下は、ディペンデンシーインジェクション (依存性の注入) を使用して JBoss EAP 6 で同じルックアップがどのようにコード化されるかを示した例になります。
@EJB(lookup="java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager") private ProductManager productManager;
ルックアップ値はメンバー変数として定義され、新しい移植可能なjava:appJNDI 名前空間名であるjava:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManagerが使用されます。 - ディペンデンシーインジェクション (依存性の注入)を使用したくない場合は、前述のとおりに InitialContext を新規作成し、新しい JNDI 名前空間名を使用するようにルックアップを編集します。
private ProductManager productManager; try { context = new InitialContext(); productManager = (ProductManager) context.lookup("java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager"); } catch(Exception lookupError) { throw new ServletException("Unable to find the ProductManager bean", lookupError); }
3.1.8.5. 以前のリリースでの JNDI 名前空間の例、および JBoss EAP 6 での名前空間の指定方法
表3.2 JNDI 名前空間マッピングテーブル
| 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 |