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

手順3.1 モジュールの依存関係の理解

1. 暗黙的な依存関係を理解する

   サーバー内のデプロイヤーは、javax.api や sun.jdk などの一般的に使用されるモジュール依存関係を暗黙的かつ自動的に追加します。これにより、ランタイム時にデプロイメントに対してクラスを可視化でき、開発者が依存関係を明示的に追加する作業が軽減されます。暗黙的な依存関係がいつどのように追加されるかについては、https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ にある JBoss EAP 6 向け『開発ガイド』の章「クラスローディングとモジュール」に記載されている「暗黙的なモジュール依存関係」の説明を参照してください。

2. 明示的な依存関係を理解する

   その他のクラスに対してはモジュールを明示的に指定する必要があります。明示的に指定しないと、不明な依存関係が原因でデプロイメントエラーやランタイムエラーが発生します。依存関係が不明な場合は、サーバーログに 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.2 ResourceBundle プロパティーの場所変更

1. WAR アーカイブをデプロイする場合、これらのプロパティーを WAR の WEB-INF/classes/ フォルダーでパッケージ化する必要があります。
2. これらのプロパティーを EAR のすべてのコンポーネントに対してアクセス可能にするには、JAR のルートでパッケージ化し、EAR の lib/ フォルダーに置く必要があります。

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

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. 次の 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>
      

2. サーバー設定ファイルの ee サブシステムを編集します。JBoss CLI を使用するか、手作業でファイルを編集します。
   • 次の手順に従って JBoss 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 サブシステム要素の例になります。

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

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

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

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

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

手順3.5 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. jboss-deployment-structure.xml ファイルは、WAR をデプロイする場合は META-INF/ または WEB-INF/ ディレクトリーに置き、EAR をデプロイする場合は META-INF/ ディレクトリーに置きます。デプロイメントに依存する子デプロイメントが含まれる場合は、各サブデプロイメントのモジュールも除外する必要があります。
3. 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>
   

4. 以下の引数を用いて JBoss EAP 6 サーバーを起動し、アプリケーションをデプロイするときに ClassCastException がコンソールに表示されないようにします。

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

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

手順3.6 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. ロギングサブシステムの 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.7 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 ロギングクラスが含まれる JAR は org.jboss.logging という名前のモジュールにあります。MANIFEST-MF ファイルは次のようになるはずです。

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

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

手順3.8 アーカイブパッケージの編集

1. WAR のパッケージ化

   WAR は単一のモジュールで、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 内の他のサブデプロイメントに属するクラスがサブデプロイメントに対して可視化されます。
   クラスローディングの詳細については、https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ にある JBoss EAP 6 向け『開発ガイド』の章「クラスローディングとモジュール」を参照してください。

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

手順3.9 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 という名前のテキストファイルが含まれてます。ドライバーが 4.0 対応でない場合は、次の方法の 1 つを用いてデプロイ可能にすることができます。

      • 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. データソースドライバーを追加します。

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

   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.10 Hibernate バンドルの削除

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

手順3.11 他の承認チェックの無効化

• 他の承認チェックを無効にし、既存の PicketLink デプロイメントを継続して使用するには、以下の方法の 1 つを使用します。

  • システム全体のプロパティーの設定

    サーバーレベルで他の承認チェックを無効にするには、org.jboss.ws.cxf.disableHandlerAuthChecks システムプロパティーの値を true に設定します。この方法は、アプリケーションサーバーに対して作成されたすべてのデプロイメントに影響します。
    システムプロパティーの設定方法は、JBoss EAP 『管理および設定ガイド』の「管理 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.12 JNDI ルックアップの変更

1. 「移植可能な EJB JNDI 名」を確認する
2. 「JNDI 名前空間のルールの確認」
3. 「JNDI 名前空間の新ルールに準拠するようアプリケーションを変更」

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

