Menu Close

第3章 アプリケーションの移行

3.1. ほとんどのアプリケーションで必要な変更

3.1.1. ほとんどのアプリケーションで必要な変更の確認

JBoss Enterprise Application Platform 6 のクラスローディングと設定の変更はほとんどのアプリケーションに影響します。また、Enterprise Application Platform 6 は新しい標準の移植可能な JNDI ネーミング構文を使用します。これらの変更はほとんどのアプリケーションに影響するため、アプリケーションを移行する際、最初に以下の情報を確認することが推奨されます。

3.1.2. クラスローディングの変更

3.1.2.1. クラスローディングの変更によるアプリケーションの更新

モジュラークラスローディングは JBoss Enterprise Application Platform 6 における主な変更の 1 つで、ほぼすべてのアプリケーションが影響を受けます。アプリケーションを移行する際、最初に次の情報を確認してください。
  1. 最初に、アプリケーションのパッケージと依存関係を確認します。詳細は 「クラスローディングの変更によるアプリケーション依存関係の更新」を参照してください。
  2. アプリケーションがロギングを行う場合、正しいモジュールの依存関係を指定する必要があります。手順の詳細は 「ロギング依存関係の編集」 を参照してください。
  3. モジュラークラスローディングの変更により、EAR または WAR のパッケージ構造を変更する必要がある場合があります。詳細は 「EAR および WAR パッケージの編集」 を参照してください。

3.1.2.2. モジュールの依存関係を理解する

概要

モジュールは独自のクラスと、明示的または暗黙的な依存関係を持つモジュールのクラスのみにアクセスすることが可能です。

手順3.1 タスク

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

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

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

3.1.2.3. クラスローディングの変更によるアプリケーション依存関係の更新

概要

JBoss Enterprise Application Platform 6 のクラスローディングは以前のバージョンの JBoss Application Server とは大きく異なっています。JBoss Enterprise Application Platform 6 のクラスローディングは JBoss モジュールプロジェクトが基盤となっています。すべての JAR をフラットなクラスパスにロードする単一の階層的なクラスローダーではなく、各ライブラリが依存するモジュールに対してのみリンクするモジュールとなります。また、Enterprise Application Platform 6 のデプロイメントもモジュールで、クラスの依存関係が明示的に定義されている場合を除き、アプリケーションサーバーの JAR に定義されているクラスへアクセスできません。アプリケーションサーバーによって定義されるモジュール依存関係の一部は自動的に設定されます。例えば、Java EE アプリケーションをデプロイする場合、Java EE API の依存関係は自動的にモジュールに追加されます。自動的に追加される依存関係の完全一覧は、JBoss Enterprise Application Platform 6 開発ガイドの「クラストーディングとモジュール」の章に記載されている暗黙的なモジュール依存関係の説明を参照してください。

タスク

アプリケーションを JBoss Enterprise Application Platform 6 に移行する際、モジュラークラスローディングの変更に伴い、以下のタスクを 1 つ以上実行する必要がある場合があります。

3.1.3. 設定ファイルの変更

3.1.3.1. JBoss Enterprise Application Platform 6 のクラスローディングを制御するファイルの作成または変更

概要

モジュラークラスローディングを使用する JBoss Enterprise Application Platform 6 の変更に伴い、依存関係を追加したり自動的な依存関係がロードされないようにするため、1 つ以上のファイルを作成または変更する必要がある場合があります。クラスローディングの優先度については、JBoss Enterprise Application Platform 6 開発ガイドの「クラスローディングとモジュール」の章を参照してください。

JBoss Enterprise Application Platform 6 のクラスローディングを制御するために使用されるファイルは次の通りです。
jboss-web.xml
jboss-web.xml ファイルの <class-loading> 要素が定義されている場合はこれを削除する必要があります。 JBoss Enterprise Application Platform 5 でこの要素によって引き起こされた動作は、JBoss Enterprise Application Platform 6 ではクラスローディングのデフォルト動作ととなっているため、この要素が必要なくなりました。この要素を削除しないと、サーバーログに ParseError と XMLStreamException が記録されます。
これは、コメントアウトされた jboss-web.xml ファイルの <class-loading> 要素の例になります。

