第5章 アプリケーション移行の変更

主に Apache CXF、Apache WSS4J、および Apache Santuario コンポーネントがアップグレードされ、JBossWS 5 は JBoss EAP 7 の Web サービスに新機能と改良されたパフォーマンスを提供します。

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointImpl</config-name>
    <property>
      <property-name>cxf.interceptors.in</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointInterceptor,org.jboss.test.ws.jaxws.cxf.interceptors.FooInterceptor</property-value>
    </property>
    <property>
      <property-name>cxf.interceptors.out</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointCounterInterceptor</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>Custom FI Config</config-name>
    <property>
      <property-name>cxf.features</property-name>
      <property-value>org.apache.cxf.feature.FastInfosetFeature</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

import org.apache.cxf.frontend.ClientProxy;
import org.apache.cxf.transport.http.HTTPConduit;
import org.apache.cxf.transports.http.configuration.HTTPClientPolicy;

// Set chunking threshold before using a JAX-WS port client
...
HTTPConduit conduit = (HTTPConduit)ClientProxy.getClient(port).getConduit();
HTTPClientPolicy client = conduit.getClient();

client.setChunkingThreshold(8192);
...

JBoss EAP 7 では、デフォルトのコネクターが remote から http-remoting に変更になり、デフォルトのリモート接続ポートが 4447 から 8080 に変更になりました。デフォルト設定の JNDI プロバイダー URL は remote://localhost:4447 から http-remoting://localhost:8080 に変更になりました。

JBoss EAP 7 の migrate 操作を使用して設定を更新すると、移行操作によってサブシステム設定の JBoss EAP 6 remoting コネクターおよび 4447 ポート設定が保持されるため、リモートコネクター、リモートポート、または JNDI プロバイダー URL を変更する必要がありません。migrate 操作の詳細は、管理 CLI の移行操作を参照してください。

migrate 操作を使用せずに、新しい JBoss EAP 7 のデフォルト設定を使用して実行する場合は、新しい設定を使用するようにリモートコネクター、リモートポート、および JNDI プロバイダー URL を変更する必要があります。

JBoss EAP の以前のリリースでは、JAX-RS 1.x の実装である RESTEasy 2 がバンドルされていました。JBoss EAP 7 には、JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services 仕様で定義されている JAX-RS 2.0 の実装となる RESTEasy 3 が含まれています。RESTful Web サービスの Java API に関する詳細情報は、JAX-RS 2.0 API Specification を参照してください。

JBoss EAP に含まれる Jackson のバージョンは変更されました。JBoss EAP の以前のリリースに含まれていた Jackson は 1.9.9 でしたが、JBoss EAP 7 には Jackson 2.6.3 またはそれ以降が含まれています。

本セクションでは、RESTEasy または JAX-RS を使用するアプリケーションにこれらの変更が及ぼす影響について説明します。

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <deployment>
    <exclusions>
      <module name="org.jboss.resteasy.resteasy-jackson2-provider"/>
      <module name="org.jboss.resteasy.resteasy-jackson-provider"/>
    </exclusions>
    <dependencies>
      <module name="org.jboss.resteasy.resteasy-jettison-provider" services="import"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

JBoss EAP 7 には CDI 1.2 のサポートが含まれています。このため、CDI 1.0 を使って書かれたアプリケーションは、JBoss EAP 7 に移行すると動作が異なる場合があります。本セクションでは、これらの変更点のいくつかのみをまとめています。

Weld および CDI 1.2 についての追加情報は、以下の参照先で確認できます。

Bean アーカイブ

CDI によってスキャンされ、bean クラスを検索および処理するようにするため、有効な bean の bean クラスを bean アーカイブにデプロイする必要があります。

CDI 1.0 では、アプリケーションクライアント、EJB、またはライブラリー JAR の META-INF/ ディレクトリーに beans.xml ファイルが含まれた場合や、WAR の WEB-INF/ ディレクトリーに beans.xml ファイルが含まれた場合には、アーカイブが 明示的 bean アーカイブとして定義されました。

