移行ガイド

1. 最初に、アプリケーションのパッケージと依存関係を確認します。詳細は 「クラスローディングの変更によるアプリケーション依存関係の更新」を参照してください。

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

手順3.1 タスク

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

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

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

   その他のクラスに対してはモジュールを明示的に指定する必要があります。明示的に指定しないと、欠落している依存関係が原因でデプロイメントエラーやランタイムエラーが発生します。依存関係が欠落していると、サーバーログに ClassNotFoundExceptions や NoClassDefFoundErrors トレースが記録されます。複数のモジュールが同じ JAR をロードしたり、異なるモジュールによってロードされるクラスを拡張するクラスを 1 つのモジュールがロードすると、サーバーログに ClassCastExceptionsトレースが記録されます。依存関係を明示的に指定するには、MANIFEST.MF を変更するか、JBoss 固有のデプロイメント記述子ファイル jboss-deployment-structure.xml を作成します。モジュール依存関係の詳細は、JBoss Enterprise Application Platform 6 開発ガイドに記載されている、クラスローディングとモジュールの概要を参照してください。

手順3.2

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
      
      

      Copy to Clipboard Toggle word wrap
   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>
      

      Copy to Clipboard Toggle word wrap
2. サーバー設定ファイルの ee サブシステムを編集します。JBoss CLI を使用するか、手作業でファイルを編集します。
   • 次の手順に従って JBoss CLI を使用し、サーバー設定ファイルを編集します。
     1. サーバーを起動し、管理 CLI へ接続します。
        • Linux の場合は、コマンドラインで以下を入力します。

          $ EAP_HOME/bin/jboss-cli.sh --connect
          $ Connected to standalone controller at localhost:9999
          

          Copy to Clipboard Toggle word wrap
        • Windows の場合は、コマンドラインで以下を入力します。

          C:\>EAP_HOME\bin\jboss-cli.bat --connect
          C:\> Connected to standalone controller at localhost:9999
          

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

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

        Copy to Clipboard Toggle word wrap
        次の結果が表示されるはずです。

        {"outcome" => "success"}
        

        Copy to Clipboard Toggle word wrap
   • サーバー設定ファイルを手作業で編集したい場合は、次の手順に従ってください。
     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>
        

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

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

   Copy to Clipboard Toggle word wrap

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

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

手順3.5 log4j.properties または log4j.xml ファイルを使用するよう Enterprise Application Platform 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>
   

   Copy to Clipboard Toggle word wrap
2. WAR をデプロイする場合は jboss-deployment-structure.xml ファイルを WEB-INF/ ディレクトリに置きます。EAR をデプロイする場合は jboss-deployment-structure.xml ファイルを META-INF/ ディレクトリに置きます。
3. デプロイメントの lib/ ディレクトリに log4j.properties または log4j.xml ファイルが含まれるようにします。
4. アプリケーションをデプロイします。

手順3.6 タスク

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);
   }
   

   Copy to Clipboard Toggle word wrap

2. ロギング依存関係の追加

   JBoss ロギングクラスが含まれる JAR は org.jboss.logging という名前のモジュールにあります。MANIFEST-MF ファイルは次のようになるはずです。

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

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

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

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

   Copy to Clipboard Toggle word wrap
   デフォルトでは false に設定され、EAR 内の他のサブデプロイメント属するクラスがサブデプロイメントに対して可視化されます。
   クラスローディングについての詳細は、JBoss Enterprise Application Platform 6 開発ガイドの「クラスローディングとモジュール」の章を参照してください。

1. アプリケーションがデータソースを使用する場合は 「DataSource 設定の更新」を参照してください。

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

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