<jboss-web>  
<!-- 
    <class-loading java2ClassLoadingCompliance="false">
        <loader-repository>
            seam.jboss.org:loader=MyApplication
            <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
        </loader-repository>
    </class-loading>
 -->
 </jboss-web>

MANIFEST.MF
手作業による編集
アプリケーションが使用するコンポーネントやモジュールによって異なりますが、このファイルに 1 つ以上の依存関係を追加する必要がある場合があります。依存関係は Dependencies Class-Path エントリのどちらかに追加します。
開発者によって編集された MANIFEST.MF の例は次の通りです。
Manifest-Version: 1.0
Dependencies: org.jboss.logmanager
Class-Path: OrderManagerEJB.jar

このファイルを編集する時、必ずファイルの最後にニューライン文字があるようにしてください。
Maven を使用した生成
Maven を使用する場合、pom.xml ファイルを編集して MANIFEST.MF ファイルの依存関係を生成する必要があります。アプリケーションによって EJB 3.0 が使用される場合、 pom.xml ファイルに次のようなセクションが含まれることがあります。
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ejb-plugin</artifactId>
    <configuration>
        <ejbVersion>3.0</ejbVersion>
    </configuration>
</plugin>
EJB 3.0 コードがorg.apache.commons.log を使用する場合、MANIFEST.MF ファイルにこの依存関係が存在しなければなりません。この依存関係を生成するには、次のように <plugin> 要素を pom.xml ファイルに追加します。
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ejb-plugin</artifactId>
    <configuration>
        <ejbVersion>3.0</ejbVersion>
        <archive>
            <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
        </archive>
    </configuration>
</plugin>
上記の例では、次の依存関係エントリのみが src/main/resourcres/MANIFEST.MF ファイルに含まれる必要があります。
Dependencies: org.apache.commons.logging
Maven は完全な MANIFEST.MF ファイルを生成します。
Manifest-Version: 1.0
Dependencies: org.apache.commons.logging
jboss-deployment-structure.xml
このファイルは、クラスローディングを細かく制御するために使用される JBoss 固有のデプロイメント記述子です。MANIFEST.MF と同様に、このファイルを使用して依存関係を追加することが可能です。また、自動的な依存関係が追加されないようにしたり、追加のモジュールを定義することが可能で、EAR デプロイメントの分離されたクラスローディング動作を変更したり、追加のリソースルートをモジュールへ追加することもできます。
JSF 1.2 モジュールの依存関係を追加し、JSF 2.0 モジュールが自動的にローディングされないようにする jboss-deployment-structure.xml ファイルの例は次の通りです。
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
  <deployment>
      <dependencies>
        <module name="javax.faces.api" slot="1.2" export="true"/>
              <module name="com.sun.jsf-impl" slot="1.2" export="true"/>
      </dependencies>
  </deployment>
  <sub-deployment name="jboss-seam-booking.war">
    <exclusions>
        <module name="javax.faces.api" slot="main"/>
              <module name="com.sun.jsf-impl" slot="main"/>
      </exclusions>
      <dependencies>
        <module name="javax.faces.api" slot="1.2"/>
              <module name="com.sun.jsf-impl" slot="1.2"/>
      </dependencies>
  </sub-deployment>
