3.2.11. EJB 2.x の変更

3.2.11.1. EJB 2.x を使用するアプリケーションの更新

JBoss EAP 6 はオープン標準で構築され、Java Enterprise Edition 6 仕様に準拠しています。アプリケーションサーバーは EJB 2.x のサポートを提供しますが、この仕様以降の機能をサポートしない可能性があります。Java EE 7 仕様では EJB 2.x はオプションとなっているため、アプリケーションコードを EJB 3.x 仕様向けに書き直すことが強く推奨されます。
EJB 2.x コードを移行する場合、JBoss EAP 6 を実行するために変更を加える必要があることがほとんどです。本トピックでは、JBoss EAP 6 上で EJB 2.x を実行するために必要となる変更の一部を取り上げます。
JBoss EAP 6 上で EJB 2.x を実行するために必要な設定変更

Full プロファイルでサーバーを起動
EJB 2.x の CMP (Container Managed Persistence) Bean には Java Enterprise Edition 6 Full Profile が必要です。このプロファイルには、CMP EJB を実行するために必要な設定要素が含まれています。
この設定プロファイルには org.jboss.as.cmp 拡張モジュールが含まれています。 
<extensions>
    ...
    <extension module="org.jboss.as.cmp"/>
    ...
</extensions>
さらに、cmp サブシステムも含まれています。 
<profiles>
    ...
    <subsystem xmlns="urn:jboss:domain:cmp:1.1"/>
    ...
</profiles>
Full プロファイルで JBoss EAP 6 スタンドアロンサーバーを起動するには、サーバーの起動時にコマンドラインで -c standalone-full.xml または -c standalone-full-ha.xml 引数を渡します。
コンテナ設定はサポートされません
以前のバージョンの JBoss EAP では、CMP エンティティーおよび他の Bean の異なるコンテナを設定し、jboss.xml アプリケーションデプロイメント記述子ファイル内に参照を設定することが可能でした。たとえば、通常は SLSB とセッション Bean の設定は異なりました。
JBoss EAP 6.x では、標準のコンテナで EJB 2 エンティティー Bean を使用できますが、他のコンテナ設定はサポートされないようになりました。EJB2 のステートフルセッション Bean (SFSB)、ステートレスセッション Bean (SLSB)、およびメッセージ駆動型 Bean (MDB) を EJB 3 へ移行し、CMP (Container-Managed Persistence) および BMP (Bean-Managed Persistence) エンティティー Bean が EJB 3 の仕様どおりに Java 永続 API (JPA) を使用することが推奨されます。
JBoss EAP 6 のデフォルトのコンテナ設定には、EJB 2 CMP Bean に対する変更が複数含まれています。
  • 悲観的ロックはデフォルトで有効になっています。これにより、デッドロックが発生する可能性があります。
  • JBoss EAP 5.x の CMP レイヤーに存在したデッドロック検出コードは JBoss EAP 6 には存在しません。
JBoss EAP 5.x では、キャッシング、プーリング、commit-options、およびインターセプタースタックをカスタマイズできましたが、JBoss EAP 6 ではカスタマイズできません。commit-option C を持つ Instance Per Transaction ポリシーと似た実装のみがあります。CMP2.x と互換性のある JDBC ベースの永続性マネージャーを使う cmp2.x jdbc2 pm エンティティー Bean コンテナ設定を使用するアプリケーションを移行する場合は、パフォーマンスに影響します。このコンテナはパフォーマンスに対して最適化されていました。アプリケーションを移行する前にこれらのエンティティーを EJB 3 に移行することが推奨されます。
サーバー側インターセプター設定
JBoss EAP 6 は、@Interceptors および @AroundInvoke を使用して標準の Java EE Interceptor をサポートします。しかし、セキュリティー外部またはトランザクション外部の操作は許可されません。
以前のバージョンの JBoss EAP では、各 EJB 呼び出しに対してカスタムインターセプターを指定するためにインターセプタースタックを変更できました。これは通常、セキュリティーチェック、トラザクションチェック、または作成の前にカスタマイズされたセキュリティーまたはリトライメカニズムを実装するために使用されました。JBoss EAP 6.1 には、同様の機能を提供するコンテナインターセプターが導入されました。コンテナインターセプターの詳細は、JBoss EAP 『開発ガイド』の「コンテナインターセプター」の章を参照してください。
Java EE 仕様に準拠しながら、トラザクションのコミットフェーズ中および前後で制御を強化する別の方法には、Transaction Synchronization Registry (トランザクション同期レジストリー) を使用してリスナーを追加する方法があります。
以下の方法の 1 つを使用してリソースを読み出しできます。
  • InitialContext の使用 
    TransactionSynchronizationRegistry tsr = (TransactionSynchronizationRegistry) 
		new InitialContext().lookup("java:jboss/TransactionSynchronizationRegistry");