1. JDBC ドライバーのインストール

   1. JDBC ドライバーのデプロイメントとしてのインストール

      これはドライバーのインストールに推奨される方法です。JDBC ドライバーがデプロイメントとしてインストールされると、普通の JAR としてデプロイされます。JBoss Enterprise Application Platform インスタンスがスタンドアロンサーバーとして実行されている場合は、 JDBC 4.0 対応の JAR を EAP_HOME/standalone/deployments/ ディレクトリへコピーします。サーバーが管理ドメインとして実行されている場合は、JAR を EAP_HOME/domain/deployments/ ディレクトリへコピーします。
      スタンドアロンサーバーにデプロイメントとしてインストールされた MySQL JDBC ドライバーの例は次の通りです。

      $cp mysql-connector-java-5.1.15.jar EAP_HOME/standalone/deployments/

      Copy to Clipboard Toggle word wrap
      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

        Copy to Clipboard Toggle word wrap
      • java.sql.Driver ファイルをデプロイメントディレクトリに作成します。スタンドアロンサーバーとして実行されている JBoss Enterprise Application Platform 6 のインスタンスの場合、このファイルを EAP_HOME/standalone/deployments/META-INF/services/java.sql.Driver に置く必要があります。サーバーが管理ドメインで実行されている場合、EAP_HOME/domain/deployments/META-INF/services/java.sql.Driver に置く必要があります。
      この方法の利点は次の通りです。

      • モジュールを定義する必要がないため、最も簡単な方法になります。
      • サーバーが管理ドメインで実行されている場合、この方法を使用するデプロイメントは自動的にドメインの全サーバーへ伝播されます。そのため、管理者が手作業で ドライバー JAR を配布する必要がありません。

      この方法の難点は次の通りです。

      • ドライバーと依存ライセンス JAR を持つ JARなど、JDBC ドライバーが複数の JAR で構成されている場合、ドライバーをデプロイメントとしてインストールすることができません。この場合、JDBC ドライバーをコアモジュールとしてインストールする必要があります。
      • ドライバーが JDBC 4.0 対応でない場合、ドライバークラス名が含まれるファイルを作成して JAR へインポートするか、deployments/ ディレクトリにオーバーレイする必要があります。

   2. コアモジュールとしての JDBC ドライバーのインストール

      1. EAP_HOME/modules/ ディレクトリ下にファイルパス構造を作成します。この構造にはドライバー JAR とモジュールを定義する module.xml ファイルが含まれます。例えば、前述の MySQL JDBC ドライバーを使用して次のようなディレクトリ構造を作成します。EAP_HOME/modules/com/mysql/main/
      2. main/ サブディレクトリに次の module.xml ファイルを作成します。

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

         Copy to Clipboard Toggle word wrap
         モジュール名「com.mysql」はこのモジュールのディレクトリ構造と一致します。<dependencies> 要素は、このモジュールの他のモジュールへの依存関係を指定するために使用されます。この場合、全 JDBC データソースの場合と同様に、javax.api という名前の他のモジュールによって定義される Java JDBC API に依存します。このモジュールは modules/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/

         Copy to Clipboard Toggle word wrap
      この方法の利点は次の通りです。

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

      この方法の難点は次の通りです。

      • モジュールの設定が難しくなります。
      • 管理ドメインで実行されている各サーバーへモジュールを手作業でコピーする必要があります。

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

      Copy to Clipboard Toggle word wrap

      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>
      

      Copy to Clipboard Toggle word wrap

   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>
      

      Copy to Clipboard Toggle word wrap

手順3.9 Hibernate バンドルの削除

1. アプリケーションライブラリーフォルダーより Hibernate JAR を削除します。

2. persistence.xml ファイルの <hibernate.transaction.manager_lookup_class> 要素は必要がないため、削除またはコメントアウトします。

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

1. 「移植可能な JNDI ネーミング構文」 について学ぶ

2. 「JNDI 名前空間のルールの確認」
3. 「新しい JNDI 名前空間ルールに準拠するようアプリケーションを変更する」

手順3.11

1. 「Hibernate および JPA を使用するアプリケーションの変更設定」

2. 「Hibernate 4 を使用するよう Hibernate 3 のアプリケーションを更新する」

3. 「JPA 2.0 の仕様に準拠するようアプリケーションを更新する」

4. 「Infinispan による JPA/Hibernate 2 次キャッシュの置き換え」

5. 「Hibernate Validator 4 への移行」

手順3.12 タスク

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

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

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

   JBoss Enterprise Application Platorm 6 では、Hibernate 3.5 (およびそれ以降のバージョン) の永続性プロバイダー jar をアプリケーションと共にパッケージ化することができます。Hibernate 3 ライブラリのみを使用し、Hibernate 4 を除外するようサーバーを指示するには、次のように jboss.as.jpa.providerModule を persistence.xml の hibernate3-bundled に設定する必要があります。

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

   Copy to Clipboard Toggle word wrap

   Java 永続性 API (JPA) のデプロイヤーによってアプリケーションに永続性プロバイダーがあることが検出され、Hibernate 3 ライブラリが使用されます。