</jboss-deployment-structure>
このファイルに関する詳細は 「Jboss-deployment-structure.xml」 を参照してください。
application.xml
以前のバージョンの JBoss Enterprise Application Platform では、jboss-app.xml ファイルを使用して EAR 内でデプロイメントの順番を制御しました。本バージョンより Java EE6 仕様が application.xml<initialize-in-order> 要素を提供するようになり、これにより EAR 内の Java EE モジュールがデプロイされる順番を制御することができます。
ほとんどの場合、デプロイメントの順番を指定する必要はありません。依存関係の挿入と、外部モジュールのコンポーネントを参照する resource-refs がアプリケーションによって使用される場合、アプリケーションサーバーは適切で最適なコンポーネントの順番を暗黙的に決定できるため、ほとんどの場合で <initialize-in-order> 要素は必要ありません。
myApp.ear 内に myBeans.jarmyApp.war を持つアプリケーションがあるとしましょう。myApp.war@EJB のサーブレットが myBeans.jar より Bean を挿入します。この場合、必ずサーブレットが起動する前に EJB コンポーネントを使用できるようにし、<initialize-in-order> 要素を使用する必要がないことをアプリケーションサーバーが適切に認識します。
しかし、次のようなレガシーの JNDI ルックアップスタイルのリモート参照を使用し、Bean へアクセスする場合はモジュールの順番を指定する必要がある場合があります。
init() {
  Context ctx = new InitialContext();
  ctx.lookup("TheBeanInMyBeansModule");
}
この場合、EJB コンポーネントが myBeans.jar にあることをサーバーが判断できないため、myBeans.jar のコンポーネントがmyApp.war のコンポーネントの前に初期化され開始されるよう強制する必要があります。これには、 <initialize-in-order> 要素を true に設定し、myBeans.jar モジュールと myApp.war モジュールの順番を application.xml ファイルに指定します。
以下は <initialize-in-order> 要素を使用してデプロイメントの順番を制御する例になります。 myBeans.jarmyApp.war ファイルの前にデプロイされます。
<application xmlns="http://java.sun.com/xml/ns/javaee" 
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="6"
             xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
             http://java.sun.com/xml/ns/javaee/application_6.xsd">
    <application-name>myApp</application-name>
    <initialize-in-order>true</initialize-in-order>
    <module>
        <ejb>myBeans.jar</ejb>
    </module>
    <module>
        <web>
            <web-uri>myApp.war</web-uri>
            <context-root>myApp</context-root>
        </web>
    </module>
</application>
application.xml ファイルのスキーマは http://java.sun.com/xml/ns/javaee/application_6.xsd を参照してください。

注記

<initialize-in-order> 要素を true に設定するとデプロイメントの速度が遅くなることに注意してください。デプロイメントを最適化するためのコンテナの柔軟性が高いため、依存関係の挿入や resource-refs を使用して適切な依存関係を定義する方法が推奨されます。
jboss-ejb3.xml
Java Enterprise Edition (EE) によって定義される ejb3-jar.xml デプロイメント記述子によって提供される機能を上書きしたり追加するため、jboss.xmljboss-ejb3.xml デプロイメント記述子に置き換えられました。この新ファイルは jboss.xml との互換性がないため、jboss.xml はデプロイメントで無視されます。
login-config.xml
login-config.xml ファイルはセキュリティー設定で使用されないようになりました。セキュリティーはサーバー設定ファイルの <security-domain> 要素に設定されるようになりました。スタンドアロンサーバーでは standalone/configuration/standalone.xml ファイルになります。管理ドメインでサーバーを実行している場合は domain/configuration/domain.xml ファイルになります。

3.1.3.2. Jboss-deployment-structure.xml

jboss-deployment-structure.xml は JBoss Enterprise Application Platform 6 の新しい任意のデプロイメント記述子です。このデプロイメント記述子はデプロイメントのクラスローディングを制御できるようにします。
このデプロイメント記述子の XML スキーマは EAP_HOME/docs/schema/jboss-deployment-structure-1_0.xsd にあります。

3.1.3.3. 新しいモジュラークラスローディングシステムのパッケージリソース

概要

以前のバージョンの Enterprise Application Platform では、WEB-INF/ ディレクトリ内のすべてのリソースが WAR クラスパスに追加されました。JBoss Enterprise Application Platform 6 では、Web アプリケーションのアーティファクトは WEB-INF/classes および WEB-INF/lib ディレクトリからのみロードされます。指定の場所でアプリケーションアーティファクトのパッケージ化に失敗した場合、ClassNotFoundExceptionNoClassDefError などのランタイムエラーが発生します。

これらのクラスローディングエラーを解決するには、アプリケーションアーカイブの構造を編集するか、カスタムモジュールを定義する必要があります。

リソースパッケージの編集
アプリケーションのみがリソースを使用できるようにするには、プロパティーファイル、JAR、およびその他のアーティファクトを WEB-INF/classes/ または WEB-INF/lib/ ディレクトリへ移動し、WAR とバンドルします。この方法の詳細は 「ResourceBundle プロパティーの場所変更」 を参照してください。
カスタムモジュールの作成
Enterprise Application Platform サーバー上で実行されているすべてのアプリケーションが、カスタムリソースを使用できるようにするには、カスタムモジュールを作成する必要があります。この方法の詳細は 「カスタムモジュールの作成」 を参照してください。