tsr.registerInterposedSynchronization(new MyTxCallback());
  • インジェクションの使用 
    @Resource(mappedName = "java:comp/TransactionSynchronizationRegistry")
TransactionSynchronizationRegistry tsr;
...
tsr.registerInterposedSynchronization(new MyTxCallback());
コールバックルーティングは、javax.transaction.Synchronization インターフェースを実装する必要があります。トランザクションがコミットまたはロールバックする前に、 beforeCompletion{} メソッドを使用してチェックを実行します。このメソッドから RuntimeException が発生した場合、トランザクションがロールバックされ、クライアントには EJBTransactionRolledbackException が報告されます。XA トランザクションの場合、XA コントラクトにしたがってすべてのリソースがロールバックされます。また、afterCompletion(int txStatus) を使用して、有効なビジネスロジックがトラザクションの状態に依存するようにすることも可能です。このメソッドから RuntimeException が発生した場合、トラザクションはコミットまたはロールバックされた以前の状態を維持し、クライアントには報告されません。トランザクションマネージャーのみがサーバーログファイル内で警告を表示します。
クライアント側インターセプターのサーバー側設定
以前のバージョンの JBoss EAP では、サーバー設定内でクライアントインターセプターを設定し、クライアント API でクラスのみを提供することが可能でした。
しかし、JBoss EAP 6 ではこれが不可能になりました。クライアントプロキシがサーバー側で作成されなくなり、ルックアップ後にクライアントへ送信されなくなったためです。JBoss EAP 6 ではプロキシはクライアント側で作成されます。この最適化は、ルックアップのサーバー呼び出しや、クラスのアップロードが発生しないようにします。
エンティティー Bean プールの設定
JBoss EAP 6 では、エンティティー Bean プールの設定は推奨されません。この設定は、<strict-max-pool> 要素の設定に限定されるため、プールが小さすぎて結果セットのエントリーをすべてロードできないと、デッドロックなどの問題が発生することがあります。エンティティー Bean は初期化中に大きなライフサイクルメソッドを持たないため、インスタンスおよび周囲のコンテナを作成する速度は、プールされたエンティティー Bean インスタンスを使用する場合と変わりません。
jboss.xml デプロイメント記述子ファイルの置き換え
jboss.xml デプロイメント記述子は jboss-ejb3.xml デプロイメント記述子に置き換えられました。このファイルは、Java Enterprise Edition (EE) によって定義された ejb-jar.xml デプロイメント記述子によって提供される機能を上書きおよび追加するために使用されます。jboss-ejb3.xml ファイルは jboss.xml との互換性がなく、jboss.xml はデプロイメントで無視されます。
たとえば、JBoss EAP の以前のリリースでは ejb-jar.xml ファイルで <resource-ref> を定義する場合に jboss.xml ファイルに JNDI 名の対応するリソース定義が必要でした。XDoclet が自動的にこれらのデプロイメント記述子ファイルを作成しました。JBoss EAP 6 では、JNDI マッピング情報が jboss-ejb3.xml ファイルで定義されるようになりました。以下のようにデータソースが Java ソースに定義されていることを仮定します。 
DataSource ds1 = (DataSource) new InitialContext().lookup("java:comp/env/jdbc/Resource1");
DataSource ds2 = (DataSource) new InitialContext().lookup("java:comp/env/jdbc/Resource2");
ejb-jar.xml は以下のリソース参照を定義します。 
<resource-ref >
    <res-ref-name>jdbc/Resource1</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
</resource-ref>
<resource-ref >
    <res-ref-name>java:comp/env/jdbc/Resource2</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
</resource-ref>
jboss-ejb3.jxml ファイルは、以下の XML 構文を使用して JNDI 名を参照へマップします。 
<resource-ref>
    <res-ref-name>jdbc/Resource1</res-ref-name>
    <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
</resource-ref>
<resource-ref>
    <res-ref-name>java:comp/env/jdbc/Resource2</res-ref-name>
    <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
