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

5.1. Web サービスアプリケーションの変更

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

5.1.1. JAX-RPC サポートの変更

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 サービスの使用は、以下のいずれかの方法で特定できます。

  • JAX-RPC マッピングファイルの存在。これは、root 要素 <java-wsdl-mapping> のある XML ファイルです。
  • webservices.xml XML 記述子ファイルの存在。このファイルには <jaxrpc-mapping-file> 子要素が含まれる <webservice-description> 要素があります。以下に JAX-RPC Web サービスを定義する webservices.xml 記述子ファイルの例を示します。

    <webservices xmlns="http://java.sun.com/xml/ns/j2ee"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://www.ibm.com/webservices/xsd/j2ee_web_services_1_1.xsd" version="1.1">
      <webservice-description>
        <webservice-description-name>HelloService</webservice-description-name>
        <wsdl-file>WEB-INF/wsdl/HelloService.wsdl</wsdl-file>
        <jaxrpc-mapping-file>WEB-INF/mapping.xml</jaxrpc-mapping-file>
        <port-component>
          <port-component-name>Hello</port-component-name>
          <wsdl-port>HelloPort</wsdl-port>
          <service-endpoint-interface>org.jboss.chap12.hello.Hello</service-endpoint-interface>
          <service-impl-bean>
            <servlet-link>HelloWorldServlet</servlet-link>
          </service-impl-bean>
        </port-component>
      </webservice-description>
    </webservices>
  • ejb-jar.xml ファイルの存在。これには、JAX-RPC マッピングファイルを参照する <service-ref> が含まれます。

5.1.2. Apache CXF Spring 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.client.allowChunking

ブール値

チャンキングを使用してリクエストを送信するかどうかを指定します。

cxf.client.chunkingThreshold

整数

非チャンキングからチャンキングモードに切り替えるしきい値を設定します。

cxf.client.connectionTimeout

Long

接続タイムアウトをミリ秒単位で設定します。

cxf.client.receiveTimeout

Long

受信タイムアウトをミリ秒単位で設定します。

cxf.client.connection

文字列

Keep-Alive または close 接続タイプを使用するかどうかを指定します。

cxf.tls-client.disableCNCheck

ブール値

CN ホスト名チェックを無効化するかどうかを指定します。

5.1.3. WS-Security の変更

  • アプリケーションに、org.apache.ws.security.WSPasswordCallback クラスにアクセスするカスタムコールバックハンドラーが含まれている場合、このクラスは org.apache.wss4j.common.ext パッケージに移動されたため注意してください。
  • ほとんどの SAML Bean オブジェクトは org.apache.ws.security.saml.ext パッケージから org.apache.wss4j.common.saml package に移動されました。
  • RSA v1.5キートランスポートおよび関連するすべてのアルゴリズムの使用はデフォルトで禁止されています。
  • これまで、セキュリティートークンサービス (STS) は onBehalfOf トークンのみを検証しましたが、ActAs トークンも検証するようになりました。そのため、ActAs トークンに提供される UsernameToken に有効なユーザー名とパスワードを指定する必要があります。
  • SAML Bearer トークンには内部署名が必要になりました。署名の検証を有効または無効にするため、org.apache.wss4j.dom.validate.SamlAssertionValidatorクラスに setRequireBearerSignature() メソッドが含まれるようになりました。

5.1.4. JBoss モジュール構造の変更

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

5.1.5. Bouncy Castle の要件の変更

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、またはそれ以降のバージョンを使用する必要があります。

5.1.6. Apache CXF バス選択ストラテジー

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

  • org.jboss.ws.cxf.jaxws-client.bus.strategy システムプロパティーの値を THREAD_BUS に設定して JBoss EAP サーバーを起動します。
  • クライアントコードで選択ストラテジーを明示的に設定します。

5.1.7. WebServiceRef の JAX-WS 2.2 要件

コンテナーは WebServiceFeature を使用して JAX-WS 2.2 スタイルのコンストラクターを使用し、Web サービス参照へインジェクトされるクライアントを構築する必要があります。よって、コンテナーによってインジェクトされるユーザー提供のサービスクラスは JAX-WS 2.2 以上を実装する必要があります。