3.1.3.4. ResourceBundle プロパティーの場所変更

概要

以前のバージョンの JBoss Enterprise Application Platform では、EAP_HOME/server/SERVER_NAME/conf/ ディレクトリはクラスパスに存在し、アプリケーションによる使用が可能でした。このプロパティーを JBoss Enterprise Application Platform 6 のアプリケーションのクラスパスで使用できるようにするには、アプリケーション内でパッケージ化する必要があります。

手順3.2

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

3.1.3.5. カスタムモジュールの作成

次の手順では、Enterprise Application Platform サーバー上で実行されているすべてのアプリケーションがプロパティーファイルやその他のリソースを使用できるようにするため、カスタムモジュールを作成する方法について説明します。

手順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
          $ Connected to standalone controller at localhost:9999
          
        • Windows の場合は、コマンドラインで以下を入力します。
          C:\>EAP_HOME\bin\jboss-cli.bat --connect
          C:\> 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.1.4. ロギングの変更

3.1.4.1. ロギング依存関係の編集

概要

JBoss LogManager はすべてのロギングフレームワークのフロントエンドをサポートするため、現在のロギングコードを保持することも、新しい JBoss のロギングインフラストラクチャーへ移行することも可能です。モジュラークラスローディングが変更されたため、いずれの場合でもアプリケーションを変更して必要な依存関係を追加する必要があるでしょう。

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

3.1.4.2. サードパーティーロギングフレームワークのアプリケーションコードの更新

概要

JBoss Enterprise Application Platform 6 では Apache Commons Logging、Apache log4j、SLF4J、Java Logging などの一般的なサードパーティーフレームワークのロギング依存関係はデフォルトで追加されています。しかし、log4j を使用し、ロギングサブシステムを使用してハンドラー (アペンダー) を設定したくない場合は Enterprise Application Platform の log4j モジュールを除外する必要があります。

手順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>
    
  2. WAR をデプロイする場合は jboss-deployment-structure.xml ファイルを WEB-INF/ ディレクトリに置きます。EAR をデプロイする場合は jboss-deployment-structure.xml ファイルを META-INF/ ディレクトリに置きます。
  3. デプロイメントの lib/ ディレクトリに log4j.properties または log4j.xml ファイルが含まれるようにします。
  4. アプリケーションをデプロイします。

注記

log4j 設定ファイルを使用すると、ランタイム時に log4j ロギング設定を変更することができなくなります。

3.1.4.3. 新しい JBoss ロギングフレームワークを使用したコードの変更

概要

新しいフレームワークを使用するには、次のようにインポートとコードを変更します。

手順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);
    }
    
  2. ロギング依存関係の追加

    JBoss ロギングクラスが含まれる JAR は org.jboss.logging という名前のモジュールにあります。MANIFEST-MF ファイルは次のようになるはずです。
    Manifest-Version: 1.0
    Dependencies: org.jboss.logging
    
    モジュール依存関係の検索方法に関する詳細は 「クラスローディングの変更によるアプリケーション依存関係の更新」「移行の問題のデバッグと解決」 を参照してください。

3.1.5. アプリケーションパッケージの変更

3.1.5.1. EAR および WAR パッケージの編集

概要

アプリケーションを移行する際、モジュラークラスローディングの変更に伴い、EAR または WAR のパッケージ構造を変更する必要がある場合があります。モジュール依存関係は次の順序でロードされます。

  1. システム依存関係
  2. ユーザー依存関係
  3. ローカルリソース
  4. デプロイメント間の依存性

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

3.1.6. データソースおよびリソースアダプター設定の変更

3.1.6.1. 設定変更によるアプリケーションの更新