</resource-ref>
JBoss EAP 6 には、JBoss EAP 5.x の jboss.xml ファイルで使用できた設定オプションの一部が実装されていません。以下のリストは、一般的な jboss.xml ファイルの属性と、JBoss EAP 6 で代替の方法があるかどうかを示しています。
  • method-attribute 要素は個別のエンティティーおよびセッション Bean メソッドを設定するために使用されました。
    • read-only および idempotent 設定オプションは JBoss EAP 6 に移植されませんでした。
    • transaction-timeout オプションは jboss-ejb3.xml ファイルで設定されるようになりました。
  • missing-method-permission-exclude-mode 属性は、セキュア化された Bean に明示的なセキュリティーメタデータを実装せずにメソッドの挙動を変更しました。現在 JBoss EAP 6 では、@RolesAllowed アノテーションが存在しないと @PermitAll と同様に処理されます。
DataSource タイプマッピングの設定
以前のバージョンの JBoss EAP では、*-ds.xml データソースデプロイメント設定ファイル内にデータソースタイプマッピングを設定できました。
JBoss EAP 6 では、この設定を jbosscmp-jdbc.xml デプロイメント記述子ファイルで行う必要があります。 
<defaults>  
    <datasource-mapping>mySQL</datasource-mapping>  
    <create-table>true</create-table>  
    ....  
</defaults>
以前のバージョンの JBoss EAP では、カスタマイズされたマッピングは standardjbosscmp-jdbc.xml ファイルで行われました。このファイルは使用できなくなり、マッピングは jbosscmp-jdbc.xml デプロイメント記述子ファイルで行われるようになりました。
CMP (Container Managed Persistence) および CMR (Container Managed Relationship) に関するその他の変更

CMR (Container Managed Relationship) イテレーターおよびコレクションの変更
以前のリリースの JBoss EAP では、cmp2.x jdbc2 pm コンテナなどの一部のコンテナが CMR コレクションを繰り返すことが可能で、関係を削除または追加できました。JBoss EAP 6 ではコンテナ設定はサポートされていないため、これが不可能になりました。アプリケーションコードで同じ機能を実現する方法については、カスタマーポータルのサポート - ナレッジ - ソリューションに記載されている EJB2.1 Finder for CMP entities with relations (CMR) returns duplicates in EAP6 を参照してください。
ファインダーに対する CMR (Container Managed Relationship) の重複エントリー
以前のバージョンの JBoss EAP では、異なる永続性ストラテジーを使用する別の CMP コンテナを選択できませんでした。JBoss EAP 5.x の cmp2.x jdbc2 pm コンテナは最適化された SQL-92 を使用して、ファインダーに対して最適化された LEFT OUTER JOIN 構文を生成しました。JBoss EAP 6.x は CMP および CMR の標準的なコンテナのみをサポートするため、実装にはこれらの最適化が含まれていません。結果セットのデカルト積を避けるため、ファインダーの SELECT ステートメントにキーワード DISTINCT が含まれるようにする必要があります。詳細は、カスタマーポータルのサポート - ナレッジ - ソリューションに記載されている EJB2.1 Finder for CMP entities with relations (CMR) returns duplicates in EAP6 を参照してください。
CMP エンティティー Bean に対するカスケード削除のデフォルト変更
カスケード削除のデフォルト値が false に変更されました。これにより、JBoss EAP 6 では削除に失敗することがあります。エンティティーの関係が cascade-delete とマークされた場合、jbosscmp-jdbc.xml ファイルで batch-cascade-delete を明示的に true に設定する必要があります。詳細は、カスタマーポータルのサポート - ナレッジ - ソリューションに記載されている cascade delete fail for EJB2 CMP Entities after migration to EAP6 を参照してください。
カスタムフィールドの CMP カスタムマッパー
JDBCParameterSetter、JDBCResultSetReader、Mapper などのカスタムマッパークラスを JBoss EAP 5.x アプリケーションで使用した場合、アプリケーションを JBoss EAP 6 にデプロイすると java.lang.ClassNotFoundException が発生することがあります。これは、インターフェースのパッケージ名が org.jboss.ejb.plugins.cmp.jdbc.Mapper から org.jboss.as.cmp.jdbc.Mapper に変更になったためです。詳細は、カスタマーポータルのサポート - ナレッジ - ソリューションに記載されている How to use Field mapping for custom classes in an EJB2 CMP application in EAP6 を参照してください。
エンティティーコマンドを使用した主キーの生成
Sequence や Auto-increment など、JBoss EAP 5 アプリケーションが entity-commands を使用して主キーを生成する場合、アプリケーションを JBoss EAP 6 に移行すると JDBCOracleSequenceCreateCommand クラスに対して ClassNotFoundException が発生することがあります。これは、クラスパッケージが org.jboss.ejb.plugins.cmp.jdbc から org.jboss.as.cmp.jdbc.keygen に変更になったためです。JBoss EAP 6 アプリケーションでこのクラスを使用する場合、EAP_HOME/modules/system/layers/base/org/jboss/as/cmp モジュール上に依存関係を追加する必要もあります。
アプリケーションの変更