5.1.8. IgnoreHttpsHost CN チェックの変更

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

5.1.9. サーバー側設定およびクラスローディング

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

5.1.10. Java Endorsed Standards Override Mechanism の非推奨

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 の依存関係を提供する必要があります。

5.1.11. EAR アーカイブでの記述子の仕様

以前のリリースの 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 記述子ファイルの対応するデータが上書きされます。

5.2. リモート URL コネクターおよびポートの更新

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 を変更する必要があります。

5.3. メッセージングアプリケーションの変更

5.3.1. JMS デプロイメント記述子の置き換えおよび更新

ネーミングパターン -jms.xml によって識別されたプロプラエタリーの 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 デプロイメント記述子を使用するようアプリケーションを変換するか、JBoss EAP 7 の messaging-activemq サブシステムを使用するようデプロイメント記述子を更新してください。

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

  • ネームスペースを "urn:jboss:messaging-deployment:1.0" から "urn:jboss:messaging-activemq-deployment:1.0" に変更します。
  • <hornetq-server> 要素名を <server> に変更します。

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

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

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

5.3.2. 外部 JMS クライアントの更新

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 クイックスタートで確認してください。

5.3.3. HornetQ API の置換

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 の進化版なので、概念の多くは継続して適用されます。

5.4. JAX-RS および RESTEasy アプリケーションの変更

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 を使用するアプリケーションにこれらの変更が及ぼす影響について説明します。

5.4.1. 非推奨の RESTEasy クラス

インターセプターおよび 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 パッケージに定義されます。

注記

RESTEasy の以前のリリースからのインターセプターはすべて、新規の JAX-RS 2.0 フィルターおよびインターセプターインターフェースと並行して実行することが可能です。

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

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

クライアント API

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

注記

org.jboss.resteasy.client.jaxrs API クラスの詳細については、The RESTEasy JAX-RS JavaDoc を参照してください。

StringConverter

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

5.4.2. 削除または保護されている RESTEasy クラス

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 から削除されたので、アプリケーションコードから削除する必要があります。

5.4.3. 他の RESTEasy 変更点

SignedInput および SignedOuput
  • resteasy-cryptoSignedInput および SignedOutput は、Content-TypeRequest または Response オブジェクトのいずれかから multipart/signed に設定する必要があります。そうでない場合は、@Consumes または @Produces アノテーションを使用する必要があります。
  • SignedOutput および SignedInput を使用すると、@Produces または @Consumes アノテーションで application/pkcs7-signature MIME タイプを設定して、そのタイプの形式をバイナリ形式で返すことができます。
  • @Produces または @Consumestext/plain MIME タイプの場合、SignedOutput は base64 でエンコードされ、文字列として送信されます。
セキュリティーフィルター

@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 3.1 にしてからできるだけ早く削除することが望まれます。非同期 Tomcat と非同期 JBoss Web モジュールもサーバーインストールから削除されています。Servlet 3.0 コンテナーまたはそれ以降を使用している場合以外は、非同期 HTTP サーバー側の処理がシミュレートされ、同一リクエストスレッドで同期的に実行されます。

サーバー側のキャッシュ

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

5.4.4. RESTEasy SPI の変更点

SPI 例外

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

非推奨の例外jaxrs-api モジュールでの代替の例外

org.jboss.resteasy.spi.ForbiddenException

javax.ws.rs.ForbiddenException

org.jboss.resteasy.spi.MethodNotAllowedException

javax.ws.rs.NotAllowedException

org.jboss.resteasy.spi.NotAcceptableException

javax.ws.rs.NotAcceptableException

org.jboss.resteasy.spi.NotFoundException

javax.ws.rs.NotFoundException

org.jboss.resteasy.spi.UnauthorizedException

javax.ws.rs.NotAuthorizedException

org.jboss.resteasy.spi.UnsupportedMediaTypeException

javax.ws.rs.NotSupportedException

InjectorFactory および Registry

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

