1. まず、アプリケーションとその依存関係のパッケージ化を確認します。詳細は、 「クラスローディングの変更によるアプリケーション依存関係の更新」を参照してください。
2. アプリケーションがロギングする場合は、正しいモジュール依存関係を指定する必要があります。詳細は、 「ロギング依存関係の変更」を参照してください。
3. モジュラークラスローディングの変更により、EAR または WAR のパッケージ構造を変更しなければならない場合があります。詳細は、 「EAR と WAR のパッケージ化の変更」を参照してください。

手順3.1 ResourceBundle プロパティーの場所の変更

1. WAR アーカイブをデプロイする場合は、これらのプロパティーを WAR の WEB-INF/classes/ フォルダーにパッケージ化する必要があります。
2. これらのプロパティーを EAR のすべてのコンポーネントで利用できるようにしたい場合は、JAR のルートにパッケージ化してから JAR を EAR の lib/ フォルダーに配置する必要があります。

手順3.2 カスタムモジュールの作成

1. module/ ディレクトリー構造を作成し、反映させます。
   1. EAP_HOME/module ディレクトリーにディレクトリー構造を作成し、ファイルと JAR が含まれるようにします。以下に例を示します。

      $ cd EAP_HOME/modules/ 
      $ mkdir -p myorg-conf/main/properties

   2. プロパティーファイルを、前のステップで作成した EAP_HOME/modules/myorg-conf/main/properties/ ディレクトリーに移動します。
   3. EAP_HOME/modules/myorg-conf/main/ ディレクトリーに、以下の XML が含まれる module.xml ファイルを作成します。

      <module xmlns="urn:jboss:module:1.1" name="myorg-conf">
          <resources>
              <resource-root path="properties"/>
          </resources>
      </module>

2. サーバー設定ファイルの ee サブシステムを変更します。管理 CLI を使用するか、ファイルを手動で編集できます。
   • 管理 CLI を使用してサーバー設定ファイルを変更するには、以下の手順に従います。
     1. サーバーを起動し、管理 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

     2. ee サブシステムで myorg-conf <global-modules> 要素を作成するには、コマンドラインで以下を入力します。

        /subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])

        以下の結果が表示されるはずです。

        {"outcome" => "success"}

   • サーバー設定ファイルを手作業で編集する場合は、次の手順に従ってください。
     1. サーバーを停止し、サーバー設定ファイルをテキストエディターで開きます。スタンドアロンサーバーを実行している場合は、これは EAP_HOME/standalone/configuration/standalone.xml ファイルで、管理対象ドメインを実行している場合は EAP_HOME/domain/configuration/domain.xml ファイルになります。
     2. ee サブシステムを見つけ、myorg-conf のグローバルモジュールを追加します。以下は、myorg-conf 要素が含まれるように変更された ee サブシステム要素の例になります。

        例3.1 myorg-conf 要素

        <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
            <global-modules>
                <module name="myorg-conf" slot="main" />            
            </global-modules>
        </subsystem>

3. my.properties という名前のファイルを正しいモジュールの場所にコピーした場合は、以下のようなコードを使用してプロパティーファイルをロードできるようになります。

   例3.2 プロパティーファイルの読み込み

   Thread.currentThread().getContextClassLoader().getResource("my.properties");

手順3.3 アプリケーションのロギングコードの更新

1. 「サードパーティーロギングフレームワーク用のアプリケーションコードの更新」
2. 「新しい JBoss ロギングフレームワークを使用するためのコード変更」

手順3.4 log4j.properties または log4j.xml ファイルを使用する JBoss EAP 6 を設定

1. 以下の内容で 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>
   

2. WAR をデプロイする場合は META-INF/ ディレクトリーまたは WEB-INF/ ディレクトリーに、EAR をデプロイする場合は META-INF/ ディレクトリーに、それぞれ jboss-deployment-structure.xml ファイルを配置します。デプロイメントに依存する子デプロイメントが含まれる場合は、それぞれのサブデプロイメントについてもモジュールを除外する必要があります。
3. EAR の lib/ ディレクトリーまたは WAR デプロイメントの WEB-INF/classes/ ディレクトリーに、それぞれ log4j.properties または log4j.xml ファイルを追加します。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>
   

4. 以下のランタイム引数を使用して JBoss EAP 6 サーバーを起動します。これにより、アプリケーションのデプロイメント時に ClassCastException がコンソールに表示されなくなります。

   -Dorg.jboss.as.logging.per-deployment=false

5. アプリケーションをデプロイします。

手順3.5 JBoss EAP 6.3 以降のロギング依存関係の設定

1. 以下のランタイム引数を使用して JBoss EAP 6 サーバーを起動します。これにより、アプリケーションのデプロイメント時に ClassCastException がコンソールに表示されなくなります。

   -Dorg.jboss.as.logging.per-deployment=false

2. ターミナルを開き、管理 CLI に接続します。
   • Linux の場合は、コマンドラインで以下を入力します。

     $ EAP_HOME/bin/jboss-cli.sh --connect
     

   • Windows の場合は、コマンドラインで以下を入力します。

     C:\>EAP_HOME\bin\jboss-cli.bat --connect
     

3. logging サブシステムの 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>
   

4. アプリケーションをデプロイします。

手順3.6 JBoss ロギングフレームワークを使用するためのコードと依存関係の変更

1. インポートとロギングコードを変更します。
   新しい 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);
   }
   

2. ロギング依存関係を追加します。
   JBoss Logging クラスが含まれる JAR は、org.jboss.logging という名前のモジュールにあります。MANIFEST-MF ファイルは以下のようになるはずです。

   Manifest-Version: 1.0
   Dependencies: org.jboss.logging
   

   モジュール依存関係を探す方法は、「クラスローディングの変更によるアプリケーション依存関係の更新」 および 「移行の問題のデバッグおよび解決」 を参照してください。

手順3.7 アーカイブパッケージの変更

1. WAR をパッケージ化します。
   WAR は 1 つのモジュールで、WAR のすべてのクラスは、同じクラスローダーで読み込まれます。つまり、WEB-INF/lib ディレクトリーにパッケージ化されたクラスは WEB-INF/classes ディレクトリーにあるクラスと同じように処理されます。