3. Hibernate の 2 次キャッシュの無効化

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

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

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

手順3.14

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. コードを確認し戻り値型の変更を探す

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

手順3.15

1. AnnotationConfiguration の設定へのマージ

   AnnotationConfiguration は既に廃止されていますが、移行に影響しないようにしなければなりません。
   今でも hbm.xml ファイルを使用している場合、JBoss Enterprise Application Platform 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 ファイル名に適合するよう名前空間を変更する

   Expand

   表3.4

   以前の 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

   Show more

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.16 クラスター環境で稼働する永続プロパティ設定

1. hibernate.session_factory_name 値を一意名に設定します。この名前は、JBoss Enterprise Application Platform インスタンス上の全アプリケーションデプロイメントにわたって一意である必要があります。例は次の通りです。

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

   Copy to Clipboard Toggle word wrap
2. hibernate.ejb.entitymanager_factory_name 値を一意名に設定します。この名前は、JBoss Enterprise Application Platform インスタンス上の全アプリケーションデプロイメントにわたって一意である必要があります。例は次の通りです。

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

   Copy to Clipboard Toggle word wrap

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

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

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

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

   Copy to Clipboard Toggle word wrap

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

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

     Copy to Clipboard Toggle word wrap
   • ALL の場合、キャッシュ不可能であるとマークされていてもエンティティーは常にキャッシュされます。

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

     Copy to Clipboard Toggle word wrap

2. JBoss Enterprise Application Platform 6 のネイティブ Hibernate アプリケーションに対して Infinispan を設定する

   JBoss Enterprise Application Platform 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"/>
   
   

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

1. デフォルトの ValidatorFactory へのアクセス

   JBoss Enterprise Application Platform 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.19 JMS ブリッジの設定

1. 次の例に従って、SAR が含まれるように Enterprise Application Platform 5 の deploy ディレクトリにサブディレクトリを作成します。 EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar
2. EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/ に META-INF という名前のサブディレクトリを作成します。
3. 以下と似た情報が含まれる jboss-service.xml ファイルをEAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/META-INF/ ディレクトリに作成します。

   <server>
      <loader-repository>
         com.example:archive=unique-archive-name
         <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
      </loader-repository> 
   
      <!-- Enterprise Application Platform 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>
   
   

   Copy to Clipboard Toggle word wrap

   注記

   <load-repository> は SAR に分離されたクラスローダーが確実に存在するようにします。JNDI ルックアップとブリッジの「ターゲット」の両方に、パスワードが 「jbosspass」であるユーザー 「jbossuser」のセキュリティー認証情報が含まれていることに注意してください。これは、JBoss Enterprise Application Platform 6 はデフォルトで保護されているからです。パスワードが 「jbosspass」であるユーザー「jbossuser」は guest ロールを持ち、EAP_HOME/bin/add_user.sh スクリプトを使用して ApplicationRealm に作成されました。
4. 次の JAR を EAP_HOME/modules/ ディレクトリから EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/ ディレクトリへコピーします。 VERSION_NUMBER を JBoss Enterprise Application Platform 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 クラスは Enterprise Application Platform 5.x のクラスと競合するため、単にそのまま EAP_HOME/bin/client/jboss-client.jar をコピーしないようにしてください。

手順3.20 開始する前に

1. クライアントとサーバーをシャットダウンします。
2. JBoss Messaging データのバックアップコピーを作成します。

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

1. 設定の転送

   最初に、既存の JBoss Messaging 設定を Enterprise Application Platform 設定に転送する必要があります。以下の設定が、 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 を使用する場合は、コードの変更が必要ありません。ただし、アプリケーションが JBoss Messaging に固有な機能を使用する場合は、HornetQ で利用可能な同等の機能を使用するようコードを変更する必要があります。
   HornetQ でメッセージングを設定する方法の詳細については、 「HornetQ でのメッセージングの設定」 を参照してください。