5.4.5. Jackson プロバイダーの変更

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 ApplicationsSwitching the Default Jackson Provider を参照してください。

5.4.6. Spring RESTEasy 統合の変更

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

5.4.7. RESTEasy Jettison JSON プロバイダーの変更

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 Development GuideAdd an Explicit Module Dependency to a Deployment を参照してください。

5.5. CDI 1.2 アプリケーションの変更

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 platformType and Bean Discovery を参照してください。

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

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

  • bean-discovery-modenone である beans.xml ファイルが含まれる場合。
  • beans.xml ファイルがない CDI 拡張が含まれる場合。

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

  • バージョン番号が 1.1 以上で、bean-discovery-modeallbeans.xml ファイルがアーカイブに含まれる場合。
  • アーカイブにバージョン番号のない beans.xml ファイルが含まれる場合。
  • アーカイブに空の beans.xml ファイルが含まれる場合。

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

  • アーカイブに beans.xml ファイルが含まれなくても、bean を定義するアノテーションを持つ bean クラスが 1 つ以上含まれるか、セッション bean が 1 つ以上含まれる場合。
  • アーカイブに bean-discovery-modeannotated beans.xml ファイルが含まれる場合。

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

  • @ApplicationScoped@SessionScoped@ConversationScoped、および @RequestScoped アノテーション
  • その他すべての通常スコープタイプ
  • @Interceptor および @Decorator アノテーション
  • @Stereotype アノテーションが付けられた stereotype アノテーションすべて
  • @Dependent スコープアノテーション

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

会話解決の明確化

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

オブザーバー解決

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

5.6. 明示的なモジュール依存関係の移行

前リリースの 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 デプロイメント記述子ファイルに追加する必要があります。

MANIFEST.MF ファイルのアノテーションフラグの例

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

jboss-deployment-structure.xml ファイルのアノテーションフラグの例

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

5.7. Hibernate および JPA の移行の変更

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 クラスを除外する必要があります。

5.8. Hibernate Search の変更

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)
番号および日付のインデックス形式の変更

番号や日付はデフォルトで数字フィールドとしてインデックス化されるようになりました。タイプ intlongfloatdouble のプロパティーおよびこれらのラッパークラスは文字列としてインデックス化されないようになりました。代わりに、これらは 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 の変更

  • ソートオプションが改良され、ソートオプションに対してフィールドエンコーディングが誤って指定されるとランタイム例外が発生するようになりました。また、あらかじめソートに使用されるフィールドが分かる場合、Lucene によってより高性能なソート機能が提供されます。Hibernate Search 5.5 は新しい @SortableField および @SortableFields アノテーションを提供します。詳細は、Migration Guide from Hibernate Search 5.4 to 5.5 を参照してください。
  • Lucene の SortField API には、以下のアプリケーションコードの変更を適用する必要があります。

    以前のリリースの JBoss EAP では、以下のようにクエリーでソートフィールドのタイプを設定しました。

    fulltextQuery.setSort(new Sort(new SortField("title", SortField.STRING)));

    JBoss EAP 7 での設定例は次のとおりです。

    fulltextQuery.setSort(new Sort(new SortField("title", SortField.Type.STRING)));
  • SearchFactory は ORM の統合でのみ使用される必要があるため、hibernate-search-engine モジュールから hibernate-search-orm モジュールに移動されました。他のインタグレーターは SearchIntegrator のみに依存する必要があります。SearchIntegrator は、非推奨となった SearchFactoryIntegrator の代わりに使用されます。
  • 列挙値 SpatialMode.GRID の名前が SpatialMode.HASH に変更になりました。
  • FullTextIndexEventListener が最終クラスになりました。現在このクラスを拡張する場合、同じ機能を実現できる他の方法を見つける必要があります。
  • hibernate-search-analyzers モジュールが削除されました。org.apache.lucene:lucene-analyzers-common などの適切な Lucene アーティファクトを直接使用する方法が推奨されます。
  • JMS コントロール API が変更になりました。他の ORM 環境で使用できるようにするため、Hibernate ORM の JMS バックエンド依存関係が削除されました。そのため、 org.hibernate.search.backend.impl.jms.AbstractJMSHibernateSearchController のインプリメンターを新しい署名に応じて調整する必要があります。このクラスは内部クラスで、拡張せずに例として使用することが推奨されます。
  • org.hibernate.search.spi.ServiceProvider SPI がリファクターされました。古いサービスコントラクトで統合している場合は、ServiceManagerServiceStartable、および StoppableHibernate Search 5.5 Javadoc で新しいコントラクトの詳細を確認してください。
  • Lucene 3.x によって生成されたインデックスを保持し、これらのインデックスを Hibernate Search 5.0 以上で再構築していない場合、IndexFormatTooOldException が発生します。マスインデクサーでインデックスを再構築することが推奨されます。再構築できない場合は、ILucene の IndexUpgrader を使用してください。デフォルトの動作が変更になった場合があるため、注意して Hibernate Search のマッピングを更新する必要があります。詳細は Apache Lucene Migration Guide を参照してください。
  • JBoss EAP 7 では、Apache Lucene が 3.6 から 5.3 にアップグレードされました。ご使用のコードが 直接 Lucene のコードをインポートする場合は、Apache Lucene Migration Guide で変更の詳細を確認してください。Lucene Change Log にも追加の情報が記載されています。
  • @Field(indexNullAs=) を使用してインデックスの null マーカー値をエンコードする場合、同じフィールドでインデックス化されるその他の値すべてに適合するマーカーのタイプである必要があります。たとえば、これまでは文字列「null」を使用して数字フィールドの null 値 をエンコードすることが可能でしたが、本リリースではこれができないようになりました。この代わりに、-1 などの null 値を表す数字を選択する必要があります。
  • ファセッティングエンジンに大幅な改良が加えられました。ほとんどの変更は API には影響しませんが、ファセッティングに使用する予定のフィールドすべてに @Facet または @Facets アノテーションを付ける必要があります。

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

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