2. 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 内の他のサブデプロイメントに属するクラスを参照できます。
   クラスローディングに関する詳細は、JBoss EAP 6 の 『Development Guide』 の『Class Loading and Modules』の章を参照してください (https://access.redhat.com/documentation/ja-jp/red_hat_jboss_enterprise_application_platform/?version=6.4)。

1. アプリケーションがデータソースを使用する場合は、 「DataSource設定の更新」 を参照してください。
2. アプリケーションが JPA を使用し、現在 Hibernate JAR をバンドルしている場合は、移行オプションについて 「Hibernate または JPA のデータソースの設定」 を参照してください。
3. アプリケーションがリソースアダプターを使用する場合は、 「リソースアダプター設定の更新」 を参照してください。
4. 基本的なセキュリティーの変更の設定方法に関する情報は、 「アプリケーションセキュリティーの変更の設定」 を参照してください。

手順3.8 JDBC ドライバーのインストールおよび設定

1. JDBC ドライバーをインストールします。
   1. 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 という名前のテキストファイルが含まれます。ドライバーが JDBC 4.0 に準拠していない場合には、以下のいずれかの方法でデプロイ可能にすることができます。

      • java.sql.Driver ファイルを作成し、META-INF/services/ パスの下にある JAR に追加します。このファイルにはドライバークラス名が含まれている必要があります。以下に例を示します。

        com.mysql.jdbc.Driver

      • デプロイメントディレクトリーに 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/ ディレクトリーにオーバーレイする必要があります。
   2. JDBC ドライバーをコアモジュールとしてインストールします。
      JDBC ドライバーをコアモジュールとしてインストールするには、EAP_HOME/modules/ ディレクトリーにファイルパス構造を作成する必要があります。この構造には、JDBC ドライバー JAR、追加のベンダーライセンスまたはローカリゼーション JAR、およびモジュールを定義する module.xml ファイルが含まれます。
      • コアモジュールとしてのMySQL JDBC ドライバーのインストール
        1. ディレクトリー構造 EAP_HOME/modules/com/mysql/main/を作成します。
        2. 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」エラーが表示されます。
        3. 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 を必要とするドライバーをデプロイする方法を説明するためにのみ提供されています。
        1. ディレクトリー構造 EAP_HOME/modules/com/ibm/db2/main/ を作成します。
        2. 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」エラーが表示されます。
        3. 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/

      このアプローチの利点は以下のとおりです。

      • これは、JDBC ドライバーが複数の JAR で構成される場合に機能する唯一の方法です。
      • この方法では、JDBC 4.0 に準拠していないドライバーを、ドライバー JAR を変更したり、ファイルオーバーレイを作成したりせずにインストールできます。

      このアプローチの短所は以下のとおりです。

      • モジュールの設定がより困難です。
      • モジュールは、管理対象ドメインで実行されているすべてのサーバーに手動でコピーする必要があります。
2. データソースを設定します。
   1. データベースドライバーを追加します。
      同じファイルの <drivers> 要素に <driver> 要素を追加します。ここでも、これには *-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 に準拠していないドライバーでは、ドライバークラス名を指定する META-INF/services/java.sql.Driver ファイルがないため、ドライバークラスを識別する <driver-class> 属性が必要です。以下は、JDBC 4.0 に準拠していないドライバーのドライバー要素の例です。

      <driver name="mysql-connector-java-5.1.15.jar" module="com.mysql">
      <driver-class>com.mysql.jdbc.Driver</driver-class></driver>
      

   2. データソースを作成します。
      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>
      

3. アプリケーションコードの JNDI 参照を更新します。
   定義した新しい JNDI 標準データソース名を使用するには、アプリケーションのソースコードの古い JNDI ルックアップ名を置き換える必要があります。詳細は、 「新しい JNDI 名前空間ルールに従うようにアプリケーションを変更」 を参照してください。
   新しい JNDI 名を使用するには、データソースにアクセスする既存の @Resource アノテーションも置き換える必要があります。以下に例を示します。

   @Resource(name = "java:/YourDatasourceName").
   

手順3.9 Hibernate バンドルの削除

1. アプリケーションライブラリーフォルダーから Hibernate JAR を削除します。
2. persistence.xml ファイルの <hibernate.transaction.manager_lookup_class> 要素は必要ないため、この要素を削除またはコメントアウトします。

手順3.10 Cached Connection Managerの有効化

1. <use-ccm="true" を設定して、サーバー設定ファイルの datasources サブシステムで CCM を有効にします。これはデフォルト値であり、明示的に設定する必要はありません。

   <subsystem xmlns="urn:jboss:domain:datasources:1.2">
     <datasources>
       <datasource ... enabled="true" use-ccm="true">
         ...
       </datasource>
     </datasources>
   </subsystem>

2. <cached-connection-manager> がサーバー設定ファイルの jca サブシステムに存在することを確認します。debug 属性を true に設定します。

   <subsystem xmlns="urn:jboss:domain:jca:1.1">
     ...
     <cached-connection-manager debug="true" error="true"/>
     ...
   </subsystem>

   debug="true" を設定すると、以下が発生します。

   • "Closing a connection for you. Please close them yourself"というメッセージと共に、INFOメッセージがログに記録されます。
   • リークした接続を開いたコード用にスタックトレースが生成されます。
   • リークした接続が閉じられます。

   追加のプロパティー error="true" を使用すると、RuntimeException を発生させ、ログに ERROR メッセージを生成できます。
3. デバッグを有効にすることは、パフォーマンスおよびログファイルのサイズに影響を及ぼすため、テスト時のみを使用することが推奨されます。リークが残っていないことを確認してから、アプリケーションを実稼働環境にデプロイする前に、debug="true" 設定を削除するか、<cached-connection-manager debug="false"/> を使用して、設定を元に戻します。

手順3.11 Cached Connection Manager によって報告されないリークのデバッグ

1. サーバー設定ファイルの datasource サブシステムに use-ccm="false"が設定されていないことを確認します。
2. サーバー設定ファイルの datasource サブシステムに jta="false"が設定されていないことを確認します。
3. org.jboss.jca では、最小ロギングレベルが INFO に設定されていることを確認します。

手順3.12 追加の承認チェックの無効化

• 以下の方法のいずれかを使用して、追加の承認チェックを無効にし、既存の PicketLink デプロイメントを引き続き使用できます。
  • システム全体のプロパティーを設定します。
    org.jboss.ws.cxf.disableHandlerAuthChecks システムプロパティーの値を true に設定すると、サーバーレベルで追加の承認チェックを無効にできます。この方法は、アプリケーションサーバーに加えられたすべてのデプロイメントに影響します。
    システムプロパティーの設定方法は、JBoss EAPの『Administration and Configuration Guide』の『Configure System Properties Using the Management CLI』というトピックを参照してください。
  • デプロイメントの Web サービス記述子ファイルにプロパティーを作成します。
    jboss-webservices.xml ファイルで org.jboss.ws.cxf.disableHandlerAuthChecks プロパティーの値を true に設定すると、デプロイメントレベルで追加の承認チェックを無効にできます。この方法は、特定のデプロイメントにのみ影響します。
    1. 追加の承認チェックを無効にするデプロイメントの META-INF/ ディレクトリーに jboss-webservices.xml ファイルを作成します。
    2. 以下の内容を追加します。

       <?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>

手順3.13 JNDI ルックアップの変更

1. 以下について詳しく確認する 「移植可能な EJB JNDI 名」
2. 「JNDI 名前空間ルールの確認」
3. 「新しい JNDI 名前空間ルールに従うようにアプリケーションを変更」

手順3.14 アプリケーションの設定

1. 必要な Hibernate 3 JAR をアプリケーションライブラリーにコピーします。
   不足しているクラスが含まれる特定の Hibernate 3 JAR をアプリケーションの lib/ ディレクトリーにコピーするか、他の方法を使用してクラスパスに追加して、問題を解決できる場合があります。これにより、Hibernate バージョンの混合使用が原因で ClassCastExceptions やその他のクラスローディングの問題が発生することがあります。その場合には、次の方法を使用する必要があります。
2. Hibernate 3 ライブラリーのみを使用するようにサーバーに指示します。
   JBoss EAP 6 では、アプリケーションで Hibernate 3.5（またはそれ以降）の永続プロバイダー jar をパッケージ化できます。Hibernate 3 ライブラリーのみを使用し、Hibernate 4 ライブラリーを除外するようにサーバーに指示するには、以下のように persistence.xml の jboss.as.jpa.providerModule を hibernate3-bundled に設定する必要があります。

   <?xml version="1.0" encoding="UTF-8"?>
   <persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
       <persistence-unit name="plannerdatasource_pu">
           <description>Hibernate 3 Persistence Unit.</description>
           <jta-data-source>java:jboss/datasources/PlannerDS</jta-data-source>
           <properties>
               <property name="hibernate.show_sql" value="false" />
               <property name="jboss.as.jpa.providerModule" value="hibernate3-bundled" />
           </properties>
       </persistence-unit>
   </persistence>
   

   Java Persistence API (JPA)デプロイヤーは、アプリケーション内に永続プロバイダーの存在を検出し、Hibernate 3 ライブラリーを使用します。JPA 永続プロパティーの詳細は、 「永続ユニットプロパティー」 を参照してください。
3. Hibernate 二次キャッシュを無効にします。
   Hibernate 3 の 二次キャッシュは、JBoss EAP 6 では以前のリリースと同じようには動作しません。アプリケーションで Hibernate 二次キャッシュを使用している場合は、Hibernate 4 にアップグレードするまで無効にする必要があります。二次キャッシュを無効にするには、persistence.xml ファイルで <hibernate.cache.use_second_level_cache> を false に設定します。
4. org.jboss.ejb3.entity.ExtendedEntityManager への参照を置き換えます。
   JBoss EAP 5 では、拡張永続コンテキスト管理のために org.jboss.ejb3.entity.ExtendedEntityManager クラスが javax.persistence.EntityManager を拡張しました。JBoss EAP 6 では、このクラスは org.jboss.as.jpa.container.ExtendedEntityManager クラスに置き換えられました。ただし、プロプライエタリークラスの代わりに標準の Java EE 6 JPA API javax.persistence.EntityManager クラスを使用するようコードを更新することが推奨されます。

手順3.15 Hibernate 4 を使用するようにアプリケーションを更新

1. JBoss EAP 6 では、自動インクリメントシーケンスジェネレーターのデフォルト動作が変更されました。詳細は、 「Hibernate のアイデンティティー自動生成値に関する既存動作の維持」 を参照してください。
2. アプリケーションによって現在使用されている Hibernate のバージョンを確認し、以下の正しい更新手順を選択します。
   • 「Hibernate 3.3.x アプリケーションの Hibernate 4.x への移行」
   • 「Hibernate 3.5.x アプリケーションの Hibernate 4.x への移行」
3. クラスター環境でアプリケーションを実行する予定の場合には、 「クラスター環境で実行する移行した Seam および Hibernate アプリケーションの永続プロパティーの変更」 を参照してください。

1. Hibernate テキスト タイプは JDBC LONGVARCHARにマッピングされるようになりました。
   3.5 よりも前のバージョンの Hibernate では、テキスト タイプは JDBC CLOB にマッピングされました。新しい Hibernate タイプ materialized_clob が Hibernate 4 に追加され、Java String プロパティーを JDBC CLOB にマッピングします。JDBC CLOB にマッピングすることが意図されたアプリケーションのプロパティーが type="text" として設定されている場合、以下のいずれかを実行する必要があります。
   1. アプリケーションが hbm マッピングファイルを使用する場合は、プロパティーを type="materialized_clob" に変更します。
   2. アプリケーションがアノテーションを使用する場合は、@Type(type = "text") を @Lob に置き換える必要があります。
2. 戻り値タイプの変更を探すコードの確認
   数値集約基準のプロジェクションは、HQL のカウンターパートと同じ値タイプを返すようになりました。その結果、org.hibernate.criterion の以下のプロジェクションからの戻り値の型が変更されました。
   1. CountProjection、Projections.rowCount()、Projections.count(propertyName)、Projections.countDistinct(propertyName) の変更により、count および count distinct プロジェクションは Long 値を返すようになりました。
   2. Projections.sum(propertyName) の変更により、sum プロジェクションはプロパティータイプに依存する値タイプを返すようになりました。

      注記

      アプリケーションコードの変更に失敗すると、java.lang.ClassCastException が発生することがあります。
      1. Long、Short、Integer、またはプリミティブ整数タイプとしてマッピングされたプロパティーの場合、Long 値が返されます。
      2. Float、Double、またはプリミティブ浮動小数点タイプとしてマッピングされたプロパティーの場合は、Double 値が返されます。
3. nullSafeGet() および nullSafeSet() メソッドの UserType 署名を更新します。
   UserType クラスの nullSafeGet() および nullSafeSet() メソッドの署名が Hibernate 4 で変更になりました。これらのメソッドを使用するアプリケーションコードは、新しい署名を使用するように更新する必要があります。
   以下は、Hibernate 3.x のメソッド署名の例です。

   public Object nullSafeGet(ResultSet rs, String[] names, Object owner) 
       throws HibernateException, SQLException;
   
   public void nullSafeSet(PreparedStatement st, Object value, int index) 
       throws HibernateException, SQLException;

   以下は、Hibernate 4 の新しいメソッド署名の例です。

   public Object nullSafeGet(ResultSet rs, String[] names, SessionImplementor session, Object owner) 
       throws HibernateException, SQLException;
   
   public void nullSafeSet(PreparedStatement st, Object value, int index, SessionImplementor session) 
       throws HibernateException, SQLException;

1. AnnotationConfiguration が Configurationにマージされました。
   AnnotationConfiguration は非推奨になりましたが、移行には影響しません。
   1. hbm.xml ファイルをまだ使用している場合は、JBoss EAP 6 では、以前のリリースで使用されていた org.hibernate.cfg.DefaultNamingStrategy ではなく、AnnotationConfiguration の org.hibernate.cfg.EJB3NamingStrategy が使用されるようになったことに注意してください。これにより、命名が一致しなくなる可能性があります。
   2. 関連付け（多対多および要素のコレクション）表の名前のデフォルト設定を命名ストラテジーに依存している場合、この問題が発生する可能性があります。この問題を解決するには、Configuration#setNamingStrategy を呼び出して org.hibernate.cfg.DefaultNamingStrategy#INSTANCE に渡すことで、レガシー org.hibernate.cfg.DefaultNamingStrategy を使用するように Hibernate に指示できます。
2. 以下の表にあるように、新しい Hibernate DTD ファイル名に準拠するように名前空間を変更します。

   表3.5 DTD 名前空間マッピングテーブル

   以前の DTD 名前空間	新しい DTD 名前空間
   http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd	http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd
   http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd	http://www.hibernate.org/dtd/hibernate-mapping-3.0.dtd

3. 環境変数を変更します。
   1. Oracle を使用し、materialized_clob または materialized_blob プロパティーを使用している場合は、グローバル環境変数 hibernate.jdbc.use_streams_for_binary を true に設定する必要があります。
   2. PostgreSQL を使用し、CLOB または BLOB プロパティーを使用している場合は、グローバル環境変数 hibernate.jdbc.use_streams_for_binary を false に設定する必要があります。
4. nullSafeGet() および nullSafeSet() メソッドの UserType 署名を更新します。
   UserType クラスの nullSafeGet() および nullSafeSet() メソッドの署名が Hibernate 4 で変更になりました。これらのメソッドを使用するアプリケーションコードは、新しい署名を使用するように更新する必要があります。詳細は、 「Hibernate 3.3.x アプリケーションの Hibernate 4.x への移行」 を参照してください。

手順3.16 クラスター環境で実行するための永続プロパティーの設定

1. hibernate.session_factory_name の値を一意の名前に設定します。この名前は、JBoss EAP 6 インスタンス上のすべてのアプリケーションデプロイメントで一意である必要があります。以下に例を示します。

   <property name="hibernate.session_factory_name" value="jboss-seam-booking.ear_session_factory"/>
   

2. hibernate.ejb.entitymanager_factory_name の値を一意の名前に設定します。この名前は、JBoss EAP 6 インスタンス上のすべてのアプリケーションデプロイメントで一意である必要があります。以下に例を示します。

   <property name="hibernate.ejb.entitymanager_factory_name" value="seam-booking.ear_PersistenceUnitName"/>
   

手順3.17 Infinispan を使用するように persistence.xml ファイルを変更します。

1. JBoss EAP 6 での JPA アプリケーション用 Infinispan の設定
   以下は、JBoss EAP 6 で Infinispan を使用して JPA アプリケーション用に同じ設定を実現するためにプロパティーを指定する方法の例です。

   <property name="hibernate.cache.use_second_level_cache" value="true"/>
   

   さらに、以下のように ENABLE_SELECTIVE または ALL の値で shared-cache-mode を指定する必要があります。
   • ENABLE_SELECTIVE はデフォルト値であり、推奨される値です。つまり、エンティティーを明示的にキャッシュ可能としてマークしない限り、エンティティーはキャッシュされません。

     <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
     

   • ALL は、エンティティーをキャッシュ可能ではないとマークしても常にキャッシュされることを意味します。

     <shared-cache-mode>ALL</shared-cache-mode>
     

2. JBoss EAP 6 でのネイティブ Hibernate アプリケーション用 Infinispan の設定
   以下は、JBoss EAP 6 で Infinispan を使用してネイティブ Hibernate アプリケーション用に同じ設定を指定する方法の例です。

   <property name="hibernate.cache.region.factory_class"
        value="org.jboss.as.jpa.hibernate4.infinispan.InfinispanRegionFactory"/>
   <property name="hibernate.cache.infinispan.cachemanager"
        value="java:jboss/infinispan/container/hibernate"/>     
   <property name="hibernate.transaction.jta.platform"
        value="org.hibernate.service.jta.platform.internal.JBossAppServerJtaPlatform"/>
   <property name="hibernate.cache.use_second_level_cache" value="true"/>
   
   

   MANIFEST.MF ファイルに以下の依存関係も追加する必要があります。

   Manifest-Version: 1.0
   Dependencies: org.infinispan, org.hibernate
   

手順3.18 以下のタスクの 1 つまたは複数を実行する必要がある場合があります。

1. デフォルトの ValidatorFactory へのアクセス
   JBoss EAP 6 は、デフォルトの ValidatorFactory を java:comp/ValidatorFactory という名前のセクションの JNDI コンテキストにバインドします。
2. ライフサイクルによりトリガーされる検証について
   Hibernate Core 4 と組み合わせて使用すると、ライフサイクルベースの検証は Hibernate Core によって自動的に有効になります。
   1. 検証は、エンティティーの INSERT、UPDATE、DELETE 操作で実行されます。
   2. 以下のプロパティーを使用して、イベントタイプで検証するようにグループを設定できます。

      • javax.persistence.validation.group.pre-persist、
      • javax.persistence.validation.group.pre-update、および
      • javax.persistence.validation.group.pre-remove

      これらのプロパティーの値は、検証するグループの完全修飾クラス名のコンマ区切りリストです。
      検証グループは Bean Validation 仕様の新しい機能です。この新機能を活用しない場合は、Hibernate Validator 4 に移行するときに変更は必要ありません。
   3. javax.persistence.validation.mode プロパティーを none に設定すると、ライフサイクルベースの検証を無効にできます。このプロパティーの他の有効な値は、auto（デフォルト）、callback、および ddl です。
3. 手動検証を使用するようにアプリケーションを設定
   1. 検証を手動で制御するには、以下のいずれかの方法でValidatorを作成します。

      • getValidator() メソッドを使用して ValidatorFactory から Validator インスタンスを作成します。
      • EJB、CDI Bean、またはその他の Java EE の注入可能なリソースにValidatorインスタンスを注入します。
   2. ValidatorFactory.usingContext() によって返される ValidatorContext を使用してValidatorインスタンスをカスタマイズできます。この API を使用すると、カスタム MessageInterpolator、TraverableResolver、および ConstraintValidatorFactory を設定できます。これらのインターフェイスは Bean Validation 仕様で指定され、Hibernate Validator 4 の新機能です。
4. 新しい Bean Validation 制約を使用するためのコードの変更
   Hibernate Validator 4 に移行する際、新しい Bean レベルの検証制約にはコードの変更が必要です。
   1. Hibernate Validator 4 にアップグレードするには、以下のパッケージの制約を使用する必要があります。

      • javax.validation.constraints
      • org.hibernate.validator.constraints
   2. Hibernate Validator 3 に存在していた制約はすべて Hibernate Validator 4 で引き続き利用できます。これらを使用するには、指定のクラスをインポートする必要があり、場合によっては、制約パラメーターの名前またはタイプを変更します。
5. カスタム制約の使用
   Hibernate Validator 3 では、org.hibernate.validator.Validator インターフェイスを実装するのにカスタム制約が必要でした。Hibernate Validator 4 では、javax.validation.ConstraintValidator インターフェイスを実装する必要があります。このインターフェイスには、以前のインターフェイスと同じ initialize() メソッドおよび isValid() メソッドが含まれますが、メソッドの署名が変更されました。さらに、Hibernate Validator 4 では DDL の変更に対応しなくなりました。
6. 以下の Hibernate 3.x Validator クラスは廃止されました。
   1. org.hibernate.validator.NotNull を javax.validation.constraints.NotNull に置き換えます。
   2. org.hibernate.validator.ClassValidator を javax.validation.Validator. に置き換えます。
   3. org.hibernate.validator.InvalidValue を javax.validation.Validator. に置き換えます。
   詳細は、『Hibernate Valitator Reference Guide』を参照してください。
7. jboss-ejb3-ext-api-VERSION.jar ファイルでは、多くのアノテーションエクステンション API が削除されました。JBoss EAP 6 では必要なくなったためです。たとえば、JBoss EAP 6 は相互互換性を自動的に処理するため、org.jboss.ejb3.annotation.IgnoreDependency クラスは利用できないか、または不要になりました。

手順3.19 Axis を使用するための JBoss EAP の設定

1. 最初に、JBoss EAP 6 に同梱される web サービス実装を無効にする必要があります。詳細な手順は、 「JBoss EAP 6 での JBossWS の無効化」 を参照してください。
2. アプリケーションを再ビルドし、デプロイします。Axis WS API 実装が Java EE 6 API クラスに正しくアクセスされるはずです。

手順3.20 単一デプロイメントでの JBossWS の無効化

1. アプリケーション用の jboss-deployment-structure.xml ファイルを作成します。
   • アプリケーションが WAR としてパッケージ化されてデプロイされている場合は、以下の内容で WAR の META-INF/ または WEB-INF/ ディレクトリーに、jboss-deployment-structure.xml ファイルを作成します。

     <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
       <deployment>
         <!-- Exclude webservices subsystem so the implicit dependencies will not be added -->
          <exclude-subsystems>
             <subsystem name="webservices"/>
         </exclude-subsystems>
       </deployment>
     </jboss-deployment-structure>

   • アプリケーションが EAR でパッケージ化されてデプロイされている場合は、以下の例のような内容で EAR の META-INF/ ディレクトリーに jboss-deployment-structure.xml ファイルを作成します。

     <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
       ...
       <sub-deployment name="example.war">
         <!-- Exclude webservices subsystem so the implicit dependencies will not be added -->
          <exclude-subsystems>
             <subsystem name="webservices"/>
         </exclude-subsystems>
         <dependencies>
            ...
         </dependencies>
       </sub-deployment>
     </jboss-deployment-structure>
     

2. 通常の方法でアプリケーションをデプロイします。JBossWS がアプリケーションで無効になりました。

手順3.21 サーバーに対する全デプロイメントでの JBossWS の無効化

1. JBoss EAP サーバーを停止します。
2. 編集するため、サーバー設定ファイルを開きます。スタンドアロンサーバーの場合には、これは EAP_HOME/standalone/configuration/standalone.xml ファイルです。管理対象ドメインの場合には、これは EAP_HOME/domain/configuration/domain.xml ファイルです。
3. org.jboss.as.webservices 拡張を見つけ、コメントアウトまたは削除します。
4. webservices サブシステムプロファイルを見つけ、コメントアウトまたは削除します。
5. 以下は、standalone.xml ファイルに加えられた変更の例になります。

   <?xml version='1.0' encoding='UTF-8'?>
   <server xmlns="urn:jboss:domain:1.7">
     <extensions>
          ...
       <!-- <extension module="org.jboss.as.webservices"/> -->
          ...
     </extensions>
     ...
     <profile>
       <!--
       <subsystem xmlns="urn:jboss:domain:webservices:1.2">
         <modify-wsdl-address>true</modify-wsdl-address>
         <wsdl-host>${jboss.bind.address:127.0.0.1}</wsdl-host>
         <endpoint-config name="Standard-Endpoint-Config"/>
         <endpoint-config name="Recording-Endpoint-Config">
           <pre-handler-chain name="recording-handlers" protocol-bindings="##SOAP11_HTTP ##SOAP11_HTTP_MTOM ##SOAP12_HTTP ##SOAP12_HTTP_MTOM">
   	       <handler name="RecordingHandler" class="org.jboss.ws.common.invocation.RecordingServerHandler"/>
           </pre-handler-chain>
         </endpoint-config>
       	<client-config name="Standard-Client-Config"/>
     	</subsystem>
       -->
     ...
     </profile>
     ...
   </server>

手順3.22 JMS ブリッジの作成

1. ソース JBoss EAP 5.x サーバーでのブリッジの設定
   リリース間のクラスで競合を回避するには、以下の手順にしたがって JBoss EAP 5.x で JMS ブリッジを設定する必要があります。SAR ディレクトリーおよびブリッジの名前は任意であり、必要に応じて変更できます。
   1. SAR を含む JBoss EAP 5 デプロイメントディレクトリーにサブディレクトリーを作成します（例： EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/）。
   2. EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/ に META-INF という名前のサブディレクトリーを作成します。
   3. EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/META-INF/ ディレクトリーに jboss-service.xml ファイルを作成します。以下の例のような情報が含まれるはずです。

      <server>
         <loader-repository>
            com.example:archive=unique-archive-name
            <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
         </loader-repository> 
      
         <!-- JBoss EAP 6 JMS Provider --> 
         <mbean code="org.jboss.jms.jndi.JMSProviderLoader" name="jboss.messaging:service=JMSProviderLoader,name=EnterpriseApplicationPlatform6JMSProvider">
            <attribute name="ProviderName">EnterpriseApplicationPlatform6JMSProvider</attribute>
            <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
            <attribute name="FactoryRef">jms/RemoteConnectionFactory</attribute> 
            <attribute name="QueueFactoryRef">jms/RemoteConnectionFactory</attribute>  
            <attribute name="TopicFactoryRef">jms/RemoteConnectionFactory</attribute>      
            <attribute name="Properties">
               java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
               java.naming.provider.url=remote://EnterpriseApplicationPlatform6host:4447
               java.naming.security.principal=jbossuser
               java.naming.security.credentials=jbosspass
            </attribute>
         </mbean> 
      
         <mbean code="org.jboss.jms.server.bridge.BridgeService" name="jboss.jms:service=Bridge,name=MyBridgeName" xmbean-dd="xmdesc/Bridge-xmbean.xml">      
            <depends optional-attribute-name="SourceProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>          
            <depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=EnterpriseApplicationPlatform6JMSProvider</depends>          
            <attribute name="SourceDestinationLookup">/queue/A</attribute>      
            <attribute name="TargetDestinationLookup">jms/queue/test</attribute>       
            <attribute name="QualityOfServiceMode">1</attribute>           
            <attribute name="MaxBatchSize">1</attribute>      
            <attribute name="MaxBatchTime">-1</attribute>           
            <attribute name="FailureRetryInterval">60000</attribute>      
            <attribute name="MaxRetries">-1</attribute>      
            <attribute name="AddMessageIDInHeader">false</attribute>
            <attribute name="TargetUsername">jbossuser</attribute>
            <attribute name="TargetPassword">jbosspass</attribute>
         </mbean>
      </server>
      
      

      注記

      SAR に分離されたクラスローダーが含まれるように、load-repository 要素が存在します。また、JNDI ルックアップとブリッジターゲットの両方に、パスワードが jbosspass のユーザー jbossuser のセキュリティークレデンシャルが含まれていることに注意してください。これは、JBoss EAP 6 はデフォルトでセキュアであるためです。パスワード「jbosspass」のユーザー「jbosspass」が、EAP_HOME/bin/add_user.sh スクリプトを使用して guest ロールで、ApplicationRealm に作成されました。
   4. 以下の JAR を EAP_HOME/modules/system/layers/base/ ディレクトリーから EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/ ディレクトリーにコピーします。各 VERSION_NUMBER は、JBoss EAP 6 ディストリビューションの実際のバージョン番号に置き換えます。

      • org/hornetq/main/hornetq-core-VERSION_NUMBER.jar
      • org/hornetq/main/hornetq-jms-VERSION_NUMBER.jar
      • org/jboss/ejb-client/main/jboss-ejb-client-VERSION_NUMBER.jar
      • org/jboss/logging/main/jboss-logging-VERSION_NUMBER.jar
      • org/jboss/logmanager/main/jboss-logmanager-VERSION_NUMBER.jar
      • org/jboss/marshalling/main/jboss-marshalling-VERSION_NUMBER.jar
      • org/jboss/marshalling/river/main/jboss-marshalling-river-VERSION_NUMBER.jar
      • org/jboss/remote-naming/main/jboss-remote-naming-VERSION_NUMBER.jar
      • org/jboss/remoting3/main/jboss-remoting-VERSION_NUMBER.jar
      • org/jboss/sasl/main/jboss-sasl-VERSION_NUMBER.jar
      • org/jboss/netty/main/netty-VERSION_NUMBER.jar
      • org/jboss/remoting3/remote-jmx/main/remoting-jmx-VERSION_NUMBER.jar
      • org/jboss/xnio/main/xnio-api-VERSION_NUMBER.jar
      • org/jboss/xnio/nio/main.xnio-nio-VERSION_NUMBER.jar
      注記

      javax API クラスは JBoss EAP 5.x のクラスと競合するため、EAP_HOME/bin/client/jboss-client.jar は単純にコピーしないでください。
2. 宛先 JBoss EAP 6 サーバー上のブリッジの設定
   JBoss EAP 6.1 以降では、JMS ブリッジを使用して JMS 1.1 準拠のサーバーからメッセージをブリッジできます。ソースおよびターゲットの JMS リソースは JNDI を使用してルックアップされるため、ソースメッセージングプロバイダーまたはメッセージブローカーの JNDI ルックアップクラスを JBoss モジュールにバンドルする必要があります。次の手順では、架空の MyCustomMQ メッセージブローカーを例として使用します。
   1. メッセージプロバイダーの JBoss モジュールを作成します。
      1. 新しいモジュールの EAP_HOME/modules/system/layers/base/ の下にディレクトリー構造を作成します。main/ サブディレクトリーには、クライアント JAR および module.xml ファイルが含まれます。MyCustomMQ メッセージングプロバイダー用に作成されたディレクトリー構造の例: EAP_HOME/modules/system/layers/base/org/mycustommq/main/
      2. main/ サブディレクトリーで、メッセージングプロバイダーのモジュール定義が含まれる module.xml ファイルを作成します。MyCustomMQ メッセージングプロバイダー用に作成された module.xml の例を以下に示します。

         <?xml version="1.0" encoding="UTF-8"?>
         <module xmlns="urn:jboss:module:1.1" name="org.mycustommq">
             <properties>
                 <property name="jboss.api" value="private"/>
             </properties> 
         
             <resources>
                 <!-- Insert resources required to connect to the source or target   -->
                 <resource-root path="mycustommq-1.2.3.jar" />
                 <resource-root path="mylogapi-0.0.1.jar" />
             </resources> 
         
             <dependencies>
                <!-- Add the dependencies required by JMS Bridge code                 -->
                <module name="javax.api" />
                <module name="javax.jms.api" />
                <module name="javax.transaction.api"/>
                <!-- Add a dependency on the org.hornetq module since we send         -->
                <!-- messages tothe HornetQ server embedded in the local EAP instance -->
                <module name="org.hornetq" />
             </dependencies>
         </module>
         

      3. ソースリソースの JNDI ルックアップに必要なメッセージングプロバイダー JAR をモジュールの main/ サブディレクトリーにコピーします。MyCustomMQ モジュールのディレクトリー構造は以下のようになります。

         modules/
         `-- system
             `-- layers
                 `-- base
                     `-- org
                           `-- mycustommq
                               `-- main
                                   |-- mycustommq-1.2.3.jar
                                   |-- mylogapi-0.0.1.jar
                                   |-- module.xml
         

   2. JBoss EAP 6 サーバーの messaging サブシステムで JMS ブリッジを設定します。
      1. 開始する前に、サーバーを停止し、現在のサーバー設定ファイルをバックアップします。スタンドアロンサーバーを実行している場合は、これは EAP_HOME/standalone/configuration/standalone-full-ha.xml ファイルです。管理対象ドメインを実行している場合は、EAP_HOME/domain/configuration/domain.xml ファイルと EAP_HOME/domain/configuration/host.xml ファイルの両方をバックアップします。
      2. jms-bridge 要素をサーバー設定ファイルの messaging サブシステムに追加します。source 要素および target 要素は、JNDI ルックアップに使用される JMS リソースの名前を提供します。ユーザー と パスワード の認証情報が指定されている場合は、JMS 接続の作成時に引数として渡されます。
         MyCustomMQ メッセージングプロバイダーに設定された jms-bridge 要素の例を以下に示します。

         <subsystem xmlns="urn:jboss:domain:messaging:1.3">
            ...
            <jms-bridge name="myBridge" module="org.mycustommq">
               <source>
                  <connection-factory name="ConnectionFactory"/>
                  <destination name="sourceQ"/>
                  <user>user1</user>
                  <password>pwd1</password>
                  <context>
                     <property key="java.naming.factory.initial" value="org.mycustommq.jndi.MyCustomMQInitialContextFactory"/>
                     <property key="java.naming.provider.url"    value="tcp://127.0.0.1:9292"/>
                  </context>
               </source>
               <target>
                  <connection-factory name="java:/ConnectionFactory"/>
                  <destination name="/jms/targetQ"/>
               </target>
               <quality-of-service>DUPLICATES_OK</quality-of-service>
               <failure-retry-interval>500</failure-retry-interval>
               <max-retries>1</max-retries>
               <max-batch-size>500</max-batch-size>
               <max-batch-time>500</max-batch-time>
               <add-messageID-in-header>true</add-messageID-in-header>
            </jms-bridge>
         </subsystem>
         

         上記の例では、JNDI プロパティーは ソース の コンテキスト 要素で定義されています。上記の target の例のように、context 要素を省略すると、JMS リソースはローカルインスタンスでルックアップされます。

手順3.23 プロバイダーを HornetQ に変更します。

1. 設定を転送します。
   既存の JBoss Messaging 設定を JBoss EAP 6 設定に転送します。以下の設定は、JBoss Messaging サーバー上のデプロイメント記述子にあります。
   • 接続ファクトリーサービスの設定
     この設定では、JBoss Messaging サーバーでデプロイされた JMS 接続ファクトリーを記述します。JBoss Messaging は、アプリケーションサーバーのデプロイメントディレクトリーにある connection-factories-service.xml という名前のファイルに接続ファクトリーを設定します。
   • 宛先設定
     この設定では、JBoss Messaging サーバーでデプロイされた JMS キューとトピックについて記述します。デフォルトでは、JBoss Messaging は、アプリケーションサーバーのデプロイメントディレクトリーにある destinations-service.xml という名前のファイルに宛先を設定します。
   • メッセージブリッジサービスの設定
     この設定には、JBoss Messaging サーバーでデプロイされたブリッジサービスが含まれます。デフォルトではブリッジはデプロイされないため、デプロイメントファイルの名前は JBoss Messaging のインストールによって異なります。
2. アプリケーションコードを変更します。
   アプリケーションコードで標準の JMS を使用する場合は、コードの変更は必要ありません。ただし、 「移植可能な EJB JNDI 名」 セクションで説明されているように、新しい標準化された JNDI 名前空間を使用するため、アプリケーションを変更する必要があります。アプリケーションが JBoss Messaging 固有の機能を使用する場合は、HornetQ で利用可能な同等の機能を使用するように、コードを変更する必要があります。
   以下は、InitialContext を作成し、JBoss EAP 6 でキューを検索する JMS クライアントの例です。

   Hashtable<String, String> env = new Hashtable<String, String>();
   String providerUrl = "remote:" + host + ":" + port;
   env.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
   env.put("java.naming.factory.initial", "org.jboss.naming.remote.client.InitialContextFactory");
   env.put("java.naming.provider.url", providerUrl);
   env.put(Context.SECURITY_PRINCIPAL, user);
   env.put(Context.SECURITY_CREDENTIALS, pass);
   InitialContext context = new InitialContext(env);
   Queue myTestQueue = (Queue) context.lookup("jms/queue/myTestQueue");
   

   アプリケーションがクラスターに接続する場合は、クラスタリングセマンティクスで HornetQ のドキュメントを慎重に確認する必要があります。クラスタリングは JMS 仕様の範囲外で、HornetQ と JBoss Messaging はクラスタリング機能の実装ごとに大きく異なるアプローチをとっていました。
   HornetQ でメッセージングを設定する方法は、以下を参照してください。 「HornetQ でのメッセージングの設定」
3. 既存のメッセージを移行します。
   JMS ブリッジを使用して、JBoss Messaging データベースのメッセージを HornetQ ジャーナルに移動します。JMS ブリッジの設定手順は、 「既存の JMS メッセージを JBoss EAP 6 に移行するような JMS ブリッジの設定」 を参照してください。

1. クラスタリングが有効な状態で JBoss EAP 6 を起動

   JBoss EAP 5.x でクラスタリングを有効にするには、all プロファイルまたはその派生を使用してサーバーインスタンスを起動する必要があります。

   $ EAP5_HOME/bin/run.sh -c all

   JBoss EAP 6 では、クラスタリングを有効にする方法は、サーバーがスタンドアロンか、管理対象ドメインで実行されているかによって異なります。

   1. 管理対象ドメインで稼働しているサーバーのクラスター化の有効化

      ドメインコントローラーを使用して起動されたサーバーのクラスター化を有効にするには、domain.xml を更新し、ha プロファイルと ha-sockets ソケットバインディンググループを使用するようにサーバーグループを指定します。以下に例を示します。

      <server-groups>
        <server-group name="main-server-group" profile="ha">
          <jvm name="default">
            <heap size="64m" max-size="512m"/>
          </jvm>
          <socket-binding-group ref="ha-sockets"/>
        </server-group>
      </server-group>

   2. スタンドアロンサーバーのクラスター化の有効化

      スタンドアロンサーバーでクラスター化を有効にするには、以下のように適切な設定ファイルを使用してサーバーを起動します。

      $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME

2. バインドアドレスを指定します。

   JBoss EAP 5.x では、通常、以下のように -b コマンドライン引数を使用してクラスタリングに使用されるバインドアドレスを指定します。

   $ EAP5_HOME/bin/run.sh -c all -b 192.168.0.2

   JBoss EAP 6 は、standalone.xml ファイル、domain.xml ファイル、および host.xml ファイルの <interfaces> 要素に含まれる IP アドレスとインターフェースにソケットをバインドします。JBoss EAP に同梱される標準設定には、2 つのインターフェース設定が含まれています。

   <interfaces>
       <interface name="management">
           <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
       </interface>
       <interface name="public">
          <inet-address value="${jboss.bind.address:127.0.0.1}"/>
       </interface>
   </interfaces>

   これらのインターフェース設定では、システムプロパティー jboss.bind.address.management および jboss.bind.address の値を使用します。これらのシステムプロパティーが設定されていない場合は、デフォルトの 127.0.0.1 が各値に使用されます。
   また、サーバーの起動時にバインドアドレスをコマンドライン引数として指定したり、JBoss EAP 6 サーバー設定ファイル内で明示的に定義したりできます。
   • JBoss EAP スタンドアロンサーバーの起動時にコマンドラインで bind 引数を指定します。
     以下は、スタンドアロンサーバーのコマンドラインでバインドアドレスを指定する方法の例になります。

     EAP_HOME/bin/standalone.sh -Djboss.bind.address=127.0.0.1

     注記

     -b のショートカットである -Djboss.bind.address=127.0.0.1 引数を使用することもできます。

     EAP_HOME/bin/standalone.sh -b=127.0.0.1

     JBoss EAP 5 構文の形式は引き続きサポートされます。

     EAP_HOME/bin/standalone.sh -b 127.0.0.1

     -b 引数は、パブリック インターフェースのみを変更することに注意してください。管理 インターフェースには影響しません。
   • サーバー設定ファイルにバインドアドレスを指定します。
     管理対象ドメインで実行されているサーバーの場合は、domain/configuration/host.xml ファイルにバインドアドレスを指定します。スタンドアロンサーバーの場合は、standalone-ha.xml ファイルにバインドアドレスを指定します。
     以下の例では、public インターフェースは ha-sockets ソケットバインディンググループ内のすべてのソケットのデフォルトインターフェースとして指定されます。

     <interfaces>
       <interface name="management">
         <inet-address value="192.168.0.2"/>
       </interface>
       <interface name="public">
         <inet-address value="192.168.0.2"/>
       </interface>
     </interfaces>

     <socket-binding-groups>
       <socket-binding-group name="ha-sockets" default-interface="public">
         <!-- ... -->
       </socket-binding-group>
     </socket-binding-groups>

     注記

     設定ファイルのシステムプロパティーではなく、ハードコーディングされた値としてバインドアドレスを指定した場合、コマンドラインの引数で上書きすることはできません。

3. mod_jk および mod_proxy をサポートする jvmRoute の設定

   JBoss EAP 5 では、Web サーバー jvmRoute は server.xml ファイルのプロパティーを使用して設定されます。JBoss EAP 6 では、以下のように instance-id 属性を使用してサーバー設定ファイルの web サブシステムに jvmRoute 属性が設定されます。

   <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false" instance-id="{JVM_ROUTE_SERVER}">
   

   上記の {JVM_ROUTE_SERVER} は jvmRoute サーバー ID に置き換える必要があります。
   instance-id は、管理コンソールを使用して設定することもできます。

4. マルチキャストアドレスおよびポートの指定

   JBoss EAP 5.x では、以下のようにコマンドライン引数 -u および -m を使用して、クラスター内通信に使用されるマルチキャストアドレスおよびポートを指定できます。

   $ EAP5_HOME/bin/run.sh -c all -u 228.11.11.11 -m 45688

   JBoss EAP 6 では、クラスター内通信に使用されるマルチキャストアドレスとポートは、以下のように関連する JGroups プロトコルスタックによって参照されるソケットバインディングによって定義されます。

   <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
       <stack name="udp">
           <transport type="UDP" socket-binding="jgroups-udp"/>
           <!-- ... -->
       </stack>
   </subsystem>

   <socket-binding-groups>
       <socket-binding-group name="ha-sockets" default-interface="public">
           <!-- ... -->
           <socket-binding name="jgroups-udp" port="55200" multicast-address="228.11.11.11" multicast-port="45688"/>
           <!-- ... -->
       </socket-binding-group>
   </socket-binding-groups>
   

   コマンドラインでマルチキャストアドレスとポートを指定する場合は、マルチキャストアドレスとポートをシステムプロパティーとして定義し、サーバーの起動時にコマンドラインでこれらのプロパティーを使用できます。以下の例では、 jboss.mcast.addr はマルチキャストアドレスの変数名で、 jboss.mcast.port はポートの変数名です。

   <socket-binding name="jgroups-udp" port="55200"
    multicast-address="${jboss.mcast.addr:230.0.0.4}" multicast-port="${jboss.mcast.port:45688}"/>
   

   次に、以下のコマンドライン引数を使用してサーバーを起動できます。

   $ EAP_HOME/bin/domain.sh -Djboss.mcast.addr=228.11.11.11 -Djboss.mcast.port=45688

5. 別のプロトコルスタックを使用する

   JBoss EAP 5.x では、jboss.default.jgroups.stack システムプロパティーを使用して、すべてのクラスタリングサービスに使用されるデフォルトのプロトコルスタックを操作できます。

   $ EAP5_HOME/bin/run.sh -c all -Djboss.default.jgroups.stack=tcp

   JBoss EAP 6 では、デフォルトのプロトコルスタックは domain.xml または standalone-ha.xml 内の JGroups サブシステムによって定義されます。

   <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
       <stack name="udp">
           <!-- ... -->
       </stack>
   </subsystem>

6. バウンドレプリケーションの置き換え

   JBoss EAP 5.x では JBoss Cache Buddy Replication を使用して、クラスターのすべてのインスタンスへのデータのレプリケーションが抑制されました。
   JBoss EAP 6 では、Buddy Replication は Infinispan の分散キャッシュ（ DIST モードとも呼ばれる）に置き換えられました。Distribution（分散）は強力なクラスタリングモードで、より多くのサーバーがクラスターに追加されるため、Infinispan は直線的にスケーリングできます。以下は、DIST キャッシュモードを使用するようにサーバーを設定する方法の例になります。
   1. コマンドラインを開き、HA または Full Profile のいずれかでサーバーを起動します。以下に例を示します。

      EAP_HOME/bin/standalone.sh -c standalone-ha.xml

   2. 別のコマンドラインを開き、管理 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

   3. 以下のコマンドを実行してキャッシュを設定し、新しい設定をリロードするようにサーバーに指示を出します。

      /subsystem=infinispan/cache-container=web/:write-attribute(name=default-cache,value=dist)
      /subsystem=infinispan/cache-container=web/distributed-cache=dist/:write-attribute(name=owners,value=3)
      reload
      

      各コマンドの後に以下の応答が表示されるはずです。

      "outcome" => "success"
      

      これらのコマンドは、以下のように standalone-ha.xml ファイルの infinispan サブシステムの dist <distributed-cache> 要素を変更します。 <cache-container>

      <cache-container name="web" aliases="standard-session-cache" default-cache="dist" module="org.jboss.as.clustering.web.infinispan">
          <transport lock-timeout="60000"/>
          <replicated-cache name="repl" mode="ASYNC" batching="true">
              <file-store/>
          </replicated-cache>
          <replicated-cache name="sso" mode="SYNC" batching="true"/>
          <distributed-cache name="dist" owners="3" l1-lifespan="0" mode="ASYNC" batching="true">
              <file-store/>
          </distributed-cache>
      </cache-container>
      

      詳細は、カスタマーポータル https://access.redhat.com/documentation/ja-jp/red_hat_jboss_enterprise_application_platform/?version=6.4 の JBoss EAP 6 の 『『開発ガイド』』 の「 『Web アプリケーションでのクラスタリング』 」の章を参照してください。

手順3.24 HA シングルトンサービスの実装

1. HA シングルトンサービスアプリケーションを記述します。
   以下は、シングルトンサービスとしてデプロイされる SingletonService デコレーターでラップされるサービスの簡単な例です。完全な例は、Red Hat JBoss Enterprise Application Platform 6 に同梱される cluster-ha-singleton クイックスタートにあります。このクイックスタートには、アプリケーションをビルドおよびデプロイするためのすべての手順が含まれます。
   1. サービスを作成します。
      サービスの例を以下に示します。

      package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
      
      import java.util.Date;
      import java.util.concurrent.atomic.AtomicBoolean;
      
      import javax.naming.InitialContext;
      import javax.naming.NamingException;
      
      import org.jboss.logging.Logger;
      import org.jboss.msc.service.Service;
      import org.jboss.msc.service.ServiceName;
      import org.jboss.msc.service.StartContext;
      import org.jboss.msc.service.StartException;
      import org.jboss.msc.service.StopContext;
      
      
      /**
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      public class HATimerService implements Service<String> {
          private static final Logger LOGGER = Logger.getLogger(HATimerService.class);
          public static final ServiceName SINGLETON_SERVICE_NAME = ServiceName.JBOSS.append("quickstart", "ha", "singleton", "timer");
      
          /**
           * A flag whether the service is started.
           */
          private final AtomicBoolean started = new AtomicBoolean(false);
      
          /**
           * @return the name of the server node
           */
          public String getValue() throws IllegalStateException, IllegalArgumentException {
              LOGGER.infof("%s is %s at %s", HATimerService.class.getSimpleName(), (started.get() ? "started" : "not started"), System.getProperty("jboss.node.name"));
              return "";
          }
      
          public void start(StartContext arg0) throws StartException {
              if (!started.compareAndSet(false, true)) {
                  throw new StartException("The service is still started!");
              }
              LOGGER.info("Start HASingleton timer service '" + this.getClass().getName() + "'");
      
              final String node = System.getProperty("jboss.node.name");
              try {
                  InitialContext ic = new InitialContext();
                  ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")).initialize("HASingleton timer @" + node + " " + new Date());
              } catch (NamingException e) {
                  throw new StartException("Could not initialize timer", e);
              }
          }
      
          public void stop(StopContext arg0) {
              if (!started.compareAndSet(true, false)) {
                  LOGGER.warn("The service '" + this.getClass().getName() + "' is not active!");
              } else {
                  LOGGER.info("Stop HASingleton timer service '" + this.getClass().getName() + "'");
                  try {
                      InitialContext ic = new InitialContext();
                      ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")).stop();
                  } catch (NamingException e) {
                      LOGGER.error("Could not stop timer", e);
                  }
              }
          }
      }
      

   2. サービス をクラスター化されたシングルトンとしてインストールする activator を作成します。
      以下のリストは、HATimerService をクラスター化されたシングルトンサービスとしてインストールする Service Activator の例です。

      package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
      
      import org.jboss.as.clustering.singleton.SingletonService;
      import org.jboss.logging.Logger;
      import org.jboss.msc.service.DelegatingServiceContainer;
      import org.jboss.msc.service.ServiceActivator;
      import org.jboss.msc.service.ServiceActivatorContext;
      import org.jboss.msc.service.ServiceController;
      
      
      /**
       * Service activator that installs the HATimerService as a clustered singleton service
       * during deployment.
       *
       * @author Paul Ferraro
       */
      public class HATimerServiceActivator implements ServiceActivator {
          private final Logger log = Logger.getLogger(this.getClass());
      
          @Override
          public void activate(ServiceActivatorContext context) {
              log.info("HATimerService will be installed!");
      
              HATimerService service = new HATimerService();
              SingletonService<String> singleton = new SingletonService<String>(service, HATimerService.SINGLETON_SERVICE_NAME);
              /*
               * To pass a chain of election policies to the singleton, for example, 
               * to tell JGroups to prefer running the singleton on a node with a
               * particular name, uncomment the following line:
               */
              // singleton.setElectionPolicy(new PreferredSingletonElectionPolicy(new SimpleSingletonElectionPolicy(), new NamePreference("node1/singleton")));
      
              singleton.build(new DelegatingServiceContainer(context.getServiceTarget(), context.getServiceRegistry()))
                      .setInitialMode(ServiceController.Mode.ACTIVE)
                      .install()
              ;
          }
      }
      

      注記

      上記の例は、JBoss EAP プライベート API の一部である org.jboss.as.clustering.singleton.SingletonService クラスを使用します。パブリック API は JBoss EAP 7 リリースで利用でき、プライベートクラスは非推奨になりましたが、これらのクラスは JBoss EAP 6.x リリースサイクルの間維持および利用可能になります。
   3. ServiceActivator ファイルの作成
      アプリケーションの resources/META-INF/services/ ディレクトリーに org.jboss.msc.service.ServiceActivator という名前のファイルを作成します。直前の手順で作成した ServiceActivator クラスの完全修飾名が含まれる行を追加します。

      org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator 

   4. クラスター全体のシングルトンタイマーとして使用するタイマーを実装するシングルトン Bean を作成します。
      このシングルトン Bean はリモートインターフェースを持たないため、アプリケーションの別の EJB からローカルインターフェースを参照しないでください。これにより、クライアントまたは他のコンポーネントによるルックアップが阻止され、SingletonService がシングルトンを完全に制御できるようになります。
      1. Scheduler インターフェースの作成

         package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
         
         /**
          * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
          */
         public interface Scheduler {
         
             void initialize(String info);
         
             void stop();
         
         }
         

      2. クラスター全体のシングルトンタイマーを実装するシングルトン Bean を作成します。

         package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
         
         import javax.annotation.Resource;
         import javax.ejb.ScheduleExpression;
         import javax.ejb.Singleton;
         import javax.ejb.Timeout;
         import javax.ejb.Timer;
         import javax.ejb.TimerConfig;
         import javax.ejb.TimerService;
         
         import org.jboss.logging.Logger;
         
         
         /**
          * A simple example to demonstrate a implementation of a cluster-wide singleton timer.
          *
          * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
          */
         @Singleton
         public class SchedulerBean implements Scheduler {
             private static Logger LOGGER = Logger.getLogger(SchedulerBean.class);
             @Resource
             private TimerService timerService;
         
             @Timeout
             public void scheduler(Timer timer) {
                 LOGGER.info("HASingletonTimer: Info=" + timer.getInfo());
             }
         
             @Override
             public void initialize(String info) {
                 ScheduleExpression sexpr = new ScheduleExpression();
                 // set schedule to every 10 seconds for demonstration
                 sexpr.hour("*").minute("*").second("0/10");
                 // persistent must be false because the timer is started by the HASingleton service
                 timerService.createCalendarTimer(sexpr, new TimerConfig(info, false));
             }
         
             @Override
             public void stop() {
                 LOGGER.info("Stop all existing HASingleton timers");
                 for (Timer timer : timerService.getTimers()) {
                     LOGGER.trace("Stop HASingleton timer: " + timer.getInfo());
                     timer.cancel();
                 }
             }
         }
         

