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

XML ベースの RPC (JAX-RPC) は Java EE 6 で非推奨となり、Java EE 7 ではオプションとなりました。JAX-RPC は JBoss EAP 7 では使用できず、サポートされません。JAX-RPC を使用するアプリケーションは、現在の Java EE 標準の Web サービスフレームワークである JAX-WS を使用するように移行する必要があります。

JAX-RPC web サービスの使用は、以下のいずれかの方法で特定できます。

以前のリリースの JBoss EAP では、エンドポイントデプロイメントアーカイブを jbossws-cxf.xml 設定ファイルに含め、JBossWS と Apache CXF の統合をカスタマイズすることができました。このユースケースの 1 つが、Apache CXF バスで Web サービスクライアントおよびサーバーエンドポイントのインターセプターチェインを設定することでした。この統合には、JBoss EAP サーバーに Spring をデプロイする必要がありました。

JBoss EAP 7 では、Spring の統合がサポートされないようになりました。jbossws-cxf.xml 記述子設定ファイルが含まれるアプリケーションを編集し、このファイルに定義されているカスタム設定を置き換える必要があります。JBoss EAP 7 でも Apache CXF API に直接アクセスすることはできますが、アプリケーションは移植できないことに注意してください。

可能な場合は、Spring のカスタム設定を新しい JBossWS 記述子設定オプションに置き換えることが推奨されます。この JBossWS 記述子ベースの方法では、クライアントエンドポイントコードを編集する必要がなく、同様の機能を提供できます。場合によっては、Spring を Context and Dependency Injection (コンテキストと依存性の注入、CDI) に置き換えることができます。

Apache CXF インターセプター

JBossWS 記述子は、クライアントエンドポイントコードを編集せずにインターセプターを宣言できる新しい設定オプションを提供します。 cxf.interceptors.in および cxf.interceptors.out プロパティーのインターセプタークラス名のリストを指定して、事前定義されたクライアントおよびエンドポイント設定内でインターセプターを宣言します。

以下は、これらのプロパティーを使用してインターセプターを宣言する jaxws-endpoint-config.xml ファイルの例です。

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

Apache CXF の機能

JBossWS 記述子を使用すると、cxf.features プロパティーの機能クラス名のリストを指定して、事前定義のクライアントおよびエンドポイント設定内で機能を宣言できます。

以下は、このプロパティーを使用して機能を宣言する jaxws-endpoint-config.xml ファイルの例です。

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

Apache CXF HTTP トランスポート

Apache CXF では、org.apache.cxf.transport.http.HTTPConduit オプションを指定すると HTTP トランスポートの設定を実行できます。JBossWS の統合により、以下のように Apache CXF API を使用して conduit がプログラム的に編集されます。

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

また、システムプロパティーを設定すると Apache CXF HTTPConduit のデフォルト値を制御および上書きできます。

cxf-api および cxf-rt-core JAR が 1つの cxf-core JAR に統合されました。そのため、JBoss EAP の org.apache.cxf モジュールに cxf-core JAR が含まれるようになり、これまでのリリースよりも多いクラスが公開されました。

XML/WS-Security での対称暗号化で Galois/Counter Mode (GCM) を用いた AES 暗号化を使用したい場合、BouncyCastle Security Provider が必要になります。

JBoss EAP 7 には org.bouncycastle モジュールが同梱されているため、JBossWS はそのクラスローダーに依存して BouncyCastle Security Provider を入手および使用できるようになりました。そのため、現在の JVM に BouncyCastle を静的にインストールする必要がなくなりました。コンテナーの外部で実行しているアプリケーションの場合、BouncyCastle ライブラリーをクラスパスに追加すると JBossWS はこのセキュリティープロバイダーを使用できます。

この動作を無効にするには、jaxws-endpoint-config.xml デプロイメント記述子ファイル (サーバーの場合) または jaxws-client-config.xml 記述子ファイル (クライアントの場合) で org.jboss.ws.cxf.noLocalBC プロパティーの値を true に設定します。