1. 必要な Hibernate 3 の JAR をアプリケーションライブラリーへコピーする

   見つからないクラスが含まれる特定の Hibernate 3 JAR をアプリケーションの lib/ ディレクトリーへコピーするか、他の方法を使用してクラスパスに追加すると問題を解決できることがあります。これにより、Hibernate のバージョンを複数使用することが原因で ClassCastExceptions や他のクラスローディングの問題が発生することがあります。この問題が発生した場合、次の方法で対処する必要があります。

2. Hibernate 3 ライブラリーのみを使用するようサーバーへ指示する

   JBoss EAP 6 では、Hibernate 3.5 (およびそれ以降のバージョン) の永続性プロバイダー jar をアプリケーションと共にパッケージ化することができます。サーバーで Hibernate 3 ライブラリーのみを使用し、Hibernate 4 ライブラリーを除外するようにするには、次のように jboss.as.jpa.providerModule を persistence.xml の 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 の 2 次キャッシュの無効化

   JBoss EAP 6 では、Hibernate 3 の 2 次キャッシュの挙動が以前のリリースと異なります。アプリケーションを用いて Hibernate の 2 次キャッシュを使用している場合、Hibernate 4 にアップグレードするまで 2 次キャッシュを無効にする必要があります。2 次キャッシュを無効にするには、persistence.xml ファイルの <hibernate.cache.use_second_level_cache> を false に設定します。

手順3.14 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 の text タイプを JDBC LONGVARCHAR へマッピングする

   バージョンが 3.5 以前の Hibernate では text 型は JDBC CLOB へマッピングされていました。Java String プロパティーを JDBC CLOB へマッピングするため、新しい Hibernate タイプ materialized_clob が Hibernate 4 に追加されました。JDBC CLOB へのマッピングが目的で type="text" と設定されているプロパティーがアプリケーションにある場合は、次の項目の 1 つを実行する必要があります。
   1. アプリケーションが hbm マッピングファイルを使用する場合、プロパティーを type="materialized_clob" に変更します。
   2. アプリケーションがアノテーションを使用する場合、@Type(type = "text") を @Lob に置き換えます。

2. コードを確認し戻り値型の変更を探す

   数値集約基準の射影 (projection) は 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 値が返されます。

1. AnnotationConfiguration を設定へマージします。
   AnnotationConfiguration はすでに廃止されていますが、移行に影響しないようにする必要があります。
   hbm.xml ファイルを使用している場合、JBoss EAP 6 では 以前のリリースで使用された org.hibernate.cfg.DefaultNamingStrategy ではなく、AnnotationConfiguration の org.hibernate.cfg.EJB3NamingStrategy が使用されることに注意してください。そのため、ネーミングの不一致が発生する可能性があります。ネーミングストラテジーに依存してアソシエーション (多対多および要素のコレクション) テーブルの名前をデフォルトにする場合は、この問題が発生することがあります。この問題を解決するには、レガシーの org.hibernate.cfg.DefaultNamingStrategy を使用するように Hibernate に指示するため、Configuration#setNamingStrategy を呼び出して org.hibernate.cfg.DefaultNamingStrategy#INSTANCE に渡します。
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 に設定する必要があります。

手順3.15 クラスター化された環境で稼働するよう永続プロパティーを設定

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.16 Infinispan を使用するよう persistence.xml ファイルを変更する

1. JBoss EAP 6 の JPA アプリケーション向けに Infinispan を設定する

   JBoss EAP 6 で Infinispan を使用し、プロパティーを指定して JPA アプリケーションに同じ設定を行う方法は次のとおりです。

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

   また、次のように、shared-cache-mode を ENABLE_SELECTIVE または ALL の値で指定する必要があります。
   • デフォルト値は 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.manager_lookup_class"
        value="org.hibernate.transaction.JBossTransactionManagerLookup"/>
   <property name="hibernate.cache.use_second_level_cache" value="true"/>
   
   

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

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

手順3.17 以下の 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 インスタンスを作成します。
      • Validator インスタンスを EJB、CDI Bean、または他の Java EE インジェクト可能リソースにインジェクトします。
   2. Validator インスタンスをカスタマイズするために、ValidatorFactory.usingContext() により返された ValidatorContext を使用できます。この 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() メソッドが含まれますが、メソッドシグネチャーが変更されました。また、代替の DDL は Hibernate Validator 4 でサポートされなくなりました。