2. クラスタリングを有効にして各 JBoss EAP 6 インスタンスを起動します。
   スタンドアロンサーバーでクラスター化を有効にするには、各インスタンスの一意のノード名とポートオフセットを使用して、HA プロファイルで各サーバーを起動する必要があります。
   • Linux の場合は、以下のコマンド構文を使用してサーバーを起動します。

     EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME -Djboss.socket.binding.port-offset=PORT_OFFSET

     例3.6 Linux で複数のスタンドアロンサーバーを起動する

     $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node1
     $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100

   • Microsoft Windows の場合は、以下のコマンド構文を使用してサーバーを起動します。

     EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME -Djboss.socket.binding.port-offset=PORT_OFFSET

     例3.7 Microsoft Windows で複数のスタンドアロンサーバーを起動する

     C:> EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=node1
     C:> EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100

   注記

   コマンドライン引数を使用しない場合は、各サーバーインスタンスの standalone-ha.xml ファイルを設定して、別のインターフェースにバインドすることができます。
3. サーバーのアプリケーションのデプロイ
   以下の Maven コマンドは、デフォルトポートで実行しているスタンドアロンサーバーにアプリケーションをデプロイします。

   mvn clean install jboss-as:deploy

   追加のサーバーにデプロイするには、サーバー名を渡します。別のホストにある場合は、ホスト名とポート番号をコマンドラインに渡します。

   mvn clean package jboss-as:deploy -Djboss-as.hostname=localhost -Djboss-as.port=10099

   Maven の設定やデプロイメントの詳細については、JBoss EAP 6 に同梱される cluster-ha-singleton クイックスタートを参照してください。