CDI 1.1 には 暗黙的 bean アーカイブが導入されました。これは bean を定義するアノテーションを持つ bean クラスが 1 つ以上またはセッション bean が 1 つ以上含まれるアーカイブです。 暗黙的な bean アーカイブは CDI によってスキャンされ、型検索中に bean を定義するアノテーションを持つクラスのみが検出されます。詳細は、Contexts and Dependency Injection for the Java EE platform の Type and Bean Discovery を参照してください。

bean アーカイブは all、annotated、または none の bean 検索モードを持ちます。バージョンのない beans.xml ファイルが含まれる bean アーカイブは、デフォルトの bean 検索モード all を持ちます。バージョンが 1.1 以上の beans.xml ファイルが含まれる bean アーカイブは bean-discovery-mode 属性を指定する必要があります。この属性のデフォルト値は annotated です。

以下の場合、アーカイブは bean アーカイブではありません。

以下の場合、アーカイブは 明示的 bean アーカイブになります。

以下の場合、アーカイブは 暗黙的 bean アーカイブになります。

CDI 1.2 は bean を定義するアノテーション を以下に限定します。

bean アーカイブの詳細は、 Contexts and Dependency Injection for the Java EE platform の Bean Archives を参照してください。

会話解決の明確化

会話コンテキストのライフサイクルは、CDI Specification Issue CDI-411 で説明されていサーブレット仕様との競合を回避するために変更されました。会話スコープはすべてのサーブレットリクエストの間はアクティブで、他のサーブレットやサーブレットフィルターによるリクエストボディーや文字エンコードの設定を妨げないはずです。

オブザーバー解決

イベント解決は、CDI 1.2 で部分的に書き換えられました。CDI 1.0 では、オブザーバーメソッドにすべてのイベント修飾子がある場合にイベントはオブザーバーメソッドに配信されました。CDI 1.2 では、オブザーバーメソッドにイベント修飾子がないかイベント修飾子のサブセットがある場合にイベントがオブザーバーメソッドに配信されます。

前リリースの JBoss EAP ではモジュラークラスローディングシステムと JBoss モジュールが導入され、アプリケーションが使用できるクラスを細かに制御することができました。この機能によって、アプリケーションの MANIFEST.MF ファイルまたは jboss-deployment-structure.xml デプロイメント記述子ファイルを使用して暗示的なモジュール依存関係を設定できました。

アプリケーションで明示的なモジュール依存関係を定義した場合、JBoss EAP 7 で変更になった以下の項目に注意してください。

利用可能な依存関係の確認

JBoss EAP に含まれるモジュールが変更されました。アプリケーションを JBoss EAP 7 に移行する場合、MANIFEST.MF および jboss-deployment-structure.xml ファイルエントリーを確認し、これらのエントリーが本リリースで削除されたモジュールを参照しないようにしてください。

アノテーションのスキャンに必要な依存関係

以前のリリースの JBoss EAP では、EJB インターセプターの宣言時など、アノテーションのスキャン中に処理される必要があるアノテーションが依存関係に含まれていると、Jandex インデックスを生成して新しい JAR ファイルに含まれるようにし、MANIFEST.MF または jboss-deployment-structure.xml デプロイメント記述子ファイルにフラグを設定する必要がありました。

JBoss EAP 7 では、静的モジュールに対するアノテーションインデックスの自動ランタイム生成が提供されるため、手動で生成する必要がなくなりました。しかし、JBoss EAP 7 でも以下のように annotations フラグを MANIFEST.MF ファイルまたは jboss-deployment-structure.xml デプロイメント記述子ファイルに追加する必要があります。

Dependencies: com.company.my-ejb annotations, com.company.other

<jboss-deployment-structure>
  <deployment>
    <dependencies>
      <module name="com.company.my-ejb" annotations="true"/>
      <module name="com.company.other"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

Hibernate ORM 5.0

アプリケーションに persistence.xml ファイルが含まれる場合や、コードが @PersistenceContext または @PersistenceUnit アノテーションを使用する場合、JBoss EAP 7 はデプロイメント中にこれを検出し、アプリケーションは JPA を使用すると仮定します。Hibernate ORM 5.O ライブラリーとその他の依存関係の一部が暗黙的にアプリケーションのクラスパスに追加され、デフォルトでこれらのライブラリーが使用されます。

Hibernate ORM 4.0 - 4.3