3. ブリッジおよび JMS 管理オブジェクトの移行

   JBoss Messaging は、 Managed Bean サービスを使用してブリッジと接続ファクトリーなどの JMS オブジェクト、キュー、およびトピックを設定します。HornetQ は POJO (Plain Old Java Object) を使用してこれらのオブジェクトを設定します。HornetQ で同等のパラメーターを使用するには設定パラメーターを更新する必要があります。

4. 既存のメッセージの移行

   JBoss Messaging データベースのすべてのメッセージを HornetQ バインディングに移動します。

手順3.22

1. クラスタリグが有効な状態で JBoss Enterprise Application Platform 6 を起動する

   JBoss Enterprise Application Platform 5.x でクラスタリングを有効にするには、次のように all プロファイル (またはその派生プロファイル) を使用してサーバーインスタンスを起動する必要がありました。
   $ EAP5_HOME/bin/run.sh -c all
   JBoss Enterprise Application Platform 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>

      Copy to Clipboard Toggle word wrap

   2. スタンドアロンサーバーに対してクラスタリングを有効にする

      スタンドアロンサーバーに対してクラスタリングを有効にするには、次のように適切な設定ファイルを使用してサーバーを起動します。 $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml

2. バインドアドレスの指定

   JBoss Enterprise Application Platform 5.x では、通常 $ EAP_HOME/bin/run.sh -c all -b 192.168.0.2 のように -b コマンドライン引数を用いてクラスタリングに使用するバインドアドレスを指定しました。
   JBoss Enterprise Application Platform 6 では、JBoss Enterprise Application Platform 6 の設定ファイル内の関連するソケットバインディングによってバインドアドレスが明示的に定義されます。ドメインコントローラーを用いて起動したサーバーの場合、バインドアドレスは domain/configuration/host.xml ファイル内で指定されます。スタンドアロンサーバーの場合、バインドアドレスは standalone-ha.xml ファイル内で指定されます。

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   上記の例では、ha-sockets ソケットバインディンググループ内のすべてのソケットに対するデフォルトインターフェースに public インターフェースが指定されています。

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

   JBoss Enterprise Application Platform 5.x では、次のようにコマンドライン引数 -u を使用してクラスター内の通信に使用されるマルチキャストアドレスを指定することができました。 同様に、引数 -m を使用してクラスター内の通信に使用されるポートを指定することができました。 $ EAP_HOME/bin/run.sh -c all -u 228.11.11.11 -m 45688
   JBoss Enterprise Application Platform 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>

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   コマンドラインでマルチキャストアドレスとポートを指定したい場合、マルチキャストアドレスとポートをシステムプロパティーとして定義した後、サーバー起動時にこれらのプロパティーをコマンドライン上で使用します。次の例では、 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}"/>
   

   Copy to Clipboard Toggle word wrap

   その後、次のコマンドライン引数を使用してサーバーを起動できます。 $ EAP_HOME/bin/domain.sh -Djboss.mcast.addr=228.11.11.11 -Djboss.mcast.port=45688

4. 代替のプロトコルスタックの使用

   JBoss Enterprise Application Platform 5.x では、jboss.default.jgroups.stack システムプロパティーを使用してすべてのクラスタリングサービスに使用されるデフォルトのプロトコルスタックを操作することができました。 $ EAP_HOME/bin/run.sh -c all -Djboss.default.jgroups.stack=tcp
   JBoss Enterprise Application Platform 6 では、domain.xml または standalone-ha.xml 内の JGroups サブシステムによってデフォルトのプロトコルスタックが定義されます。

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

   Copy to Clipboard Toggle word wrap

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