JBoss EAP に同梱されるバージョンでないものを使用したい場合は、BouncyCastle を静的に JVM にインストールできます。この場合、静的にインストールされた BouncyCastle Security Provider はクラスパスに存在するプロバイダーよりも優先的に選択されます。この問題を回避するには、BouncyCastle 1.49、1.51、またはそれ以降のバージョンを使用する必要があります。

コンテナー内で実行されているクライアントのデフォルトのバス選択ストラテジーが THREAD_BUS から TCCL_BUS に変更されました。コンテナー外部で実行されているクライアントのデフォルトストラテジーは THREAD_BUS で、変更はありません。以下の方法の 1 つを使用すると、以前のリリースでの動作を復元できます。

コンテナーは、コンストラクターで WebServiceFeature クラスが引数として含まれる JAX-WS 2.2 スタイルのコンストラクターを使用して、web サービス参照にインジェクトされるクライアントを構築する必要があります。JBossWS 4 が同梱される JBoss EAP 6.4 はこの要件を隠しますが、JBossWS 5 が同梱される JBoss EAP 7 はこの要件を隠さないようになりました。そのため、コンテナーによってインジェクトされたユーザー提供のサービスクラスが、WebServiceFeature 引数が 1 つ以上含まれる javax.xml.ws.Service コンストラクターを使用するよう既存コードを更新し、JAX-WS 2.2 以上を実装する必要があります。

protected Service(URL wsdlDocumentLocation,
       QName serviceName,
       WebServiceFeature... features)

以前のリリースでは、システムプロパティー org.jboss.security.ignoreHttpsHost を true に設定すると、証明書にあるサービスの一般名 (CN) に対する HTTPS URL ホスト名チェックを無効にすることができました。このシステムプロパティー名は cxf.tls-client.disableCNCheck に置き換えられました。

サービスエンドポイントおよびサービスクライアントハンドラーへのインジェクションが有効になったため、org.jboss.as.webservices.server.integration JBoss モジュールから自動的にハンドラークラスをロードすることができなくなりました。アプリケーションが事前定義の設定に依存する場合、デプロイメントの新しいモジュール依存関係を明示的に定義する必要があることがあります。詳細は「明示的なモジュール依存関係の移行」を参照してください。

Java Endorsed Standards Override Mechanism は JDK 1.8_40 では非推奨になり、JDK 9 では削除される予定です。これは、JAR を JRE 内の endorsed ディレクトリーに置くことで、デプロイされたアプリケーションすべてがライブラリーを利用できるメカニズムです。

アプリケーションが Apache CXF の JBossWS 実装を使用する場合、JBoss EAP 7 では必要な依存関係が正しい順序で追加されるため、この変更による影響はないはずです。 アプリケーションが Apache CXF に直接アクセスする場合、アプリケーションデプロイメントの一部として JBossWS の依存関係の後に Apache CXF の依存関係を提供する必要があります。

以前のリリースの JBoss EAP では、EJB Web サービスデプロイメントの jboss-webservices.xml デプロイメント記述子ファイルを JAR アーカイブの META-INF/ ディレクトリーまたは POJO Web サービスデプロイメントの WEB-INF/ ディレクトリーと、WAR アーカイブにバンドル化された EJB Web サービスエンドポイントに設定することができました。

JBoss EAP 7 では、jboss-webservices.xml デプロイメント記述子ファイルを EAR アーカイブの META-INF/ ディレクトリーで設定できるようになりました。jboss-webservices.xml ファイルが EAR アーカイブと JAR (または WAR) アーカイブの両方で見つかった場合、JAR または WAR の jboss-webservices.xml ファイルにある設定データによって EAR 記述子ファイルの対応するデータが上書きされます。

ネーミングパターン -jms.xml によって識別されたプロプライエタリーの HornetQ JMS リソースデプロイメント記述子ファイルは JBoss EAP 7 では動作しません。以下は、JBoss EAP 6 での JMSリソースデプロイメント記述子ファイルの例になります。

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0">
  <hornetq-server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </hornetq-server>