アプリケーションが 2 次キャッシュの有効化を必要とする場合、Infinispan 8.0 と統合されている Hibernate ORM 5.0 に移行してください。

Hibernate ORM 4.x で書かれているアプリケーションは今後も Hibernate 4.x を使用できます。Hibernate 4.x JAR のカスタム JBoss モジュールを定義し、アプリケーションから Hibernate 5 クラスを除外する必要があります。しかし、Hibernate 5 を使用するようアプリケーションコードを書き直すことが強く推奨されます。

Hibernate 4 と Hibernate 5 で変更になった内容に関する詳細は Hibernate ORM 5.0 Migration Guide を参照してください。

Hibernate ORM 3.0

前リリースで Hibernate 3 の使用を容易にした統合クラスは JBoss EAP 7 から削除されました。大きく手を加えないと Hibernate 3 は JBoss EAP では動作しないため、アプリケーションが Hibernate 3 ライブラリーを使用する場合は、Hibernate 5 を使用するようアプリケーションを移行することが強く推奨されます。Hibernate 5 に移行できない場合、Hibernate 3 JAR のカスタム JBoss Module を定義し、アプリケーションから Hibernate 5 クラスを除外する必要があります。

JBoss EAP 7 に同梱される Hibernate Search のバージョンが変更になりました。以前のリリースの JBoss EAP には Hibernate Search 4.6.x が含まれていましたが、JBoss EAP 7 には Hibernate Search 5.5.x が同梱されます。

Hibernate Search 5.5 は Apache Lucene 5.3.1 に構築されます。ネイティブ Lucene API を使用する場合は、必ずこのバージョンに合わせてください。Hibernate Search 5.5 API は、バージョン 3 からバージョン 5 の間に加えられた複雑な Lucene API の変更の多くをラップし、隠していますが、クラスの一部は非推奨となったり、名前変更または再パッケージされています。ここでは、これらの変更がアプリケーションコードに与える影響について説明します。

Hibernate Search マッピングの変更

埋め込み関係の ID フィールドのインデックス化

@IndexedEmbedded アノテーションを使用して関連エントリーからのフィールドを含む場合、関連エントリーの id が含まれなくなりました。id が含まれるようにするには、@IndexedEmbedded アノテーションの includeEmbeddedObjectId 属性を使用します。

@IndexedEmbedded(includeEmbeddedObjectId=true)

番号および日付のインデックス形式の変更

番号や日付はデフォルトで数字フィールドとしてインデックス化されるようになりました。タイプ int、long、float、double のプロパティーおよびこれらのラッパークラスは文字列としてインデックス化されないようになりました。代わりに、これらは Lucene の適切な数字エンコーディングを使用してインデックス化されるようになりました。id フィールドはこのルールの例外で、 数字タイプによって表されても、デフォルトで文字列キーワードとしてインデックス化されます。@NumericField の使用は、数字エンコーディングのカスタム精度を指定する場合以外は廃止されました。文字列エンコーディングフィールドブリッジを明示的に指定すると、これまでの文字列ベースのインデックス形式を保持できます。整数の場合は org.hibernate.search.bridge.builtin.IntegerBridge になります。公開されているその他の使用可能なフィールドブリッジは、org.hibernate.search.bridge.builtin パッケージを確認してください。

Date および Calendar は文字列としてインデックス化されないようになりました。代わりに、インスタンスは 1970 年 1 月 1 日グリニッジ標準時 00:00:00 からの期間 (ミリ秒) を表す長整数としてエンコードされます。新しい EncodingType 列挙を使用するとインデックス形式を切り替えできます。以下に例を示します。

@DateBridge(encoding=EncodingType.STRING)
@CalendarBridge(encoding=EncodingType.STRING)

数字と日付のエンコーディングの変更は重要で、アプリケーションの動作に大きく影響する可能性があります。以前は文字列にエンコードされ、現在は数字にエンコードされるフィールドをターゲットとするクエリーがある場合、クエリーを更新する必要があります。NumericRangeQuery で数字フィールドを検索する必要があります。また、ファセッティングがターゲットとするすべてのフィールドが文字列でエンコードされるようにする必要があります。Search クエリー DSL を使用する場合、適切なクエリーが自動的に作成されるはずです。