手順3.25 セッション Bean のリモート呼び出しに対する Maven プロジェクト設定の追加

1. 必要なプロジェクト依存関係の追加
   プロジェクトの pom.xml を更新して、必要な依存関係が含まれるようにする必要があります。
2. jboss-ejb-client.properties ファイルの追加
   JBoss EJB クライアント API は、JNDI サービスの接続情報が含まれる jboss-ejb-client.properties という名前のプロジェクトのルートでファイルを検索することを想定します。以下の内容を含む、このファイルをプロジェクトの src/main/resources/ ディレクトリーに追加します。

   # In the following line, set SSL_ENABLED to true for SSL
   remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
   remote.connections=default
   # Uncomment the following line to set SSL_STARTTLS to true for SSL
   # remote.connection.default.connect.options.org.xnio.Options.SSL_STARTTLS=true
   remote.connection.default.host=localhost
   remote.connection.default.port = 4447
   remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
   # Add any of the following SASL options if required
   # remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
   # remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false
   # remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
   

   サーバーに合わせてホスト名とポートを変更します。4447 はデフォルトのポート番号です。セキュアな接続の場合は、SSL_ENABLED 行を true に設定し、SSL_STARTTLS 行のコメントを解除します。コンテナーの Remoting インターフェースは、同じポートを使用したセキュアな接続およびセキュアでない接続をサポートします。