JBoss Enterprise Application Platform 5 ではサービスやサブシステムが多くの異なるファイルに設定されていました。JBoss Enterprise Application 6 では、設定は主に 1 つのファイルで行われます。アプリケーションが以下のサービスやリソースを使用する場合は、設定の変更が必要となる場合があります。
  1. アプリケーションがデータソースを使用する場合は 「DataSource 設定の更新」を参照してください。
  2. アプリケーションが JPA を使用し、現在 Hibernate JAR をバンドルする場合は、 「Hibernate または JPA に対するデータソースの設定」を参照し、移行のオプションについて確認してください。
  3. アプリケーションがリソースアダプターを使用する場合は、 「リソースアダプター設定の更新」を参照してください。
  4. 「アプリケーションセキュリティーの変更設定」 を参照し、基本的なセキュリティーの設定変更方法について確認してください。

3.1.6.2. DataSource 設定の更新

概要

以前のバージョンの JBoss Enterprise Application Platform では、ファイル名の最後に *-ds.xml が付くファイルに JCA データソースの設定が定義されていました。このファイルはサーバーの deploy/ ディレクトリにデプロイされるか、アプリケーションによってパッケージ化されました。JDBC ドライバーは server/lib/ ディレクトリにコピーされるか、アプリケーションの WEB-INF/lib/ ディレクトリにパッケージ化されました。この設定方法は開発環境では今でもサポートされていますが、JBoss の管理ツールではサポートされていないため実稼働環境では推奨されません。

JBoss Enterprise Application Platform 6 ではデータソースはサーバー設定ファイルに設定されています。Enterprise Application Platform インスタンスが管理ドメインで実行されている場合、データソースは domain/configuration/domain.xml ファイルに設定されます。Enterprise Application Platform インスタンスがスタンドアロンサーバーとして実行されている場合、データソースは standalone/configuration/standalone.xml ファイルに設定されます。このように設定されたデータソースは、Web 管理コンソールやコマンドラインインターフェース (CLI) などが含まれる JBoss 管理インターフェースを使用して管理および制御されます。これらのツールはデプロイメントの管理や、管理ドメインで実行されている複数のサーバーの設定を容易にします。
次の項では、使用可能な管理ツールによって管理およびサポートされるよう、データソースの設定を変更する方法について説明します。
JBoss Enterprise Application Platform 6 の管理可能なデータソース設定の移行

JDBC 4.0 対応のドライバーはデプロイメントまたはコアモジュールとしてインストールすることができます。JDBC 4.0 対応のドライバーには、ドライバークラス名を指定する META-INF/services/java.sql.Driver ファイルが含まれています。JDBC 4.0 対応でないドライバーには追加の設定が必要となります。ドライバーを JDBC 4.0 対応にする方法や、現在のデータソース設定を Web 管理コンソールや CLI によって管理可能な設定に更新する方法の詳細については 「JDBC ドライバーのインストールと設定」 を参照してください。

アプリケーションが Hibernate や JPA を使用する場合、追加の変更が必要となる場合があります。詳細は 「Hibernate または JPA に対するデータソースの設定」 を参照してください。
IronJacamar 移行ツールを使用した設定データの変換

「IronJacamar ツールを使用してデータソースとリソースアダプターの設定を移行する」 の通り、IronJacamar ツールを使用してデータソースやリソースアダプター設定を移行することが可能です。このツールは *-ds.xml スタイルの設定ファイルを JBoss Enterprise Application Platform 6 が想定する形式に変換します。

3.1.6.3. JDBC ドライバーのインストールと設定

概要

次の 2 つの方法の 1 つを用いて JDBC ドライバーをコンテナにインストールすることができます。

  • デプロイメントとしてのインストール
  • コアモジュールとしてのインストール
これらの方法の利点と欠点は次の通りです。

JBoss Enterprise Application Platform 6 ではデータソースはサーバー設定ファイルに設定されています。Enterprise Application Platform インスタンスが管理ドメインで実行されている場合、データソースは domain/configuration/domain.xml ファイルに設定されます。Enterprise Application Platform インスタンスがスタンドアロンサーバーとして実行されている場合、データソースは standalone/configuration/standalone.xml ファイルに設定されます。両モードで同じであるスキーマ参照情報は JBoss Enterprise Application Platform 6 インストールの doc/ ディレクトリにあります。ここでは説明上、サーバーがスタンドアロンサーバーとして稼働し、データソースが standalone.xml ファイルに設定されていると仮定します。