その他の Hibernate Search の変更

Hibernate Search の名前変更および再パッケージされたクラス

以下は、名前変更または再パッケージされた Hibernate Search クラスのリストになります。

Lucene - 名前変更および再パッケージされたクラス

クエリーパーサーが新しいモジュールに移動されたため、パッケージが org.apache.lucene.queryParser.QueryParser から org.apache.lucene.queryparser.classic.QueryParser に変更になりました。

Lucene アナライザーの多くがリファクターされたため、パッケージが変更になりました。Apache Lucene Documentation を参照してください。

TokenizerFactory や TokenFilterFactory などの Apache Solr ユーティリティークラスの一部が Apache Lucene に移動されました。これらのユーティリティーやカスタムアナライザーがアプリケーションによって使用される場合は、Apache Lucene で新パッケージ名を探す必要があります。

詳細は Apache Lucene Migration Guide を参照してください。

Hibernate Search で非推奨となった API

Hibernate Search で非推奨となったインターフェース、クラス、列挙、アノテーションタイプ、メソッド、コンストラクター、および列挙定数の完全リストは、Hibernate Search Deprecated API ドキュメントを参照してください。

Hibernate Search で非推奨となったインターフェース

Hibernate Search で非推奨となったクラス

Hibernate Search で非推奨となった列挙

Hibernate Search で非推奨となったアノテーション

Hibernate Search で非推奨となったメソッド

Hibernate Search で非推奨となったコンストラクター

上級インテグレーターに影響する変更

ここでは、パブリック API の一部ではない変更について説明します。これらのアーティファクトは、Hibernate Search フレームワークを拡張するインテグレーターのみがアクセスできる必要があるため、通常の開発者には影響はないはずです。

Java EE 7 では EJB エンティティー bean のサポートが任意となり、JBoss EAP 7 ではサポート対象外になりました。そのため、JBoss EAP 7 への移行時に CMP (Container-Managed Persistence) および BMP (Bean-Managed Persistence) エンティティー bean を書き直し、Java Persistence API (JPA) エンティティーを使用するようにする必要があります。

以前のリリースの JBoss EAP では、javax.ejb.EntityBean クラスを拡張し、必要なメソッドを実装してエンティティー bean がアプリケーションのソースコードに作成されました。作成後、エンティティー bean は ejb-jar.xml ファイルで設定されました。CMP エンティティー bean は、値が Container の <persistence-type> 子要素が含まれる <entity> 要素を使用して指定されました。BMP エンティティー bean は、値が Bean の <persistence-type> 子要素が含まれる <entity> 要素を使用して指定されました。

JBoss EAP 7 では、コードの CMP および BMP エンティティー bean を Java Persistence API (JPA) エンティティーに置き換える必要があります。JPA エンティティーは javax.persistence.* クラスを使用して作成され、persistence.xml ファイルに定義されます。

以下は JPA エンティティークラスの例になります。

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
// User is a keyword in some SQL dialects!
@Table(name = "MyUsers")
public class MyUser {
    @Id
    @GeneratedValue
    private Long id;

    @Column(unique = true)
    private String username;
    private String firstName;
    private String lastName;