3. リモートビジネスインターフェースの依存関係の追加
   セッション Bean のリモートビジネスインターフェースの pom.xml に Maven 依存関係を追加します。

   <dependency>
      <groupId>org.jboss.as.quickstarts</groupId>
      <artifactId>jboss-ejb-remote-server-side</artifactId>
      <type>ejb-client</type>
      <version>${project.version}</version>
   </dependency>

手順3.26 JNDI と Bean の Invoke メソッドを使用した Bean プロキシーの取得

1. チェックされた例外の処理
   以下のコード（InitialContext() および lookup()）で使用される 2 つのメソッドには、javax.naming.NamingException 型のチェック済み例外があります。これらのメソッド呼び出しは、NamingException をキャッチする try/catch ブロック、または NamingException のスローに宣言されているメソッドに囲む必要があります。ejb-remote クイックスタートは 2 番目の手法を使用します。
2. JNDI コンテキストの作成
   JNDI Context オブジェクトは、サーバーからリソースを要求するメカニズムを提供します。以下のコードを使用して JNDI コンテキストを作成します。

   final Hashtable jndiProperties = new Hashtable();
   jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
   final Context context = new InitialContext(jndiProperties);

   JNDI サービスの接続プロパティーは jboss-ejb-client.properties ファイルから読み込まれます。