手順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/
      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 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>
        
        モジュール名「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/
      この方法の利点は次の通りです。
      • 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"/>
      
      JDBC 4.0 対応でないドライバーにはドライバークラス名を指定する META-INF/services/java.sql.Driver がないため、ドライバークラスを識別するために <driver-class> が必要となります。JDBC 4.0 に対応していないドライバーのドライバー要素の例は次の通りです。
      <driver name="mysql-connector-java-5.1.15.jar" module="com.mysql">
      <driver-class>com.mysql.jdbc.Driver</driver-class></driver>
      
    2. データソースの作成

      standalone.xml ファイルの <datasources> セクションに <datasource> 要素を作成します。このファイルには、以前 *-ds.xml に定義されたデータソース情報と同じ情報の多くが含まれています。
      standalone.xml ファイルの MySQL データソース要素の例は次の通りです。
      <datasource jndi-name="java:/YourDatasourceName" pool-name="YourDatasourceName">
        <connection-url>jdbc:mysql://localhost:3306/YourApplicationURL</connection-url>
        <driver>mysql-connector-java-5.1.15.jar</driver>
        <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
        <pool>
          <min-pool-size>100</min-pool-size>
          <max-pool-size>200</max-pool-size>
        </pool>
        <security>
          <user-name>USERID</user-name>
          <password>PASSWORD</password>
        </security>
        <statement>
          <prepared-statement-cache-size>100</prepared-statement-cache-size>
          <share-prepared-statements/>
        </statement>
      </datasource>
      

3.1.6.4. Hibernate または JPA に対するデータソースの設定

アプリケーションが JPA を使用し、現在 Hibernate JAR をバンドルする場合、JBoss Enterprise Application Platform 6 に含まれる Hibernate を使用した方がよい場合があります。このバージョンの Hibernate を使用するには、アプリケーションより古いバージョンの Hibernate バンドルを削除する必要があります。

手順3.9 Hibernate バンドルの削除

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

3.1.6.5. リソースアダプター設定の更新

概要

以前のバージョンのアプリケーションサーバーでは、リソースアダプター設定は、ファイル名の最後に *-ds.xml が付くファイルで定義されました。JBoss Enterprise Application Platform 6 ではリソースアダプターはサーバー設定ファイルで設定されます。管理ドメインで実行されている場合、設定ファイルは EAP_HOME/domain/configuration/domain.xml ファイルになります。スタンドアロンサーバーとして実行されている場合、EAP_HOME/standalone/configuration/standalone.xml ファイルのリソースアダプターを設定します。Resource adapter descriptors のスキーマ参照情報は両モード共通です。

リソースアダプターの定義

リソースアダプター記述子の情報は、サーバー設定ファイルの次のサブシステム要素下に定義されます。

<subsystem xmlns="urn:jboss:domain:resource-adapters:1.0"/>
以前リソースアダプター *-ds.xml ファイルに定義された情報と同じものの一部を使用します。

サーバー設定ファイルのリソースアダプター要素の例は次の通りです。
<resource-adapters>
  <resource-adapter>
    <archive>multiple-full.rar</archive>
    <config-property name="Name">ResourceAdapterValue</config-property>
    <transaction-support>NoTransaction</transaction-support>
    <connection-definitions>
      <connection-definition
      class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleManagedConnectionFactory1"
      enabled="true" jndi-name="java:/eis/MultipleConnectionFactory1"
      pool-name="MultipleConnectionFactory1">
    <config-property name="Name">MultipleConnectionFactory1Value</config-property>
      </connection-definition>
      <connection-definition
      class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleManagedConnectionFactory2"
      enabled="true" jndi-name="java:/eis/MultipleConnectionFactory2"
      pool-name="MultipleConnectionFactory2">
    <config-property name="Name">MultipleConnectionFactory2Value</config-property>
      </connection-definition>
    </connection-definitions>
    <admin-objects>
      <admin-object
      class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleAdminObject1Impl"
      jndi-name="java:/eis/MultipleAdminObject1">
    <config-property name="Name">MultipleAdminObject1Value</config-property>
      </admin-object>
      <admin-object class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleAdminObject2Impl"
      jndi-name="java:/eis/MultipleAdminObject2">
    <config-property name="Name">MultipleAdminObject2Value</config-property>
      </admin-object>
      </admin-objects>
  </resource-adapter>