    public Long getId() {
        return id;
    }
    public String getUsername() {
        return username;
    }
    public void setUsername(String username) {
        this.username = username;
    }
    public String getFirstName() {
        return firstName;
    }
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

以下は persistence.xml ファイルの例になります。

<persistence version="2.1"
      xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="
        http://xmlns.jcp.org/xml/ns/persistence
        http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
  <persistence-unit name="my-unique-persistence-unit-name">
    <properties>
      // properties...
    </properties>
  </persistence-unit>
</persistence>

JAP エンティティーの実施例は、JBoss EAP 7 に同梱される bmt、cmt、および hibernate5 クイックスタートを参照してください。

これまでの JBoss EAP リリースでの永続性動作と互換性を維持するため、新しい永続プロパティー jboss.as.jpa.deferdetach が追加されました。

jboss.as.jpa.deferdetach プロパティーは、非 JTA トランザクションスレッドで使用されるトランザクションスコープの永続コンテキストが各 EntityManager 呼び出しの後にロードされたエントリーをデタッチするかどうか、または永続コンテキストが閉じられるまで待機するかどうか (セッション bean が終了するときなど) を制御します。このプロパティーのデフォルト値は false で、各 EntityManager 呼び出しの後にエンティティーがデタッチまたは消去されます。これは、JPA 仕様 で定義されている正しいデフォルト動作です。プロパティーの値が true に設定されると、永続コンテキストが閉じられるまでエンティティーはデタッチされません。

JBoss EAP 5 では、jboss.as.jpa.deferdetach プロパティーが true に設定された場合と同様に永続性が動作しました。JBoss EAP 5 から JBoss EAP 7 に移行するときにこの動作を保持するには、以下の例のように persistence.xml で jboss.as.jpa.deferdetach プロパティーの値を true に設定する必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
    <persistence-unit name="EAP5_COMPAT_PU">
    <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
    <properties>
         <property name="jboss.as.jpa.deferdetach" value="true" />
    </properties>
  </persistence-unit>
</persistence>

In JBoss EAP 6 では、jboss.as.jpa.deferdetach プロパティーが false に設定された場合と同様に永続性が動作しました。 これは JBoss EAP 7 での動作と同じであるため、アプリケーションの移行時に変更を加える必要はありません。

JBoss EAP 7 ではデフォルトのリモートコネクターおよびポートが変更になりました。この変更の詳細は リモート URL コネクターおよびポートの更新を参照してください。

migrate 操作を使用してサーバー設定を移行した場合は、旧設定は保持されるため以下の変更を行う必要はありません。しかし、新しい JBoss EAP 7 のデフォルト設定で実行する場合は以下の変更を行う必要があります。

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=remote://localhost:4447

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=http-remoting://localhost:8080

Java EE Application Deployment 仕様 (JSR-88) は、すべての Java EE プラットフォームの製品でアプリケーションを設定およびデプロイするため、複数のプロバイダーからツールを有効にする標準的なコントラクトを定義することが目的でした。コントラクトは、Java EE Product Provider が DeploymentManager を実装し、Tool Provider が他の javax.enterprise.deploy.spi インターフェースにアクセスすることを必要としました。JBoss EAP 6 の場合、デプロイメント計画は、ZIP または JAR アーカイブでバンドルされる deployment-plan.xml という XML 記述子によって識別されます。

ほとんどのアプリケーションサーバー製品は、より機能の充実した独自のデプロイメントソルーションを提供するため、この仕様の採用は限定的でした。そのため、JSR-88 のサポートは JBoss EE 7 より廃止されたため、JBoss EAP 7 でも廃止されました。

アプリケーションのデプロイに JSR-88 を使用した場合、他の方法を使ってアプリケーションをデプロイする必要があります。JBoss EAP 管理 CLI の deploy コマンドを使用すると、アーカイブをスタンドアロンサーバーや管理対象ドメインのサーバーグループにデプロイする標準的な方法を実行できます。管理 CLI についての詳細情報は、Management CLI Guide を参照してください。

カスタムバルブまたは jboss-web.xml XML ファイルで定義されたバルブは、手動で移行する必要があります。これには、org.apache.catalina.valves.ValveBase クラスを拡張して作成されたバルブや、jboss-web.xml 記述子ファイルの <valve> 要素で設定されたバルブが含まれます。

デプロイメントで設定されたバルブの移行

JBoss EAP 6 では、カスタムバルブを jboss-web.xml web アプリケーション記述子ファイルで設定するとアプリケーションレベルで定義することができました。JBoss EAP 7 では、Undertow ハンドラーを使用して定義することもできます。

以下は、JBoss EAP 6 の jboss-web.xml ファイルに設定されたバルブの例になります。

<jboss-web>
    <valve>
        <class-name>org.jboss.examples.MyValve</class-name>
​        <param>
    ​        <param-name>myParam</param-name>
​            <param-value>foobar</param-value>
    ​    </param>
    </valve>
</jboss-web>

JBoss EAP でカスタムハンドラーを作成および設定する方法の詳細は、JBoss EAP Development Guide の Creating Custom Handlers を参照してください。

カスタムオーセンティケーターバルブの移行

オーセンティケーターバルブを移行する方法については、セキュリティーアプリケーションの変更を参照してください。

JBoss Web を Undertow で置き換えるには、JBoss EAP 7 のセキュリティー設定における変更が必要になります。

アプリケーションが JBoss Logging を使用する場合、org.jboss.logging パッケージのアノテーションは JBoss EAP 7 では非推奨になったことに注意してください。アノテーションは org.jboss.logging.annotations パッケージに移動されたため、ソースコードを更新して新しいパッケージをインポートする必要があります。

また、アノテーションは個別の Maven groupId:artifactId:version (GAV) ID に移動されたため、プロジェクトの pom.xml ファイルで org.jboss.logging:jboss-logging-annotations の新しいプロジェクト依存関係を追加する必要があります。

非推奨となったアノテーションクラスと代替クラスを以下の表に示します。

JSF 1.2 のサポート停止

JBoss EAP 6 では、jboss-deployment-structure.xml ファイルを作成して、アプリケーションデプロイメントで JSF 1.2 の使用を継続することができました。

JBoss EAP 7 には JSF 2.2 が含まれ、JSF 1.2 API はサポート対象外になりました。アプリケーションが JSF 1.2 を使用する場合、JSF 2.2 を使用するようアプリケーションを書き直す必要があります。

JSF 2.1 および JSF 2.2 の互換性の問題

JSF 2.1 API と JSF 2.2 API は完全に互換性があるわけではありません。リリース間で、FACELET_CONTEXT_KEY 定数値が com.sun.faces.facelets.FACELET_CONTEXT から javax.faces.FACELET_CONTEXT に変更されました。この値はコンパイラーによってインライン化され、どちらかのリリースに対してコンパイルされたコードは他のリリースでは動作しません。

以下の例に似たコードが含まれ、JSF 2.1 API でコンパイルされたアプリケーションが JSF 2.2 API を使用する JBoss EAP 7 で実行されると、NullPointerException が発生します。この問題を修正するには、アプリケーションを JSF 2.2 API に対してコンパイルする必要があります。

Object obj = FacesContext.getCurrentInstance().getAttributes().get(FaceletContext.FACELET_CONTEXT_KEY);

詳細は、JAVASERVERFACES_SPEC_PUBLIC-1257 を参照してください。

JBoss EAP 7 では、複数のモジュールに同じクラスまたはパッケージが含まれる場合のクラスローディングの動作が変更になりました。

お互いに依存し、一部同じパッケージが含まれる MODULE_A と MODULE_B の 2 つのモジュールがあるとします。JBoss EAP 6 では、依存関係からロードされたクラスまたはパッケージは module.xml ファイルの resource-root に指定されたものよりも優先されました。これは、MODULE_A は MODULE_B のパッケージを認識し、MODULE_B は MODULE_A のパッケージを認識したことを意味しますが、この動作は複雑で競合が発生することがありました。この動作は JBoss EAP 7 では変更になり、module.xml ファイルの resource-root によって指定されたクラスまたはパッケージは依存関係によって指定されたものよりも優先されるようになりました。これは、MODULE_A は MODULE_A のパッケージを認識し、MODULE_B は MODULE_B のパッケージを認識することを意味します。これにより、競合の発生を防ぎ、より適切な動作を提供します。

resource-root ライブラリーが含まれるカスタムモジュールまたは複製されたクラスがモジュール依存関係に含まれるパッケージを定義した場合、JBoss EAP 7 へ移行するときに ClassCastException、LinkageError、クラスローディングエラー、またはその他の動作の変更が発生することがあります。この問題を解決するには、module.xml ファイルを設定して 1 つのバージョンのクラスのみが使用されるようにする必要があります。これは、以下の方法の 1 つを使用して実現できます。

既存の動作を保持するには、filter 要素を使用して module.xml ファイルの依存する resource-root から依存パッケージをフィルターする必要があります。これにより、JBoss EAP 6 で見られる odd loop なしで既存の動作を保持できます。以下は、指定のパッケージのクラスをフィルターする root-resource の例になります。

<resource-root path="mycompany.jar">
  <filter>
    <exclude path="com/mycompany/duplicateclassespath"/>
  </filter>
</resource-root>

モジュールおよびクラスローディングの詳細は、JBoss EAP Development Guide の Class Loading and Modules を参照してください。