手順3.18 JMS ブリッジの作成

1. ソース JBoss EAP 5.x サーバー上のブリッジの設定

   リリース間のクラスの競合を防ぐため、以下の手順に従って JBoss EAP 5.x 上の JMS ブリッジを設定する必要があります。SAR ディレクトリーおよびブリッジの名前は任意で、変更可能です。
   1. EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/ のように、JBoss EAP 5 デプロイメントディレクトリーでサブディレクトリーを作成し、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 ルックアップとブリッジの「ターゲット」には、ユーザーが「jbossuser」でパスワードが「jbosspass」のセキュリティークレデンシャルが含まれています。これは、JBoss EAP 6 はデフォルトでセキュア化されているからです。パスワードが「jbosspass」のユーザー「jbossuser」は、EAP_HOME/bin/add_user.sh スクリプトを使用して ApplicationRealm で作成され、guest ロールが割り当てられます。
   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 ファイルを格納します。EAP_HOME/modules/system/layers/base/org/mycustommq/main/ は MyCustomMQ メッセージングプロバイダー用に作成されたディレクトリー構造の例になります。
      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 リソースの名前を提供します。user および password クレデンシャルが指定されいると、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 プロパティーは source の context 要素に定義されています。上記の target の例のように、context 要素が省略されると、JMS リソースはローカルインスタンスでルックアップされます。

手順3.19 開始する前に

1. クライアントとサーバーをシャットダウンします。
2. JBoss Messaging データのバックアップコピーを作成します。メッセージデータは、JBM_ という接頭辞でデータベースのテーブルに格納されます。

手順3.20 HornetQ へのプロバイダーの変更

1. 設定の転送

   既存の JBoss Messaging 設定を JBoss EAP 6 設定に転送します。以下の設定が、 JBoss Mesaging サーバーにあるデプロイメント記述子に存在します。
   • 接続ファクトリーサービス設定
     この設定は、 JBoss Messaging サーバーにデプロイされた JMS 接続ファクトリーを定義します。JBoss Messaging は、アプリケーションサーバーのデプロイメントディレクトリーにある connection-factories-service.xml という名前のファイルで接続ファクトリーを設定します。
   • 宛先設定
     この設定は、JBoss Messaging サーバーでデプロイされた JMS キューおよびトピックを定義します。デフォルトでは、JBoss Messaging は、アプリケーションサーバーのデプロイメントディレクトリーにある destinations-service.xml という名前のファイルで宛先を設定します。
   • メッセージブリッジサービス設定
     この設定には、JBoss Messaging サーバーでデプロイされたブリッジサービスが含まれます。デフォルトではブリッジがデプロイされないため、デプロイメントファイルの名前は、JBoss Messaging インストールによって異なります。

2. アプリケーションコードの変更

   アプリケーションコードで標準的な JMS を使用する場合は、コードの変更が必要ありません。ただし、アプリケーションがクラスターに接続する場合は、クラスタリングセマンティクスについて HornetQ ドキュメンテーションを参照する必要があります。クラスタリングは、JMS 仕様の範囲外であり、クラスタリング機能の各実装において JBoss Messaging は非常に異なる方法を取ります。
   アプリケーションが JBoss Messaging に固有な機能を使用する場合は、HornetQ で利用可能な同等の機能を使用するようコードを変更する必要があります。
   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 スタンドアロンサーバーの起動時に、コマンドラインでバインド引数を指定します。
     以下の例は、スタンドアロンサーバーでコマンドラインにバインドアドレスを指定する方法を示しています。

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

     注記

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

     EAP_HOME/bin/standalone.sh -b=127.0.0.1

     JBoss EAP 5 の構文形式もサポートされます。

     EAP_HOME/bin/standalone.sh -b 127.0.0.1

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

     <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. jvmRoute が mod_jk と mod_proxy をサポートするよう設定する

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

   <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 のバディーレプリケーションを使用して、クラスターのすべてのインスタンスへのデータレプリケーションを抑制しました。
   JBoss EAP 6 ではバディーレプリケーションは、Infinispan の分散キャッシュである DIST モードに置き換えられました。DIST (分散) モードは強力なクラスタリングモードで、サーバーがクラスターに追加されると Infinispan によって線形にスケールします。サーバーが DIST キャッシングモードを使用するよう設定する方法の例は次のとおりです。
   1. コマンドラインを開き、次のように HA または Full プロファイルのいずれかでサーバーを起動します。

      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 サブシステムにある web <cache-container> 設定の dist <distributed-cache> 要素を変更します。

      <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/site/documentation/JBoss_Enterprise_Application_Platform/ にある JBoss EAP 6 向け『開発ガイド』の章「Web アプリケーションのクラスター化」を参照してください。

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