3. JNDI コンテキストの lookup（）メソッドを使用して Bean プロキシーを取得します。
   Bean プロキシーの lookup() メソッドを呼び出し、必要なセッション Bean の JNDI 名を渡します。これにより、呼び出すメソッドが含まれるリモートビジネスインターフェースのタイプにキャストする必要のあるオブジェクトが返されます。

   
   final RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
       "ejb:/jboss-ejb-remote-server-side//CalculatorBean!" + 
       RemoteCalculator.class.getName());
   

   セッション Bean の JNDI 名は、特別な構文を使用して定義されます。詳細は、「EJB JNDI 命名リファレンス」 を参照してください。
4. メソッドを呼び出す
   プロキシー Bean オブジェクトがあると、リモートビジネスインターフェースに含まれるメソッドを呼び出すことができます。

   int a = 204;
   int b = 340;
   System.out.println("Adding " + a + " and " + b + " via the remote stateless calculator deployed on the server");
   int sum = statelessRemoteCalculator.add(a, b);
   System.out.println("Remote calculator returned sum = " + sum);

   プロキシー Bean はメソッド呼び出しリクエストをサーバーのセッション Bean に渡します。結果はプロキシー Bean に返され、呼び出し元に返されます。プロキシー Bean とリモートセッション Bean 間の通信は、呼び出し元に対して透過的です。