</messaging-deployment>

以前のリリースで -jms.xml JMS デプロイメント記述子をアプリケーションで使用した場合、 Java EE 7 仕様の EE.5.18 で指定されたとおりに標準の Java EE 7 デプロイメント記述子を使用するようアプリケーションを変換するか、 messaging-activemq-deployment スキーマを使用するようデプロイメント記述子を更新してください。

記述子の更新を選択した場合、以下の変更を加える必要があります。

編集後のファイルは以下の例のようになるはずです。

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-activemq-deployment:1.0">
  <server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </server>
</messaging-deployment>

メッセージングに関するサーバー設定の変更については、「メッセージングサーバー設定の変更」を参照してください。

JBoss EAP 7 は JMS 1.1 API をサポートするため、コードを変更する必要はありません。

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

migrate 操作を使用してサーバー設定を移行する場合、これまでの設定は保持され、PROVIDER_URL を更新する必要はありません。しかし、新しい JBoss EAP 7 のデフォルト設定を使用して実行する場合は、新しい http-remoting://localhost:8080 設定を使用するよう PROVIDER_URL を変更する必要があります。詳細は「リモートネーミングクライアントコードの移行」を参照してください。

JMS 2.0 API を使用するためにコードを移行する計画がある場合は、作業例を helloworld-jms クイックスタートで確認してください。

JBoss EAP 6 には org.hornetq モジュールが含まれ、これによりアプリケーションソースコードで HornetQ API が使用できました。

JBoss EAP 7 では HornetQ が Apache ActiveMQ Artemis に置き換えられたため、HornetQ API を使用したコードは Apache ActiveMQ Artemis API を使用するように移行する必要があります。この API のライブラリーは、org.apache.activemq.artemis モジュールに含まれています。

ActiveMQ Artemis は HornetQ の進化版なので、概念の多くは継続して適用されます。

インターセプターおよび MessageBody クラス

JSR 311: JAX-RS: The Java™ API for RESTful Web Services にはインターセプターフレームワークが含まれなかったため、RESTEasy 2 によって提供されました。JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services によって正式なインターセプターおよびフィルターフレームワークが導入されたため、RESTEasy 2 に含まれたインターセプターフレームワークは非推奨になり、RESTEasy 3.x の JAX-RS 2.0 対応インターセプターファシリティーに置き換えられました。関係するインターフェースは、 jaxrs-api モジュールの javax.ws.rs.ext パッケージに定義されます。

インターセプターについての詳細情報は、JBoss EAP『Developing Web Services Applications』の「RESTEasy Interceptors」を参照してください。

新しい代替の API については、RESTEasy JAX-RS 3.0.13.Final API もしくはそれ以降を参照してください。

クライアント API

resteasy-jaxrs の RESTeasy クライアントフレームワークは、JAX-RS 2.0 準拠の resteasy-client モジュールに置き換えられました。そのため、RESTEasy クライアント API クラスおよびメソッドの中には非推奨となっているものもあります。

StringConverter

org.jboss.resteasy.spi.StringConverter クラスは RESTEasy 3.x では非推奨になりました。この機能は JAX-RS 2.0 の jax.ws.rs.ext.ParamConverterProvider クラスを使用して置き換えできます。

ResteasyProviderFactory Add メソッド

org.jboss.resteasy.spi.ResteasyProviderFactory add() メソッドのほとんどは、RESTEasy 3.0 で削除または保護されました。たとえば、addBuiltInMessageBodyReader() および addBuiltInMessageBodyWriter() メソッドは削除され、 addMessageBodyReader() および addMessageBodyWriter() メソッドは保護されました。

現時点では、registerProvider() と registerProviderInstance() のメソッドを使用してください。

RESTEasy 3 から削除された他のクラス