新しい JNDI 名前空間ルールを使用するためのコードの変更
EJB 3.0 と同様に、EJB 2.x でも完全な JNDI 接頭辞を使用する必要があります。新しい JNDI 名前空間ルールやコード例の詳細は、 「アプリケーションの JNDI 名前空間名の更新」を参照してください。
以前のリリースから JNDI 名前空間を更新する方法を表す例は 「以前のリリースでの JNDI 名前空間の例、および JBoss EAP 6 での名前空間の指定方法」にあります。
jboss-web.xml ファイル記述子の変更
各 <ejb-ref> に対する <jndi-name> を変更し、新しい JNDI 完全修飾ルックアップ形式を使用するようにします。
XDoclet を使用した内部ローカルインターフェースの JNDI 名へのマッピング
EJB 2 では、Locator パターンを使用した Bean のルックアップが一般的でした。アプリケーションコードを変更せずに、アプリケーションでこのパターンを使用する場合、XDoclet を使用して新しい JNDI 名のマップを生成できます。
通常、XDoclet アノテーションは以下のようになります。 
@ejb.bean name="UserAttribute" display-name="UserAttribute" local-jndi-name="ejb21/UserAttributeEntity" view-type="local" type="CMP" cmp-version="2.x" primkey-field="id"
上例の JNDI 名 ejb21/UserAttributeEntity は、JBoss EAP 6 では無効です。サーバー設定の naming サブシステムと XDoclet のパッチを使用して、この名前を有効な JNDI 名へマッピングします。
前述の「カスタムフィールドの CMP カスタムマッパー」にしたがって、カスタマイズされたマッパーを作成できます。または、以下の手順どおりにコードを変更できます。

手順3.24 XDoclet で生成されたコードの変更と naming サブシステムの使用

  1. ejb-module.jar にある XDoclet の lookup.xdt テンプレートを展開し、次のように lookupHome の lookup() を編集します。 
    private static Object lookupHome(java.util.Hashtable environment, String jndiName, Class narrowTo) throws javax.naming.NamingException {  
    // Obtain initial context  
    javax.naming.InitialContext initialContext = new javax.naming.InitialContext(environment);  
    try { 
        // Replace the existing lookup      
        // Object objRef = initialContext.lookup(jndiName);  
        // This is the new mapped lookup
        Object objRef;  
        try {  
            // try JBoss EAP mapping  
            objRef = initialContext.lookup("global/"+jndiName);  
        } catch(java.lang.Exception e) {  
            objRef = initialContext.lookup(jndiName);  
        }  
        // only narrow if necessary  
        if (java.rmi.Remote.class.isAssignableFrom(narrowTo))  
            return javax.rmi.PortableRemoteObject.narrow(objRef, narrowTo); 
        else  
            return objRef;  
    } finally {  
        initialContext.close();  
    }  
}
  2. Ant を実行し、変更された lookup.xdt を ejbdoclet タスクに使用するようテンプレート属性を設定します。
  3. サーバー設定ファイルの naming サブシステムを編集し、古い JNDI 名を新しく有効な JNDI 名へマッピングします。 
    <subsystem xmlns="urn:jboss:domain:naming:1.2">  
    <bindings>  
        <lookup name="java:global/ejb21/UserAttributeEntity" lookup="java:global/ejb2CMP/ejb/UserAttribute!de.wfink.ejb21.cmp.cmr.UserAttributeLocalHome"/>  
    </bindings>  
    <remote-naming/>  
</subsystem>
廃止されたファイル

JBoss EAP 6 ではサポートされないファイルは次のとおりです。

jboss.xml
jboss.xml デプロイメント記述子ファイルはサポートされなくなり、デプロイされたアーカイブに含まれていると無視されます。
standardjbosscmp-jdbc.xml
standardjbosscmp-jdbc.xml 設定ファイルはサポートされません。この設定情報は、org.jboss.as.cmp モジュールに含まれるようになり、カスタマイズ不可能になりました。
standardjboss.xml
standardjboss.xml 設定ファイルはサポートされません。この設定情報は、スタンドアロンサーバーを実行する場合は standalone.xml ファイルに含まれ、管理対象ドメインで実行される場合は domain.xml に含まれるようになりました。
バグを報告する