</resource-adapters>

3.1.7. セキュリティーの変更

3.1.7.1. アプリケーションセキュリティーの変更設定

基本認証のセキュリティーの設定

UsersRolesLoginModule は常にクラスパスのプロパティーファイルを検索しました。以前のバージョンのJBoss Enterprise Application Platform では、EAP_HOME/server/SERVER_NAME/conf/ ディレクトリに置かれたプロパティーファイルはクラスパス上にあり、UsersRolesLoginModule によって簡単に見つかりました。JBoss Enterprise Application Platform 6 ではディレクトリ構造が変更になりました。プロパティーファイルをアプリケーション内でパッケージ化し、クラスパスで使用できるようにする必要があります。

基本認証のセキュリティーを設定するには、security-domains 下の新しいセキュリティードメインを standalone/configuration/standalone.xml または domain/configuration/domain.xml サーバー設定ファイルに追加します。
<security-domain name="example">
    <authentication>
        <login-module code="UsersRoles" flag="required">
            <module-option name="usersProperties" 
                    value="${jboss.server.config.dir}/example-users.properties"/>
            <module-option name="rolesProperties" 
                    value="${jboss.server.config.dir}/example-roles.properties"/>
        </login-module>
    </authentication>
</security-domain>
JBoss Enterpise Application Platform 6 インスタンスがスタンドアロンサーバーとして実行されている場合、 ${jboss.server.config.dir}EAP_HOME/standalone/configuration/ ディレクトリを参照します。インスタンスが管理ドメインで実行されている場合、 ${jboss.server.config.dir}EAP_HOME/domain/configuration/ ディレクトリを参照します。
セキュリティードメイン名の変更

JBoss Enterprise Application Platform 6 では、セキュリティードメインの名前の最初に java:/jaas/ が付かないようになりました。

  • Web アプリケーションでは jboss-web.xml のセキュリティー設定よりこのプレフィックスを削除する必要があります。
  • エンタープライズアプリケーションでは、jboss-ejb3.xml ファイルのセキュリティードメイン設定よりこのプレフィックスを削除する必要があります。JBoss Enterprise Application Platform 6 では jboss.xml はこのファイルに置き換えられました。

3.1.8. JNDI の変更

3.1.8.1. アプリケーションの JNDI 名前空間名の更新

概要

EJB 3.1 は標準化されたグローバル JNDI 名前空間や、Java EE アプリケーションの様々なスコープへマップする複数の関連名前空間を導入しました。移植可能な EE アプリケーションに使用される JNDI 名前空間は java:globaljava:modulejava:app の 3 つです。JNDI ルックアップを使用するアプリケーションを変更し、新しい標準 JNDI 名前空間の慣例に従うようにする必要があります。

JNDI マッピングの例

以前のリリースにおける JNDI 名前空間の例や、 JBoss Enterprise Application Platform 6 で指定する方法については 「以前のリリースにおける JNDI 名前空間の例、また JBoss Enterprise Application Platform 6 での名前空間の指定方法」 を参照してください。

3.1.8.2. 移植可能な JNDI ネーミング構文

概要

論理的な名前空間は 4 つあり、それぞれ独自のスコープを持っています。このうち 3 つは移植可能な JNDI ルックアップに利用されます。以下の表は各名前空間をいつどのように使用するかを説明しています。

表3.1 移植可能な JNDI 名前空間

JNDI 名前空間 詳細
java:global
この名前空間の名前はアプリケーションサーバーインスタンス内にデプロイされている全アプリケーションで共有されます。この名前空間の名前を使いリモートの EJB を検索します。
以下は java:global 名前空間の例になります。 java:global/jboss-seam-booking/jboss-seam-booking.jar/HotelBookingAction
java:module
この名前空間の名前は、1 つの EJB モジュールにある全エンタープライズ Bean や Web モジュールにある全コンポーネントなど、モジュール内の全コンポーネントで共有されます。
java:module 名前空間の例は次の通りです。 java:module/HotelBookingAction!org.jboss.seam.example.booking.HotelBooking
java:app
この名前空間の名前は、1つのアプリケーション内にある全モジュールのコンポーネントすべてで共有されます。例えば、同じ EAR ファイルにある WAR や EJB jar ファイルは java:app namespace のリソースにアクセスできます。
以下は java:app 名前空間の例になります。 java:app/jboss-seam-booking.jar/HotelBookingAction
JNDI ネーミングコンテキストの詳細は「JSR 316: JavaTM Platform, Enterprise Edition (Java EE) 仕様バージョン 6」 の EE.5.2.2 「Application Component Environment Namespaces」 を参照してください。 http://jcp.org/en/jsr/detail?id=316 からこの仕様をダウンロードすることができます。