手順3.27 非同期セッション Bean とクライアントの作成

1. 非同期セッション Bean メソッドを作成します。
   以下の例では、sayHelloAsync() メソッドは @Asynchronous アノテーションを使用して非同期としてマークされます。型 String で、必要な Future クラス実装を返します。

   import javax.ejb.Remote;
   import javax.ejb.SessionContext;
   import javax.ejb.Stateless;
   import javax.ejb.TransactionAttribute;
   import javax.ejb.TransactionAttributeType;
   import javax.interceptor.Interceptors;
   
   import java.util.concurrent.Future;
   import javax.ejb.AsyncResult;
   import javax.ejb.Asynchronous;
   
   @Stateless(name="Hello")
   @Remote(Hello.class)
   public class HelloBean implements Hello {
   
       @Asynchronous
       public Future<String> sayHelloAsync() {
          return new AsyncResult<String>("Hello");
       }
   }

2. クライアントコードを作成します。
   利用可能な Future.get（） メソッドの 1 つを使用して EJB を検索し、非同期メソッドを呼び出します。以下の例では、待機時間を timeout 引数および unit 引数で指定された値に制限します。

   Future<String> future = ejbObject.sayHelloAsync();
   String response = future.get(timeout, unit);

手順3.28 ステートフル EJB キャッシュの設定

1. サーバー設定ファイルの ejb3 サブシステムで <caches> 要素を見つけます。<cache> 要素を追加します。以下の例では、「my=cache」という名前のキャッシュを作成します。

   <cache name="my-cache" passivation-store-ref="my-cache-file" aliases="my-custom-cache"/>

2. サーバー設定ファイルの ejb3 サブシステムで <passivation-stores> 要素を見つけます。前のステップで定義したキャッシュ用に <file-passivation-store> を作成します。

   <file-passivation-store name="my-cache-file" idle-timeout="1260" idle-timeout-unit="SECONDS" max-size="200"/>

3. ejb3 サブシステムの設定が以下の例のようになるはずです。

   <subsystem xmlns="urn:jboss:domain:ejb3:1.4">
     ...
     <caches>
       <cache name="simple" aliases="NoPassivationCache"/>
       <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>  
       <cache name="clustered" passivation-store-ref="infinispan" aliases="StatefulTreeCache"/>  
       <cache name="my-cache" passivation-store-ref="my-cache-file" aliases="my-custom-cache"/>               
     </caches>
     <passivation-stores>
       <file-passivation-store name="file" idle-timeout="120" idle-timeout-unit="SECONDS" max-size="500"/>
       <cluster-passivation-store name="infinispan" cache-container="ejb"/>
       <file-passivation-store name="my-cache-file" idle-timeout="1260" idle-timeout-unit="SECONDS" max-size="200"/>
     </passivation-stores>
     ...
   </subsystem>

   パッシベーションキャッシュ "my-cache" は「my-cache-file」パッシベーションストアに設定されたようにステートフルセッション Bean をファイルシステムに渡します。これには、idle-timeout、idle-timeout-unit、および max-size オプションが含まれます。