以前のパッケージおよびクラス新しいパッケージおよびクラス

org.hibernate.search.Environment

org.hibernate.search.cfg.Environment

org.hibernate.search.FullTextFilter

org.hibernate.search.filter.FullTextFilter

org.hibernate.search.ProjectionConstants

org.hibernate.search.engine.ProjectionConstants

org.hibernate.search.SearchException

org.hibernate.search.exception.SearchException

org.hibernate.search.Version

org.hibernate.search.engine.Version

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

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

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

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

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

Hibernate Search で非推奨となった API

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

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

org.hibernate.search.store.IndexShardingStrategy

Hibernate Search 4.4 で非推奨となりました。Hibernate Search 5 で削除される可能性があります。代わりに ShardIdentifierProvider を使用してください。

org.hibernate.search.store.Workspace

このインターフェースは削除され、非公開 API [HSEARCH-1915] として考慮される必要があります。

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

org.hibernate.search.filter.FilterKey

カスタムフィルターキーは非推奨となり、Hibernate Search 6 で削除される予定です。Hibernate Search 5.1 では、Lucene フィルターをキャッシュするキーは指定のフィルターパラメーターを基に自動的に算出されます。

org.hibernate.search.filter.StandardFilterKey

カスタムフィルターキーは非推奨となり、Hibernate Search 6 で削除される予定です。Hibernate Search 5.1 では、Lucene フィルターをキャッシュするキーは指定のフィルターパラメーターを基に自動的に算出されます。

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

org.hibernate.search.annotations.FieldCacheType

非推奨となったため CacheFromIndex アノテーションを削除します。Hibernate Search Deprecated Annotations を参照してください。

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

org.hibernate.search.annotations.CacheFromIndex

アノテーションを削除してください。代替は必要ありません。

org.hibernate.search.annotations.Key

カスタムフィルターキャッシュキーは非推奨機能となり、Hibernate Search 6 で削除される予定です。Hibernate Search 5.1 では、フィルターキャッシュキーはフィルターパラメーターを基に自動的に判断されるため、キーオブジェクトを提供する必要がなくなりました。

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