3.1.8.3. JNDI 名前空間のルールの確認

概要

JBoss Enterprise Application Platform 6 では JNDI 名前空間の名前が改良され、アプリケーションにバインドされた名前に対して一貫した予測可能なルールを提供するだけでなく、将来的に互換性の問題が起こらないよう対処されます。そのため、現在の名前空間が新しいルールに準拠しない場合、問題が発生することがあります。

名前空間は次のルールに準拠する必要があります。

  1. DefaultDSjdbc/DefaultDS のような修飾されていない相対名は、コンテキストに応じて java:comp/envjava:module/envjava:jboss/env のいずれかに相対的に修飾されなければなりません。
  2. /jdbc/DefaultDS などの修飾されていない absolute 名は java:jboss/root 名に相対的に修飾されなければなりません。
  3. java:/jdbc/DefaultDS などの修飾された absolute 名は、前述の修飾されていない absolute 名と同様に修飾されなければなりません。
  4. 特殊な java:jboss 名前空間は AS サーバーインスタンス全体で共有されます。
  5. プレフィックスが java: である relative 名は、 compmoduleappglobal、 プロプラエタリ jboss の 5 つの名前空間の 1 つでなければなりません。 名前が java:xxx で始まり、xxx が前述の 5 つの名前空間と一致しない場合、無効な名前エラーが発生する原因となります。

3.1.8.4. 新しい JNDI 名前空間ルールに準拠するようアプリケーションを変更する

  • JBoss Enterprise Application Platform 5.1 の JNDI ルックアップの例は次の通りです。通常、このコードは初期化メソッドに存在します。
    private ProductManager productManager;
    try {
        context = new InitialContext();
        productManager = (ProductManager) context.lookup("OrderManagerApp/ProductManagerBean/local");
    } catch(Exception lookupError) {
        throw new ServletException("Unable to find the ProductManager bean", lookupError);
    }
    
    ルックアップ名は OrderManagerApp/ProductManagerBean/local になります。
  • 次の例は、JBoss Enterprise Application Platform 6 では同じルックアップがどのようにコード化されるかを表しています。
    @EJB(lookup=“java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager")
    private ProductManager productManager;
    
    ルックアップ値はメンバー変数として定義され、新しい移植可能な java:app JNDI 名前空間名である java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager が使用されます。

3.1.8.5. 以前のリリースにおける JNDI 名前空間の例、また JBoss Enterprise Application Platform 6 での名前空間の指定方法

表3.2

JBoss Enterprise Application Platform 5.x の名前空間 JBoss Enterprise Application Platform 6 の名前空間 追加コメント
OrderManagerApp/ProductManagerBean/local java:module/ProductManagerBean!services.ejb.ProductManager EE6 標準のバインディング、同じモジュール内でのみアクセス可能
OrderManagerApp/ProductManagerBean/local java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager EE6 標準のバインディング、同じアプリケーション内でのみアクセス可能
OrderManagerApp/ProductManagerBean/local java:global/OrderManagerApp/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager EE6 標準のバインディング、グローバルにアクセス可能
java:comp/UserTransaction java:comp/UserTransaction アプリケーションが直接作成するスレッドなど、EE 以外のスレッド対してアクセス可能
java:comp/UserTransaction java:jboss/UserTransaction グローバルにアクセス可能。java:comp/UserTransaction を利用できない場合に使用。
java:/TransactionManager java:jboss/TransactionManager
java:/TransactionSynchronizationRegistry java:jboss/TransactionSynchronizationRegistry