@org.jboss.resteasy.annotations.cache.ServerCached アノテーションは、JAX-RS メソッドへの応答をサーバーでキャッシュすることを指定するものでしたが、これは RESTEasy 3 から削除されたので、アプリケーションコードから削除する必要があります。

SignedInput および SignedOuput

セキュリティーフィルター

@RolesAllowed、@PermitAll、および @DenyAll のセキュリティーフィルターは、"401 Unauthorized" ではなく "403 Forbidden" を返すようになりました。

クライアント側のフィルター

以前のリリースからの RESTEasy クライアント API を使用している場合は、新しい JAX-RS 2.0 クライアント側のフィルターはバインドされず、実行されません。

非同期 HTTP サポート

JAX-RS 2.0 仕様は、@Suspended アノテーションと AsynResponse インターフェースを使用した非同期 HTTP サポートを追加するため、非同期 HTTP の RESTEasy プロプライエタリー API は非推奨となりました。今後の RESTEasy リリースで削除される可能性があります。非同期 Tomcat と非同期 JBoss Web モジュールもサーバーインストールから削除されています。Servlet 3.0 コンテナーまたはそれ以降を使用していない場合、非同期 HTTP サーバー側の処理がシミュレートされ、同一リクエストスレッドで同期的に実行されます。

サーバー側のキャッシュ

サーバー側のキャッシュ設定が変更されました。詳細は、「RESTEasy Documentation」を参照してください。

YAML プロバイダーの設定変更

以前のリリースの JBoss EAP では、RESTEasy YAML プロバイダー設定はデフォルトで有効になっていました。これは JBoss EAP 7 で変更になり、YAML プロバイダーはデフォルトで無効になっています。アンマーシャリングで RESTEasy によって使用される SnakeYAML ライブラリーにセキュリティー上の問題があるため、YAML プロバイダーの使用はサポートされず、アプリケーションで明示的に有効にする必要があります。アプリケーションで YAML プロバイダーを有効にし、Maven 依存関係を追加する方法については、JBoss EAP『Developing Web Services Applications』の「YAML Provider」を参照してください。

Content-Type ヘッダーのデフォルトの文字セット UTF-8