1. HA シングルトンサービスアプリケーションを作成します。

   シングルトンサービスとしてデプロイされる SingletonService デコレーターでラッピングされた Service の簡単な例を以下に示します。完全な例は、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. Service をクラスター化されたシングルトンとしてインストールするアクティベーターを作成します。

      以下は、HATimerService をクラスター化されたシングルトンサービスとしてインストールするサービスアクティベーターの例になります。

      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("node2/cluster")));
      
              singleton.build(new DelegatingServiceContainer(context.getServiceTarget(), context.getServiceRegistry()))
                      .setInitialMode(ServiceController.Mode.ACTIVE)
                      .install()
              ;
          }
      }
      

      注記

      上記のコードサンプルは、JBoss EAP プライベート API の一部である org.jboss.as.clustering.singleton.SingletonService クラスを使用します。パブリック API は EAP 7 リリースで利用可能になる予定です。その後、プライベートクラスは廃止されますが、6.x のリリースサイクル中は維持され、利用可能です。

   3. ServiceActivator ファイルを作成します。

      アプリケーションの resources/META-INF/services/ ディレクトリーに org.jboss.msc.service.ServiceActivator という名前のファイルを作成します。前の手順で作成した ServiceActivator クラスの完全修飾名が含まれる行を追加します。

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

   4. 使用するタイマーをクラスター全体のシングルトンタイマーとして実装する Singleton Bean を作成します。

      この Singleton Bean はリモートインターフェースを持たないようにし、すべてのアプリケーションの別の EJB からローカルインターフェースを参照しないようにする必要があります。これにより、クライアントや他のコンポーネントがルックアップできないようにし、SingletonService がシングルトンを完全に制御するようにします。

      1. スケジューラーインターフェースを作成します。

         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. クラスター全体のシングルトンタイマーを実装する Singleton 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.1 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.2 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.22 セッション 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 行をアンコメントします。コンテナ内のリモーティングインターフェースは同じポートを使用して安全な接続と安全でない接続をサポートします。

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.23 JNDI を使用した Bean プロキシの取得および Bean のメソッドの呼び出し

1. チェック例外の処理

   次のコードに使用されるメソッドの 2 つ (InitialContext() および lookup()) は、タイプ javax.naming.NamingException のチェック済み例外を持っています。これらのメソッド呼び出しは、NamingException をキャッチする try/catch ブロックか、NamingException のスローが宣言されたメソッドでエンクローズされる必要があります。ejb-remote クイックスタートでは、2 つ目の方法を使用します。

2. JNDI コンテキストの作成

   JNDI コンテキストオブジェクトはサーバーよりリソースを要求するメカニズムを提供します。次のコードを使用して 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 とリモートセッション Bean 間の通信は呼び出し側に透過的です。

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

1. データソース設定を更新する

   一部の Seam 2.2 の例は、java:/ExampleDS という名前のデフォルトの JDBC データソースを使用します。このデフォルトデータソースは JBoss EAP 6 では java:jboss/datasources/ExampleDS に変更になりました。例のデータベースがアプリケーションによって使用される場合、以下の方法の 1 つ実行します。

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

     <!-- <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.3 データソース定義を追加する構文の例

     $ 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 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 のデプロイメントセクションで 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 アーカイブの移行の問題」を参照してください。