org.hibernate.search.FullTextSharedSessionBuilder.autoClose()

代替はありません。

org.hibernate.search.FullTextSharedSessionBuilder.autoClose(boolean)

代替はありません。

org.hibernate.search.cfg.IndexedMapping.cacheFromIndex(FieldCacheType…​)

今後削除される予定で、代替はありません。

org.hibernate.search.cfg.EntityDescriptor.getCacheInMemory()

今後削除される予定で、代替はありません。

org.hibernate.search.cfg.ContainedInMapping.numericField()

代わりに、field().numericField() を呼び出します。

org.hibernate.search.cfg.EntityDescriptor.setCacheInMemory(Map<String, Object>)

今後削除される予定で、代替はありません。

org.hibernate.search.MassIndexer.threadsForSubsequentFetching(int)

このメソッドは削除される予定です。

org.hibernate.search.query.dsl.FuzzyContext.withThreshold(float)

FuzzyContext.withEditDistanceUpTo(int) を使用します。

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

org.hibernate.search.cfg.NumericFieldMapping(PropertyDescriptor, EntityDescriptor, SearchMapping)

代わりに NumericFieldMapping.NumericFieldMapping(String, PropertyDescriptor, EntityDescriptor, SearchMapping) を使用します。

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

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

5.9. エンティティー Bean の JPA への移行

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 に同梱される bmtcmt、および hibernate5 クイックスタートを参照してください。

5.10. JPA 永続プロパティーの変更

これまでの 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.xmljboss.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 での動作と同じであるため、アプリケーションの移行時に変更を加える必要はありません。

5.11. EJB クライアントコードの移行

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

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

5.11.1. デフォルトのリモート接続ポートの更新

jboss-ejb-client.properties ファイルのリモート接続ポートの値を 4447 から 8080 に変更します。

以下は、前リリースと本リリースの jboss-ejb-client.properties ファイルの例になります。

例: JBoss EAP 6 の jboss-ejb-client.properties ファイル

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

例: JBoss EAP 7 の jboss-ejb-client.properties ファイル

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

5.11.2. デフォルトコネクターの更新

新しい JBoss EAP 7 設定で実行している場合、デフォルトのコネクターは remote から http-remoting に変更になりました。この変更は、使用するライブラリーと接続するサーバーの JBoss EAP リリースが異なるクライアントに影響します。

  • クライアントアプリケーションが JBoss EAP 6 の EJB クライアントライブラリーを使用し、JBoss EAP 7 サーバーへ接続する場合、8080 以外のポートで remote コネクターを公開するようサーバーを設定する必要があります。
  • JBoss EAP 7 の EJB クライアントライブラリーを使用し、JBoss EAP 6 サーバーへ接続するクライアントアプリケーションは、サーバーインスタンスによって http-remoting コネクターは使用されず、remote コネクターが使用されることを認識する必要があります。これは、新しいクライアント側接続プロパティーを定義することで実現されます。

    remote.connection.default.protocol=remote

5.11.3. リモートネーミングクライアントコードの移行

新しいデフォルトの 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.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=http-remoting://localhost:8080

5.12. デプロイメント計画設定の移行

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 を参照してください。

5.13. カスタムアプリケーションバルブの移行

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

重要

jboss-web.xml ファイルに定義されたカスタムバルブおよびバルブは、対応する Undertow のビルトインハンドラーで書き直すか、置き換える必要があります。Undertow ハンドラーへのバルブのマッピングに関する詳細はJBoss Web バルブの移行 を参照してください。

認証バルブは、Undertow ビルトイン認証メカニズムを使用して手動で置き換える必要があります。

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

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 GuideCreating Custom Handlers を参照してください。

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

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

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

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

5.14.1. オーセンティケーターバルブの移行

オーセンティケーターバルブは、Undertow ビルトイン認証メカニズムを使用して手動で置き換える必要があります。オーセンティケーターバルブを移行する方法は、以下の項を参照してください。

5.14.3. その他のセキュリティーアプリケーションの変更

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

5.15. JBoss Logging の変更