1. HA シングルトンサービスアプリケーションの作成

   シングルトンサービスとしてデプロイされる SingletonService デコレーターでラッピングされたサービスの簡単な例は次の通りです。

   1. シングルトンサービスを作成します。

      package com.mycompany.hasingleton.service.ejb;
      
      import java.util.concurrent.atomic.AtomicBoolean;
      import java.util.logging.Logger;
      
      import org.jboss.as.server.ServerEnvironment;
      import org.jboss.msc.inject.Injector;
      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;
      import org.jboss.msc.value.InjectedValue;
      
      /**
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      public class EnvironmentService implements Service<String> {
          private static final Logger LOGGER = Logger.getLogger(EnvironmentService.class.getCanonicalName());
          public static final ServiceName SINGLETON_SERVICE_NAME = ServiceName.JBOSS.append("quickstart", "ha", "singleton");
          /**
           * A flag whether the service is started.
           */
          private final AtomicBoolean started = new AtomicBoolean(false);
      
          private String nodeName;
      
          private final InjectedValue<ServerEnvironment> env = new InjectedValue<ServerEnvironment>();
      
          public Injector<ServerEnvironment> getEnvInjector() {
              return this.env;
          }
      
          /**
           * @return the name of the server node
           */
          public String getValue() throws IllegalStateException, IllegalArgumentException {
              if (!started.get()) {
                  throw new IllegalStateException("The service '" + this.getClass().getName() + "' is not ready!");
              }
              return this.nodeName;
          }
      
          public void start(StartContext arg0) throws StartException {
              if (!started.compareAndSet(false, true)) {
                  throw new StartException("The service is still started!");
              }
              LOGGER.info("Start service '" + this.getClass().getName() + "'");
              this.nodeName = this.env.getValue().getNodeName();
          }
      
          public void stop(StopContext arg0) {
              if (!started.compareAndSet(true, false)) {
                  LOGGER.warning("The service '" + this.getClass().getName() + "' is not active!");
              } else {
                  LOGGER.info("Stop service '" + this.getClass().getName() + "'");
              }
          }
      }
      

      Copy to Clipboard Toggle word wrap
   2. サーバー起動時にサービスを SingletonService として開始するシングルトン EJB を作成します。

      package com.mycompany.hasingleton.service.ejb;
      
      import java.util.Collection;
      import java.util.EnumSet;
      
      import javax.annotation.PostConstruct;
      import javax.annotation.PreDestroy;
      import javax.ejb.Singleton;
      import javax.ejb.Startup;
      
      import org.jboss.as.clustering.singleton.SingletonService;
      import org.jboss.as.server.CurrentServiceContainer;
      import org.jboss.as.server.ServerEnvironment;
      import org.jboss.as.server.ServerEnvironmentService;
      import org.jboss.msc.service.AbstractServiceListener;
      import org.jboss.msc.service.ServiceController;
      import org.jboss.msc.service.ServiceController.Transition;
      import org.jboss.msc.service.ServiceListener;
      import org.slf4j.Logger;
      import org.slf4j.LoggerFactory;
      
      
      /**
       * A Singleton EJB to create the SingletonService during startup.
       * 
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      @Singleton
      @Startup
      public class StartupSingleton {
        private static final Logger LOGGER = LoggerFactory.getLogger(StartupSingleton.class);
      
        /**
         * Create the Service and wait until it is started.<br/>
         * Will log a message if the service will not start in 10sec. 
         */
        @PostConstruct
        protected void startup() {
          LOGGER.info("StartupSingleton will be initialized!");
      
          EnvironmentService service = new EnvironmentService();
          SingletonService<String> singleton = new SingletonService<String>(service, EnvironmentService.SINGLETON_SERVICE_NAME);
          // if there is a node where the Singleton should deployed the election policy might set,
          // otherwise the JGroups coordinator will start it
          //singleton.setElectionPolicy(new PreferredSingletonElectionPolicy(new NamePreference("node2/cluster"), new SimpleSingletonElectionPolicy()));
          ServiceController<String> controller = singleton.build(CurrentServiceContainer.getServiceContainer())
              .addDependency(ServerEnvironmentService.SERVICE_NAME, ServerEnvironment.class, service.getEnvInjector())
              .install();
      
          controller.setMode(ServiceController.Mode.ACTIVE);
          try {
            wait(controller, EnumSet.of(ServiceController.State.DOWN, ServiceController.State.STARTING), ServiceController.State.UP);
            LOGGER.info("StartupSingleton has started the Service");
          } catch (IllegalStateException e) {
            LOGGER.warn("Singleton Service {} not started, are you sure to start in a cluster (HA) environment?",EnvironmentService.SINGLETON_SERVICE_NAME);
          }
        }
      
        /**
         * Remove the service during undeploy or shutdown
         */
        @PreDestroy
        protected void destroy() {
          LOGGER.info("StartupSingleton will be removed!");
          ServiceController<?> controller = CurrentServiceContainer.getServiceContainer().getRequiredService(EnvironmentService.SINGLETON_SERVICE_NAME);
          controller.setMode(ServiceController.Mode.REMOVE);
          try {
            wait(controller, EnumSet.of(ServiceController.State.UP, ServiceController.State.STOPPING, ServiceController.State.DOWN), ServiceController.State.REMOVED);
          } catch (IllegalStateException e) {
            LOGGER.warn("Singleton Service {} has not be stopped correctly!",EnvironmentService.SINGLETON_SERVICE_NAME);
          }
        }
      
        private static <T> void wait(ServiceController<T> controller, Collection<ServiceController.State> expectedStates, ServiceController.State targetState) {
          if (controller.getState() != targetState) {
            ServiceListener<T> listener = new NotifyingServiceListener<T>();
            controller.addListener(listener);
            try {
              synchronized (controller) {
                int maxRetry = 2;
                while (expectedStates.contains(controller.getState()) && maxRetry > 0) {
                  LOGGER.info("Service controller state is {}, waiting for transition to {}", new Object[] {controller.getState(), targetState});
                  controller.wait(5000);
                  maxRetry--;
                }
              }
            } catch (InterruptedException e) {
              LOGGER.warn("Wait on startup is interrupted!");
              Thread.currentThread().interrupt();
            }
            controller.removeListener(listener);
            ServiceController.State state = controller.getState();
            LOGGER.info("Service controller state is now {}",state);
            if (state != targetState) {
              throw new IllegalStateException(String.format("Failed to wait for state to transition to %s.  Current state is %s", targetState, state), controller.getStartException());
            }
          }
        }
      
        private static class NotifyingServiceListener<T> extends AbstractServiceListener<T> {
          @Override
          public void transition(ServiceController<? extends T> controller, Transition transition) {
            synchronized (controller) {
              controller.notify();
            }
          }
        }
      }
      

      Copy to Clipboard Toggle word wrap

   3. クライアントよりサービスへアクセスするためステートレスセッション Bean を作成します。

      package com.mycompany.hasingleton.service.ejb;
      
      import javax.ejb.Stateless;
      
      import org.jboss.as.server.CurrentServiceContainer;
      import org.jboss.msc.service.ServiceController;
      import org.slf4j.Logger;
      import org.slf4j.LoggerFactory;
      
      /**
       * A simple SLSB to access the internal SingletonService.
       * 
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      @Stateless
      public class ServiceAccessBean implements ServiceAccess {
          private static final Logger LOGGER = LoggerFactory.getLogger(ServiceAccessBean.class);
      
          public String getNodeNameOfService() {
              LOGGER.info("getNodeNameOfService() is called()");
              ServiceController<?> service = CurrentServiceContainer.getServiceContainer().getService(
                      EnvironmentService.SINGLETON_SERVICE_NAME);
              LOGGER.debug("SERVICE {}", service);
              if (service != null) {
                  return (String) service.getValue();
              } else {
                  throw new IllegalStateException("Service '" + EnvironmentService.SINGLETON_SERVICE_NAME + "' not found!");
              }
          }
      }
      

      Copy to Clipboard Toggle word wrap

   4. SingletonService のビジネスロジックインターフェースを作成します。

      package com.mycompany.hasingleton.service.ejb;
      
      import javax.ejb.Remote;
      
      /**
       * Business interface to access the SingletonService via this EJB
       * 
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      @Remote
      public interface ServiceAccess {
          public abstract String getNodeNameOfService();
      } 
      
      

      Copy to Clipboard Toggle word wrap

2. クラスタリングが有効な状態で各 Jboss Enterprise Application Platform 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-groups>
      

      Copy to Clipboard Toggle word wrap

      次のように host.xml ファイルを変更します。

      <servers>
        <server name="server-one" group="main-server-group" auto-start="false"/>
        <server name="server-two" group="distinct2">
          <socket-bindings port-offset="100"/>
        </server>
      <servers>
      

      Copy to Clipboard Toggle word wrap

      その後、次のようにサーバーを起動します。
      • Linux では EAP_HOME/bin/domain.sh と入力します。
      • Microsoft Windows では EAP_HOME\bin\domain.bat と入力します。

   2. スタンドアローンサーバーに対してクラスタリングを有効にする

      スタンドアローンサーバーに対してクラスタリングを有効にするには、次のようにノード名と standalone-ha.xml 設定ファイルを使用してサーバーを起動します。
      • Linux では EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME と入力します。
      • Microsoft Windows では EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME と入力します。

   注記

   1 つのマシン上で複数のサーバーが実行されている時にポートの競合が発生しないようにするため、別のインターフェースでバインドするように各サーバーインスタンスに対して standalone-ha.xml ファイルを設定します。または、コマンドラインで -Djboss.socket.binding.port-offset=100 のような引数を使用し、ポートオフセットを持つ後続のサーバーインスタンスを開始して対応することも可能です 。

3. アプリケーションをサーバーにデプロイする

   Maven を使用してアプリケーションをデプロイする場合は、次の Maven コマンドを使用してデフォルトのポートで稼働しているサーバーへデプロイします。
   mvn clean install jboss-as:deploy
   追加のサーバーをデプロイするには、サーバー名とポート番号をコマンドラインに渡します。
   mvn clean package jboss-as:deploy -Ddeploy.hostname=localhost -Ddeploy.port=10099

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

1. 必要なプロジェクト依存関係の追加

   必要な依存関係が含まれるようにするため、プロジェクトの pom.xml を更新する必要があります。

2. jboss-ejb-client.properties ファイルの追加

   JBoss EJB クライアント API は、JNDI サービスの接続情報が含まれる jboss-ejb-client.properties という名前のプロジェクトのルートにファイルがあることを想定します。このファイルを以下の内容と共にプロジェクトの src/resources/ ディレクトリに追加します。

   # Set this to true for SSL
   remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
   remote.connections=default
   # Uncomment this 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 other 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
   

   Copy to Clipboard Toggle word wrap
   ホスト名とポートを変更してサーバーと一致するようにします。4447 がデフォルトのポート番号です。 安全な接続の場合、SSL_ENABLED 行を true に設定し、 SSL_STARTTLS 行をアンコメントします。コンテナ内のリモーティングインターフェースは同じポートを使用して安全な接続と安全でない接続をサポートします。

3. リモートビジネスインターフェースの依存関係の追加

   セッション Bean のリモートビジネスインターフェースに対する pom.xml に Maven の依存関係を追加します。

   <dependency>
      <groupId>org.jboss.as.quickstarts</groupId>
      <artifactId>jboss-as-ejb-remote-server-side</artifactId>
      <type>ejb-client</type>
      <version>7.1.0.CR1-SNAPSHOT</version>
   </dependency>

   Copy to Clipboard Toggle word wrap

手順3.25 JNDI を使用して Bean プロキシを取得し、Bean のメソッドを呼び出す

1. チェック例外の処理

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

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

   Copy to Clipboard Toggle word wrap
   JNDI サービスの接続プロパティーは jboss-ejb-client.properties ファイルより読み取られます。

3. JNDI コンテキストの lookup() メソッドを使用した Bean プロキシの取得

   Bean プロキシの lookup() メソッドを呼び出し、必要なセッション Bean の JNDI 名 へ渡します。これにより、呼び出したいメソッドが含まれるリモートビジネスインターフェースのタイプへキャストされなければならないオブジェクトが返されます。

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

   Copy to Clipboard Toggle word wrap
   セッション Bean の 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);

   Copy to Clipboard Toggle word wrap
   メソッド呼び出し要求が実行されるサーバー上で、プロキシ Bean がメソッド呼び出し要求をセッション Bean へ渡します。結果はプロキシ Bean へ返され、プロキシ Bean によって結果が呼び出し側へ返されます。プロキシ Bean とリモートセッション Bean 間の通信は呼び出し側に透過的です。

手順3.26 JBoss Enterprise Application Platform 6 で EJB 2.x を起動する

1. JNDI 名前空間の新しいルールを使用するようコードを変更する

   EJB 3.0 と同様に、EJB 2.x でも完全な JNDI プレフィックスを使用する必要があります。新しい JNDI 名前空間ルールやコード例の詳細は 「アプリケーションの JNDI 名前空間名の更新」 を参照してください。
   以前のリリースから JNDI 名前空間を更新する方法を表す例は 「以前のリリースにおける JNDI 名前空間の例、また JBoss Enterprise Application Platform 6 での名前空間の指定方法」 にあります。

2. JBoss AOP インターセプターの置換

   JBoss AOP (Aspect Oriented Programming) は JBoss Enterprise Application Platform 6 には含まれていません。以前のリリースでは、JBoss AOP は EJB コンテナによって使用されていましたが、Enterprise Application Platform 6 では EJB コンテナは新しいメカニズムを使用します。アプリケーションが JBoss AOP を使用する場合、次のようにアプリケーションコードを変更する必要があります。

   • ejb3-interceptors-aop.xml で設定された標準的な EJB3 設定は、サーバー設定ファイルで設定されるようになりました。スタンドアロンサーバーの場合、このファイルは standalone/configuration/standalone.xml ファイルになります。サーバーが管理ドメインで実行されている場合は domain/configuration/domain.xml ファイルになります。
   • AOP インターセプターを EJB レイヤーへ統合するアプリケーションは、 EJB3 インターセプターと CDI を使用するよう再設計する必要があります。サーバー側のインターセプターは EJB3 インターセプターへ変更することができますが、Enterprise Application Platform 6 ではクライアント側のインターセプターがありません。

3. jboss-web.xml ファイル記述子の変更

   各 <ejb-ref> に対する <jndi-name> を変更し、新しい JNDI 完全修飾ルックアップ形式を使用するようにします。

4. jboss.xml デプロイメント記述子ファイルの置換

   Java Enterprise Edition (EE) によって定義される ejb3-jar.xml デプロイメント記述子によって提供される機能を上書きしたり追加するため、jboss.xml は jboss-ejb3.xml デプロイメント記述子に置き換えられました。この新ファイルは jboss.xml との互換性がないため、jboss.xml はデプロイメントで無視されます。

5. 完全プロファイルでのサーバーの起動

   EJB 2.x には Java Enterprise Edition 6 の完全プロファイルが必要となります。完全プロファイルで JBoss Enterprise Application Platform 6 を起動するには、サーバーの起動時に引数 -c standalone-full.xml をコマンドラインに渡します。

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

1. データソース設定の更新

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

   • JBoss Enterprise Application Platform 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>

     Copy to Clipboard Toggle word wrap
   • 既存のデータベースを維持したい場合は、データソースの定義を EAP_HOME/standalone/configuration/standalone.xml ファイルに追加することができます。以下の定義は JBoss Enterprise Application Platform 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>

     Copy to Clipboard Toggle word wrap
   • jbossadmin コマンドラインインターフェースを使用してデータソースの定義を追加することも可能です。データソースを追加するために使用しなければならない構文の例は次の通りです。行の最後にある "\" はコマンドが次の行に続くことを表しています。

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

     $ 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
     

     Copy to Clipboard Toggle word wrap

   データソースの設定方法の詳細は 「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>

   Copy to Clipboard Toggle word wrap

   アプリケーションがサードパーティーのロギングフレームワークを使用する場合は、 「ロギング依存関係の編集」 に記載されている依存関係を追加する必要があります。

3. 外部フレームワークまたは他の場所より依存するアーカイブをコピーする

   Seam 2.2 アプリケーションが Hibernate 3.x を使用する場合でも、JBoss Enterprise Application Platform 6 にパッケージ化されている Hibernate 4 モジュールを使用してアプリケーションを実行することが可能ですが、存在しない Hibernate 3.x クラスがあるため、以前の Hibernate JAR を 1 つ以上 /lib ディレクトリへコピーする必要がある場合があります。Hibernate クラスを示す ClassNotFoundExceptions や ClassCastExceptions が発生した場合、次のように 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>

   Copy to Clipboard Toggle word wrap

4. Seam 2.2 JNDI エラーのデバッグおよび解決

   Seam 2.2 アプリケーションを移行する時に次のような javax.naming.NameNotFoundException エラーがログに記録されることがあります。

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

   Copy to Clipboard Toggle word wrap

   コード全体の 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"/>
      

      Copy to Clipboard Toggle word wrap

   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
      

      Copy to Clipboard Toggle word wrap

   3. component 要素の追加

      ログの各 JNDI バインディング INFO メッセージに対して、一致する component 要素を components.xml ファイルに追加します。

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

      Copy to Clipboard Toggle word wrap
   移行の問題に関するデバッグや解決方法の詳細は 「移行の問題のデバッグと解決」 を参照してください。