JBoss EAP 7.1 では、デフォルトで resteasy.add.charset パラメーターが true に設定されています。リソースメソッドが明示的な文字セットなしで text/* または application/xml* メディアタイプを返すときに、返された content-type ヘッダーに charset=UTF-8 を追加したくない場合は、resteasy.add.charset パラメーターを false に設定できます。

テキストメディアタイプと文字セットに関する詳細は、JBoss EAP『Developing Web Services Applications』の「Text Media Types and Character Sets」を参照してください。

SerializableProvider

信用できないソースから Java オブジェクトをデシリアライズすることは危険です。そのため、JBoss EAP 7 では org.jboss.resteasy.plugins.providers.SerializableProvider クラスがデフォルトで無効となり、このプロバイダーの使用は推奨されません。

リソースメソッドへのリクエストの一致

RESTEasy 3 では、JAX-RS 2.0 仕様の定義どおりに、一致ルールの実装に改善および修正が加えられました。特に、サブリソースメソッドおよびサブリソースロケーターのあいまいな URI の処理方法が変更されました。

RESTEasy 2 では、同じ URI を持つ別のサブリソースが存在していても、サブリソースロケーターが正常に実行される可能性がありました。仕様上ではこの挙動は適切ではありません。

RESTEasy 3 では、サブリソースおよびサブリソースロケーターのあいまいな URI が存在する場合、サブリソースの呼び出しには成功しますが、サブリソースロケーターの呼び出しは HTTP ステータス 405 Method Not Allowed のエラーによって失敗します。

以下の例には、サブリソースメソッドおよびサブリソースロケーターのあいまいな @Path アノテーションが含まれています。エンドポイント anotherResource および anotherResourceLocator 両方の URI は同じであることに注目してください。この 2 つのエンドポイントの違いは、anotherResource メソッドは REST 動詞である POST に関連付けられていることです。anotherResourceLocator メソッドに関連付けられている REST 動詞はありません。仕様上では、REST 動詞を持つエンドポイント (この場合は anotherResource メソッド) が常に選択されます。

@Path("myResource")
public class ExampleSubResources {
    @POST
    @Path("items")
    @Produces("text/plain")
    public Response anotherResource(String text) {
        return Response.ok("ok").build();
    }

    @Path("items")
    @Produces("text/plain")
    public SubResource anotherResourceLocator() {
        return new SubResource();
    }
}

SPI 例外

すべての SPI 失敗例外は非推奨となり、内部的には使用されません。これらは対応する JAX-RS 2.0 例外に置き換えられました。

InjectorFactory および Registry

InjectorFactory および Registry SPI が変更されました。ドキュメントに従ってサポートされるように RESTEasy を使用する場合は、問題はありません。

JBoss EAP に含まれる Jackson のバージョンは変更されました。JBoss EAP の以前のリリースに含まれていた Jackson は 1.9.9 でしたが、JBoss EAP 7 には Jackson 2.6.3 またはそれ以降が含まれています。このため、Jackson プロバイダーは resteasy-jackson-provider から resteasy-jackson2-provider に変更されました。

resteasy-jackson2-provider へのアップグレードにはいくつかのパッケージ変更が必要になります。たとえば、Jackson アノテーションパッケージは org.codehaus.jackson.annotate から com.fasterxml.jackson.annotation に変更されました。

JBoss EAP の以前のリリースに含まれていたデフォルトのプロバイダーを使用するようにアプリケーションを切り替えるには、JBoss EAP『Developing Web Services Applications』の「Switching the Default Jackson Provider」を参照してください。

Spring 4.0 フレームワークには、Java 8 のサポートが導入されました。Spring と RESTEasy 3.x 統合を使用する場合は、使用するデプロイメントで最小 Spring バージョンに 4.2.x を指定してください。これは JBoss EAP 7 がサポートする安定性のある最も早期のバージョンです。

RESTEasy Jettison JSON プロバイダーは JBoss EAP 7 では非推奨となり、デフォルトでデプロイメントに追加されなくなりました。推奨される RESTEasy Jackson プロバイダーに切り替えるようにしてください。Jettison プロバイダーの使用継続を希望する場合は、以下の例で示すように jboss-deployment-descriptor.xml ファイルでその明示的な依存関係を定義する必要があります。

<?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『開発ガイド』の「デプロイメントへの明示的なモジュール依存関係の追加」を参照してください。

以前のリリースの Hibernate ORM 3 を簡単に使用できるようにする統合クラスは JBoss EAP 7 から削除されました。膨大な作業を行わないと JBoss EAP で Hibernate ORM 3 を実行できなくなったため、アプリケーションが Hibernate ORM 3 ライブラリーを使用する場合は、アプリケーションを移行して Hibernate ORM 5 を使用するようにすることが強く推奨されます。Hibernate ORM 5 へ移行できない場合は、Hibernate ORM 3 JAR のカスタム JBoss モジュールを定義し、アプリケーションから Hibernate ORM 5 のクラスを除外する必要があります。

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

Hibernate ORM 4.x で作成されたアプリケーションは Hibernate ORM 4.x を引き続き使用できます。Hibernate ORM 4.x JAR のカスタム JBoss モジュールを定義し、アプリケーションから Hibernate ORM 5 クラスを排除する必要があります。しかし、Hibernate ORM 5 を使用するようにアプリケーションコードを書き直すことが強く推奨されます。Hibernate ORM 5 への移行に関する情報は、「Hibernate ORM 5 への移行」を参照してください。

ここでは、Hibernate ORM をバージョン 4.3 からバージョン 5 に移行する際に必要な変更について説明します。Hibernate ORM 4 から Hibernate ORM 5 の間に実装された変更については、『Hibernate ORM 5.0 Migration Guide』を参照してください。

削除および非推奨となったクラス

以下のクラスは非推奨となり、Hibernate ORM 5 から削除されました。

クラスおよびパッケージのその他の変更

タイプ処理

トランザクション管理

Hibernate ORM 5 のその他の変更

JBoss EAP 7.0 には Hibernate ORM 5.0 が含まれていましたが、JBoss EAP 7.1 には Hibernate ORM 5.1 が含まれています。ここでは、この 2 つの違いと、Hibernate ORM のバージョン 5.0 からバージョン 5.1 に移行する際に必要な変更について説明します。

Hibernate ORM 5.1 の機能

このリリースには、JBoss EAP 7.1.0 リリースノート の Hibernate ORM 5.1 の機能 に記載されているパフォーマンスの改善やバグ修正が含まれます。Hibernate ORM 5.0 から Hibernate ORM 5.1 の間に実装された変更に関する詳細は、『Hibernate ORM 5.1 Migration Guide』を参照してください。

スキーマ管理ツールの変更

JBoss EAP 7 でのスキーマ管理ツールの変更

Hibernate ORM 5.1 のスキーマ管理ツールは、主に以下の項目を中心に変更されています。

移行時にスキーマ管理ツールの変更に注意する必要があるのは、以下のクラスを直接使用するアプリケーションのみです。

JBoss EAP 7.1 でのスキーマ管理ツールの変更

JBoss EAP 7.1 に含まれる Hibernate ORM 5.1.10 には、SchemaMigrator および SchemaValidator のパフォーマンスを向上するデータベーステーブル取得の新しいストラテジーが導入されました。このストラテジーは、単一の java.sql.DatabaseMetaData#getTables(String, String, String, String[]) 呼び出しを実行して、各 javax.persistence.Entity がマップされたデータベーステーブルを持っているかどうかを判断します。これはデフォルトのストラテジーで、hibernate.hbm2ddl.jdbc_metadata_extraction_strategy=grouped プロパティー設定を使用します。このストラテジーには、hibernate.default_schema や hibernate.default_catalog を提供する必要があることがあります。

each javax.persistence.Entity に java.sql.DatabaseMetaData#getTables(String, String, String, String[]) 呼び出しを実行する旧式のストラテジーを使用するには、hibernate.hbm2ddl.jdbc_metadata_extraction_strategy=individually プロパティー設定を使用します。

JBoss EAP 7.0 では、同期されていない永続化コンテキストエラーチェックが以下の場合で厳格に行われませんでした。

さらに、JBoss EAP 7.0 では @PersistenceContext でヒントする PersistenceProperty は誤って無視されました。

これらの問題は JBoss EAP 7.1 で修正されました。これらの更新によってアプリケーションの動作が不適切に変更されるため、後方互換性を提供して以前の動作を維持するために JBoss EAP 7.1 には 2 つの新しい永続化ユニットプロパティーが導入されました。

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

新しいデフォルトの JBoss EAP 7 設定で実行している場合、新しいデフォルトのリモートポートおよびコネクターを使用するようクライアントコードを変更する必要があります。

以下の例は、リモートネーミングプロパティーが JBoss EAP 6 のクライアントコードでどのように指定されていたかを示しています。

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

以下は、JBoss EAP 7 のクライアントコードでリモートネーミングプロパティーを指定する方法の例になります。

java.naming.factory.initial=org.wildfly.naming.client.WildFlyInitialContextFactory
java.naming.provider.url=http-remoting://localhost:8080

JBoss EAP 7.0 には JBoss EJB Client 2.1.4 が同梱されていましたが、JBoss EAP 7.1 には JBoss EJB Client 4.0.x が同梱され、API に複数の変更が追加されました。

JBoss EAP 6.4 で AuthenticatorBase を拡張するカスタムオーセンティケーターバルブを作成した場合、JBoss EAP 7.1 では手作業でカスタム HTTP 認証実装に置き換える必要があります。HTTP 認証メカニズムは elytron サブシステムで作成され、undertow サブシステムで登録されます。カスタム HTTP 認証メカニズムの実装方法に関する詳細は、JBoss EAP 『開発ガイド』の「カスタム HTTP メカニズムの開発 」を参照してください。

SSO の SAML v2 設定で必要となる変更についての情報は、JBoss EAP『How To Set Up SSO with SAML v2』の「Changes from Previous Versions of JBoss EAP」を参照してください。

Kerberos による SSO 設定についての相違点については、JBoss EAP『How to Set Up SSO with Kerberos』の「Differences from Configuring Previous Versions JBoss EAP」を参照してください。

以下のリストは、アプリケーションを JBoss EAP 6 から JBoss EAP 7 へ移行するときに注意する必要がある新しいクラスタリング機能の一部を示しています。

本セクションの残りの部分では、クラスタリングの変更がアプリケーションの JBoss EAP 7 への移行に及ぼす可能性のある影響について説明します。

JBoss EAP 7 では、新しい Web セッションクラスタリング実装が導入されました。これは、レガシーの JBoss Web サブシステムソースコードに密に結合された以前の実装に代わる実装です。

新しい Web セッションクラスタリング実装は、JBoss EAP プロプライエタリー Web アプリケーションの XML 記述子ファイルである jboss-web.xml にアプリケーションが設定される方法に影響します。以下は、このファイルのクラスタリング設定要素のみになります。

<jboss-web>
  ...
  <max-active-sessions>...</max-active-sessions>
  ...
  <replication-config>
    <replication-granularity>...</replication-granularity>
    <cache-name>...</cache-name>
  </replication-config>
  ...
</jboss-web>

以下の表は、jboss-web.xml ファイルの廃止された要素と同様の動作を実現する方法を説明しています。

新しいこの実装は、ライトスルーキャッシュストアとパッシベーションのみのキャッシュストアもサポートします。通常、ライトスルーキャッシュストアはインバリデーションキャッシュとともに使用されます。JBoss EAP 6 の web セッションクラスタリング実装は、インバリデーションキャッシュの使用時に適切に動作しませんでした。

JBoss EAP 6 では、以下の方法の 1 つでステートフルセッション Bean (SFSB) のクラスタリング動作を有効化する必要がありました。

JBoss EAP 7 では、クラスタリング動作を有効にする必要がなくなりました。デフォルトでは、HA プロファイルを使用してサーバーが起動された場合は SFSB の状態が自動的にレプリケートされます。

以下の方法の 1 つを使用すると、このデフォルト動作を無効にできます。

JBoss EAP 6 では、クラスタリングサービスの API はプライベートモジュールでサポートされませんでした。

JBoss EAP 7 には、アプリケーションによって使用されるパブリッククラスタリングサービス API が導入されました。新しいサービスは、ライトウェイトで簡単にインジェクトできるよう設計されています。外部の依存関係は必要ありません。

これらのサービスは、JBoss EAP 5 の HAPartition、JBoss EAP 6 の GroupCommunicationService、GroupMembershipNotifier、および GroupRpcDispatcher に代わるサービスです。これらの API は以前のリリースで利用できました。

詳細は、JBoss EAP『開発ガイド』の「クラスタリングサービスのパブリック API」を参照してください。

JBoss EAP 6 では、クラスター全体の HA シングルトンサービスに使用できるパブリック API がありませんでした。プライベートの org.jboss.as.clustering.singleton.* クラスを使用した場合、アプリケーションを JBoss EAP 7 に移行するときに新しいパブリックの org.wildfly.clustering.singleton.* パッケージを使用するようコードを変更する必要があります。

HA シングルトンに関する詳細は、JBoss EAP『開発ガイド』の「HA シングルトンサービス」を参照してください。HA シングルトンのデプロイメントに関する詳細は、JBoss EAP『開発ガイド』の「HA シングルトンデプロイメント」を参照してください。