アプリケーションが 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 の新しいプロジェクト依存関係を追加する必要があります。

注記

ロギングアノテーションのみが移動されました。 org.jboss.logging.BasicLogger および org.jboss.logging.Logger は、これまでどおり org.jboss.logging パッケージにあります。

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

表5.1 非推奨となったロギングアノテーションの代替

非推奨となったクラス代替クラス

org.jboss.logging.Cause

org.jboss.logging.annotations.Cause

org.jboss.logging.Field

org.jboss.logging.annotations.Field

org.jboss.logging.FormatWith

org.jboss.logging.annotations.FormatWith

org.jboss.logging.LoggingClass

org.jboss.logging.annotations.LoggingClass

org.jboss.logging.LogMessage

org.jboss.logging.annotations.LogMessage

org.jboss.logging.Message

org.jboss.logging.annotations.Message

org.jboss.logging.MessageBundle

org.jboss.logging.annotations.MessageBundle

org.jboss.logging.MessageLogger

org.jboss.logging.annotations.MessageLogger

org.jboss.logging.Param

org.jboss.logging.annotations.Param

org.jboss.logging.Property

org.jboss.logging.annotations.Property

5.16. JavaServer Faces (JSF) のコード変更

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 を参照してください。

5.17. モジュールクラスローティングの変更

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

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

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

  • モジュール依存関係のクラスを複製する resource-root を指定しないようにします。
  • imports および exports 要素の include および exclude サブ要素を使用して module.xml ファイルでクラスローディングを制御できます。以下は、指定されたパッケージでクラスを除外する export 要素になります。

    <exports>
      <exclude path="com/mycompany/duplicateclassespath/"/>
    </exports>

既存の動作を保持するには、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 GuideClass Loading and Modules を参照してください。

5.18. アプリケーションクラスタリングの変更

5.18.1. 新しいクラスタリング機能の概要

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

  • JBoss EAP 7 には、シングルトンサービスのビルドを大幅に簡易化する、新しいパブリック API が導入されました。詳細は JBoss EAP Developing EJB ApplicationsImplement an HA Singleton を参照してください。
  • 一度にクラスターで単一のノードのみをデプロイおよび開始するよう、シングルトンデプロイメントを設定できます。詳細は、JBoss EAP Development GuideHA Singleton Deployments を参照してください。
  • クラスター化されたシングルトン MDB を定義できるようになりました。詳細は、JBoss EAP Developing EJB ApplicationsClustered Singleton MDBs を参照してください。
  • JBoss EAP 7 には、Undertow mod_cluster 実装が含まれています。これは、http web サーバーを必要としない純粋な Java ロードバランシングソリューションを提供します。詳細は、JBoss EAP Configuration GuideConfiguring JBoss EAP as a Front-end Load Balancer を参照してください。

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

5.18.2. Web セッションクラスタリングの変更

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

新しい Web セッションクラスタリング実装は、JBoss プロプライエタリー 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 ファイルの廃止された要素と同様の動作を実現する方法を説明しています。

設定要素変更の説明

<max-active-sessions/>

これまでの実装では、アクティブなセッションの数が <max-active-sessions/> によって指定された値を超えるとセッションの作成に失敗しました。

新しい実装では、<max-active-sessions/> を使用してセッションパッシベーションが有効化されます。セッションの作成によって、アクティブなセッションの数が <max-active-sessions/> を超える場合、新しいセッションが作成されるよう、セッションマネージャーが認識する最も古いセッションがパッシベートされます。

<passivation-config/>

この設定要素とサブ要素は JBoss EAP 7 では使用されないようになりました。

<use-session-passivation/>

以前の実装では、この属性を使用してパッシベーションが有効化されました。

新しい実装では、<max-active-sessions/> に負でない値を指定するとパッシベーションが有効化されます。

<passivation-min-idle-time/>

以前の実装では、パッシベーションの候補となる前にセッションは最小時間アクティブである必要がありました。そのため、パッシベーションが有効であってもセッションの作成に失敗することがありました。

新しい実装はこの論理をサポートしないため、サービス拒否 (DoS) 攻撃の発生を防ぎます。