4. EJB JAR の META -INF/ ディレクトリーに jboss-ejb3.xml ファイルを作成します。以下の例は、前のステップで定義されたキャッシュを使用するように EJB を設定します。

   <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
         xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xmlns:c="urn:ejb-cache:1.0"
         xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
         version="3.1"
         impl-version="2.0">
     <assembly-descriptor>
       <c:cache>
         <ejb-name>*</ejb-name>
         <c:cache-ref>my-cache</c:cache-ref>
       </c:cache>
     </assembly-descriptor>
   </jboss:ejb-jar>

5. タイムアウト値を設定する方法は、EJB 2 または EJB 3 を実装するかどうかによって異なります。
   • EJB 3 ではアノテーションが導入されるため、以下のように EJB コードで javax.ejb.StatefulTimeout アノテーションを指定できます。

     @StatefulTimeout(value = 1320, unit=java.util.concurrent.TimeUnit.SECONDS) 
     @Stateful
     @Remote(MyStatefulEJBRemote.class)
     public class MyStatefulEJB implements MyStatefulEJBRemote {
       ...
     }

     @StatefulTimeout の値は以下のいずれかに設定できます。

     • 値が 0 の場合は、Bean がすぐに削除できます。
     • 0 より大きい値は、unit パラメーターで指定された単位のタイムアウト値を示します。デフォルトのタイムアウト単位は MINUTES です。パッシベーションキャッシュ設定を使用し、idle-timeout の値が StatefulTimeout 値よりも小さい場合、指定された idle-timeout 期間に対してアイドル状態になると、JBoss EAP は Bean をパッシベートします。その後、Bean は StatefulTimeout の期間後に削除することができます。
     • -1 を値と し て指定すると、タイムアウトにより bean が削除されません。パッシベーションキャッシュ設定を使用し、Bean が idle-timeout でアイドル状態である場合、JBoss EAP は Bean インスタンスを passivation-store に渡します。
     • -1 未満の値は有効ではありません。
   • EJB 2 と EJB 3 の両方に対して、ejb-jar.xml ファイルでステートフルタイムアウトを設定できます。

     <?xml version="1.0" encoding="UTF-8"?>
     <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
              version="3.1">
       <enterprise-beans>
         <session>
           <ejb-name>HelloBean</ejb-name>
             <session-type>Stateful</session-type>
             <stateful-timeout>
               <timeout>1320</timeout>
               <unit>Seconds</unit>
             </stateful-timeout>
         </session>
       </enterprise-beans>
     </ejb-jar>

   • EJB 2 と EJB 3 の両方に対して、jboss-ejb3.xml ファイルでステートフルタイムアウトを 設定できます。

     <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
           xmlns="http://java.sun.com/xml/ns/javaee"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:c="urn:ejb-cache:1.0"
           xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
           version="3.1"
           impl-version="2.0">
       <enterprise-beans>
         <session>
           <ejb-name>HelloBean</ejb-name>
             <session-type>Stateful</session-type>
             <stateful-timeout>
               <timeout>1320</timeout>
               <unit>Seconds</unit>
             </stateful-timeout>
         </session>
       </enterprise-beans>
       <assembly-descriptor>
         <c:cache>
           <ejb-name>*</ejb-name>
           <c:cache-ref>my-cache</c:cache-ref>
         </c:cache>
       </assembly-descriptor>
     </jboss:ejb-jar>

手順3.30 Seam 2.2 アーカイブの移行

1. データソース設定を更新します。
   Seam 2.2 の例では、java:/ExampleDS という名前のデフォルトの JDBC データソースを使用します。このデフォルトのデータソースは JBoss EAP 6 で java:jboss/datasources/ExampleDS に変更されています。アプリケーションがサンプルデータベースを使用する場合は、以下のいずれかを実行できます。

   • JBoss EAP 6 に同梱されるサンプルデータベースを使用する場合は、META-INF/persistence.xml ファイルを変更して、既存の jta-data-source 要素をデータベースのデータソースの JNDI 名に置き換えます。

     <!-- <jta-data-source>java:/ExampleDS</jta-data-source> -->
     <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>

   • 既存のデータベースを保持する場合は、データソース定義を EAP_HOME/standalone/configuration/standalone.xml ファイルに追加できます。
     重要

     サーバーの再起動後に変更が維持されるようにするには、サーバーを停止してからサーバー設定ファイルを編集する必要があります。
     以下の定義は、JBoss EAP 6 で定義されたデフォルトの HSQL データソースのコピーです。

     <datasource name="ExampleDS" jndi-name="java:/ExampleDS" enabled="true" jta="true" use-java-context="true" use-ccm="true">
        <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
        <driver>h2</driver>
        <security>
           <user-name>sa</user-name>
           <password>sa</password>
        </security>
     </datasource>

   • 管理 CLI コマンドラインインターフェースを使用してデータソース定義を追加することもできます。以下は、データソースの追加に使用する構文の例です。行の最後にある「\"」は、以下の行のコマンドの継続を示しています。

     例3.12 データソース定義を追加する構文の例

     $ EAP_HOME/bin/jboss-cli --connect 
     [standalone@localhost:9999 /] data-source add --name=ExampleDS --jndi-name=java:/ExampleDS \ 
           --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --driver-name=h2 \ 
           --user-name=sa --password=sa
     

   データソースの設定方法は 「DataSource設定の更新」 を参照してください。
2. 必要な依存関係を追加します。
   Seam 2.2 アプリケーションは JSF 1.2 を使用しているため、JSF 1.2 モジュールの依存関係を追加して JSF 2.0 モジュールを除外する必要があります。これを実行するには、以下のデータが含まれる EAR の META-INF/ ディレクトリーに 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>

   アプリケーションがサードパーティーのロギングフレームワークを使用する場合は、「ロギング依存関係の変更」 に記載されているように、これらの依存関係を追加する必要があります。
3. アプリケーションが Hibernate 3.x を使用する場合は、最初に Hibernate 4 ライブラリーを使用してアプリケーションを実行します。
   アプリケーションが Seam Managed Persistence Context、Hibernate 検索、検証、またはその他の機能を使用していない場合は、Hibernate 4 ライブラリーで実行することができます。ただし、Hibernate クラスを参照する ClassNotFoundExceptions または ClassCastExceptions が表示された場合や、以下のようなエラーが表示される場合には、次の手順の手順に従い、アプリケーションを Hibernate 3.3 ライブラリーを使用するように変更する必要がある場合があります。

           Caused by: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.jboss.seam.persistence.HibernateSessionProxy.getSession(Lorg/hibernate/EntityMode;)Lorg/hibernate/Session;" the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, org/jboss/seam/persistence/HibernateSessionProxy, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for interface org/hibernate/Session have different Class objects for the type org/hibernate/Session used in the signature
   

4. 外部フレームワークまたは他の場所から依存アーカイブをコピーします。
   アプリケーションが Hibernate 3.x を使用し、アプリケーションで Hibernate 4 が正常に使用できない場合は、Hibernate 3.x JAR を /lib ディレクトリーにコピーし、以下のように META-INF/jboss-deployment-structure.xml の deployments セクションの Hibernate モジュールを除外する必要があります。

   <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
    <deployment>
      <exclusions>
        <module name="org.hibernate"/>
      </exclusions>
    <deployment>
   </jboss-deployment-structure>

   アプリケーションと Hibernate 3.x をバンドルする場合には、追加の手順を実施する必要があります。詳細は、 「Hibernate および JPA を使用するアプリケーションの変更の設定」 を参照してください。
5. Seam 2.2 JNDI エラーをデバッグして解決します。
   Seam 2.2 アプリケーションを移行すると、以下のようなログに javax.naming.NameNotFoundException エラーが表示される可能性があります。

   javax.naming.NameNotFoundException: Name 'jboss-seam-booking' not found in context ''

   コード全体で JNDI ルックアップを変更したくない場合は、アプリケーションの components.xml ファイルを以下のように変更できます。
   1. 既存の core-init 要素を置き換えます。
      まず、以下のように既存の core-init 要素を置き換える必要があります。

      <!-- <core:init jndi-pattern="jboss-seam-booking/#{ejbName}/local" debug="true" distributable="false"/>   -->
      <core:init debug="true" distributable="false"/>
      

   2. サーバーログで JNDI バインディング INFO メッセージを検索します。
      次に、アプリケーションのデプロイ時にサーバーログに出力される JNDI バインディング INFO メッセージを見つけます。JNDI バインディングメッセージは以下のようになります。

      INFO org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor (MSC service thread 1-1) JNDI bindings for session bean
      named AuthenticatorAction in deployment unit subdeployment "jboss-seam-booking.jar" of deployment "jboss-seam-booking.ear" are as follows.
          java:global/jboss-seam-booking/jboss-seam-booking.jar/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator
          java:app/jboss-seam-booking.jar/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator
          java:module/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator
          java:global/jboss-seam-booking/jboss-seam-booking.jar/AuthenticatorAction
          java:app/jboss-seam-booking.jar/AuthenticatorAction
          java:module/AuthenticatorAction
      

   3. コンポーネント要素を追加します。
      ログの JNDI バインディング INFO メッセージごとに、一致する component 要素を components.xml ファイルに追加します。

      <component class="org.jboss.seam.example.booking.AuthenticatorAction" jndi-name="java:app/jboss-seam-booking.jar/AuthenticatorAction" />

   移行の問題のデバッグおよび解決方法に関する詳細は、 「移行の問題のデバッグおよび解決」 を参照してください。
   Seam 2 アーカイブの既知の問題の一覧は、 「Seam 2.2 アーカイブの移行の問題」 を参照してください。