<passivation-max-idle-time/>

以前の実装では、セッションは指定期間アイドル状態であった後にパッシベートされました。

新しい実装はレイジー (Lazy) パッシベーションのみをサポートします。イーガー (Eager) パッシベーションはサポートしません。セッションは、<max-active-sessions/> に準拠する必要があるときのみパッシベートされます。

<replication-config/>

新しい実装では複数のサブ要素が非推奨になりました。

<replication-trigger/>

以前の実装では、この要素を使用してセッションレプリケーションがトリガーされるタイミングを決定しました。新しい実装では、この設定は単一の堅牢なストラテジーに変更されました。詳細は、JBoss EAP Development GuideImmutable Session Attributes を参照してください。

<use-jk/>

以前の実装では、<use-jk/> に指定された値に応じて、指定のリクエストを処理するノードの instance-idjsessionid の末尾に追加され、mod_jk、mod_proxy_balancer、mod_cluster などのロードバランサーによって使用されました。

新しい実装では、instance-id が定義されている場合は常に jsessionid の末尾に追加されるようになりました。

<max-unreplicated-interval/>

以前の実装では、この設定オプションは変更されたセッション属性がない場合にセッションのタイムスタンプがレプリケートされないようにする最適化を目的としていました。しかし、セッション属性が変更されたかどうかに関係なく、セッションのアクセスにはキャッシュトランザクション RPC が必要であるため、実際は RPC の実行を防ぐことはできません。

新しい実装では、リクエストごとにセッションのタイムスタンプがレプリケートされるようになりました。これにより、フェイルオーバーの後にセッションメタデータが陳腐化されないようにします。

<snapshot-mode/>

これまでの実装では、<snapshot-mode/>INSTANT または INTERVAL として設定することができました。Infinispan のレプリケーションキューはこの設定オプションを廃止としてレンダーします。

<snapshot-interval/>

これは <snapshot-mode>INTERVAL</snapshot-mode> にのみ関係しました。<snapshot-mode/> は廃止されたため、このオプションも廃止されました。

<session-notification-policy/>

以前の実装では、この属性によって指定された値はセッションイベントをトリガーするポリシーを定義しました。

新しい実装ではこの動作は仕様に応じて判断されるようになり、設定不可能になりました。

5.18.3. ステートフルセッション EJB クラスタリングの変更

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

  • セッション Bean に org.jboss.ejb3.annotation.Clustered アノテーションを追加。

    @Stateful
    @Clustered
    public class MyBean implements MySessionInt {
    
       public void myMethod() {
          //
       }
    }
  • <clustered> 要素を jboss-ejb3.xml ファイルに追加。

    <c:clustering>
      <ejb-name>DDBasedClusteredSFSB</ejb-name>
      <c:clustered>true</c:clustered>
    </c:clustering>

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

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

  • EJB 3.2 仕様に新たに導入された @Stateful(passivationCapable=false) を使用して単一のステートフルセッション Bean のデフォルト動作を無効化します。
  • サーバー設定の ejb3 サブシステムの設定で、この動作をグローバルに無効化します。
注記

@Clustered アノテーションがアプリケーションから削除されると、このアノテーションは無視され、アプリケーションのデプロイメントには影響しません。

5.18.4. クラスタリングサービスの変更

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

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

  • 新しい org.wildfly.clustering.group.Group インターフェースを使用すると、現在のクラスター状態へアクセスでき、クラスターメンバーシップの変更をリッスンできます。
  • 新しい org.wildfly.clustering.dispatcher.CommandDispatcher インターフェースを使用すると、すべてのノードまたはノードの選択されたサブセットのクラスターでコードを実行できます。

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

詳細は、JBoss EAP Development GuidePublic API for Clustering Services を参照してください。

5.18.5. クラスタリング HA シングルトンの移行

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

HA シングルトンの実装方法に関する詳細は、JBoss EAP Developing EJB ApplicationsImplement an HA Singleton を参照してください。


このページには機械翻訳が使用されている場合があります (詳細はこちら)。