第5章 アプリケーション移行の変更
5.1. Web サービスアプリケーションの変更
主に Apache CXF、Apache 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 |
Boolean |
チャンキングを使用してリクエストを送信するかどうかを指定します。 |
cxf.client.chunkingThreshold |
Integer |
非チャンキングからチャンキングモードに切り替えるしきい値を設定します。 |
cxf.client.connectionTimeout |
Long |
接続タイムアウトをミリ秒単位で設定します。 |
cxf.client.receiveTimeout |
Long |
受信タイムアウトをミリ秒単位で設定します。 |
cxf.client.connection |
String |
|
cxf.tls-client.disableCNCheck |
Boolean |
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 サービス参照にインジェクトされるクライアントを構築する必要があります。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)
5.1.8. IgnoreHttpsHost CN チェックの変更
以前のリリースでは、システムプロパティー org.jboss.security.ignoreHttpsHost
を true
に設定すると、証明書にあるサービスの一般名 (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 リモーティングコネクターおよび 4447
ポート設定が保持されるため、リモートコネクター、リモートポート、または JNDI プロバイダー URL を変更する必要がありません。migrate
操作の詳細は、「管理 CLI の移行操作」を参照してください。
migrate
操作を使用せずに、新しい JBoss EAP 7 のデフォルト設定を使用して実行する場合は、新しい設定を使用するようにリモートコネクター、リモートポート、および JNDI プロバイダー URL を変更する必要があります。
5.3. メッセージングアプリケーションの変更
5.3.1. JMS デプロイメント記述子の置き換えおよび更新
ネーミングパターン -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
スキーマを使用するようデプロイメント記述子を更新してください。
記述子の更新を選択した場合、以下の変更を加える必要があります。
- ネームスペースを "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 6 は、JAX-RS 1.x の実装であった RESTEasy 2 をバンドルしました。
JBoss EAP 7.0 には、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 6 に含まれていた 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 3.x では、以下のインターセプターインターフェースが非推奨になりました。
-
org.jboss.resteasy.spi.interception.PreProcessInterceptor
インターフェースは RESTEasy 3.x のjavax.ws.rs.container.ContainerRequestFilter
インターフェースに置き換えられました。 RESTEasy 3.x では、以下のインターフェースとクラスも非推奨になりました。
-
org.jboss.resteasy.spi.interception.MessageBodyReaderInterceptor
-
org.jboss.resteasy.spi.interception.MessageBodyWriterInterceptor
-
org.jboss.resteasy.spi.interception.MessageBodyWriterContext
-
org.jboss.resteasy.spi.interception.MessageBodyReaderContext
-
org.jboss.resteasy.core.interception.InterceptorRegistry
-
org.jboss.resteasy.core.interception.InterceptorRegistryListener
-
org.jboss.resteasy.core.interception.ClientExecutionContextImpl
-
-
The
org.jboss.resteasy.spi.interception.MessageBodyWriterInterceptor
インターフェースはjavax.ws.rs.ext.WriterInterceptor
インターフェースに置き換えられました。 さらに、
javax.ws.rs.ext.MessageBodyWriter
インターフェースの変更の一部は JAX-RS 1.x の後方互換性を維持しない可能性があります。アプリケーションが JAX-RS 1.x を使用した場合はアプリケーションコードを確認し、エンドポイントに@Produces
または@Consumes
を定義するようにしてください。この定義を怠ると、以下のようなエラーが発生することがあります。org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: <OBJECT> of media type:
以下に、このエラーの原因となる REST エンドポイントの例を示します。
@Path("dates") public class DateService { @GET @Path("daysuntil/{targetdate}") public long showDaysUntil(@PathParam("targetdate") String targetDate) { DateLogger.LOGGER.logDaysUntilRequest(targetDate); final long days; try { final LocalDate date = LocalDate.parse(targetDate, DateTimeFormatter.ISO_DATE); days = ChronoUnit.DAYS.between(LocalDate.now(), date); } catch (DateTimeParseException ex) { // ** DISCLAIMER **. This example is contrived. throw new WebApplicationException(Response.status(400).entity(ex.getLocalizedMessage()).type(MediaType.TEXT_PLAIN) .build()); } return days; } }
この問題を修正するには、次のように
javax.ws.rs.Produces
のインポートと@Produces
アノテーションを追加します。... import javax.ws.rs.Produces; ... @Path("dates") public class DateService { @GET @Path("daysuntil/{targetdate}") @Produces(MediaType.TEXT_PLAIN) public long showDaysUntil(@PathParam("targetdate") String targetDate) { DateLogger.LOGGER.logDaysUntilRequest(targetDate); final long days; try { final LocalDate date = LocalDate.parse(targetDate, DateTimeFormatter.ISO_DATE); days = ChronoUnit.DAYS.between(LocalDate.now(), date); } catch (DateTimeParseException ex) { // ** DISCLAIMER **. This example is contrived. throw new WebApplicationException(Response.status(400).entity(ex.getLocalizedMessage()).type(MediaType.TEXT_PLAIN) .build()); } return days; } }
RESTEasy の以前のリリースからのインターセプターはすべて、新規の JAX-RS 2.0 フィルターおよびインターセプターインターフェースと並行して実行することが可能です。
インターセプターについての詳細情報は、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 クラスおよびメソッドの中には非推奨となっているものもあります。
以下のクラスは非推奨になりました。
-
org.jboss.resteasy.client.ClientResponseFailure
例外、org.jboss.resteasy.client.ClientExecutor
インターフェースおよびorg.jboss.resteasy.client.EntityTypeFactory
インターフェースも非推奨になりました。 org.jboss.resteasy.client.ClientRequest
およびorg.jboss.resteasy.client.ClientResponse
クラスを、それぞれorg.jboss.resteasy.client.jaxrs.ResteasyClient
およびjavax.ws.rs.core.Response
に置き換える必要があります。以下は RESTEasy 2.3.x の RESTEasy クライアントでリンクヘッダーを送信する例です。
ClientRequest request = new ClientRequest(generateURL("/linkheader/str")); request.addLink("previous chapter", "previous", "http://example.com/TheBook/chapter2", null); ClientResponse response = request.post(); LinkHeader header = response.getLinkHeader();
以下は RESTEasy 3 の RESTEasy クライアントで上記と同じタスクを実行する例です。
ResteasyClient client = new ResteasyClientBuilder().build(); Response response = client.target(generateURL("/linkheader/str")).request() .header("Link", "<http://example.com/TheBook/chapter2>; rel=\"previous\"; title=\"previous chapter\"").post(Entity.text(new String())); javax.ws.rs.core.Link link = response.getLink("previous");
JAX-RS Web サービスと対話する外部 JAX-RS RESTEasy クライアントの例は、
resteasy-jaxrs-client
クイックスタートを参照してください。-
org.jboss.resteasy.client.cache
パッケージのクラスおよびインターフェースも非推奨になりました。これらのクラスとインターフェースは、org.jboss.resteasy.client.jaxrs.cache
パッケージの同等のクラスおよびインターフェースに置き換えられました。
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-crypto
のSignedInput
およびSignedOutput
では、Content-Type
をRequest
またはResponse
オブジェクトのいずれかでmultipart/signed
に設定する必要があります。そうでない場合は、@Consumes
または@Produces
アノテーションを使用する必要があります。 -
SignedOutput
およびSignedInput
を使用すると、@Produces
または@Consumes
アノテーションでapplication/pkcs7-signature
MIME タイプを設定して、そのタイプの形式をバイナリ形式で返すことができます。 -
@Produces
または@Consumes
がtext/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 リリースで削除される可能性があります。非同期 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(); } }
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 Applications』の「Switching 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『開発ガイド』の「デプロイメントへの明示的なモジュール依存関係の追加」を参照してください。
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 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-discovery-mode
がnone
であるbeans.xml
ファイルが含まれる場合。 -
beans.xml
ファイルがない CDI 拡張が含まれる場合。
以下の場合、アーカイブは 明示的 bean アーカイブになります。
-
バージョン番号が 1.1 以上で、
bean-discovery-mode
がall
のbeans.xml
ファイルがアーカイブに含まれる場合。 -
アーカイブにバージョン番号のない
beans.xml
ファイルが含まれる場合。 -
アーカイブに空の
beans.xml
ファイルが含まれる場合。
以下の場合、アーカイブは 暗黙的 bean アーカイブになります。
-
アーカイブに
beans.xml
ファイルが含まれなくても、bean を定義するアノテーションを持つ bean クラスが 1 つ以上含まれるか、セッション bean が 1 つ以上含まれる場合。 -
アーカイブに
bean-discovery-mode
がannotated
beans.xml
ファイルが含まれる場合。
CDI 1.2 は bean を定義するアノテーション を以下に限定します。
-
@ApplicationScoped
、@SessionScoped
、@ConversationScoped
、および@RequestScoped
アノテーション - その他すべての通常スコープタイプ
-
@Interceptor
および@Decorator
アノテーション -
@Stereotype
アノテーションが付けられた stereotype アノテーションすべて -
@Dependent
スコープアノテーション
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 では、オブザーバーメソッドにイベント修飾子がないかイベント修飾子のサブセットがある場合にイベントがオブザーバーメソッドに配信されます。
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 の移行の変更
5.7.1. Hibernate ORM 3.0
以前のリリースの 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 のクラスを除外する必要があります。
5.7.2. Hibernate ORM 4.0 - 4.3
アプリケーションが有効な 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 への移行」を参照してください。
5.7.3. Hibernate ORM 5 への移行
ここでは、Hibernate ORM をバージョン 4.3 からバージョン 5 に移行する際に必要な変更について説明します。Hibernate ORM 4 から Hibernate ORM 5 の間に実装された変更については、『Hibernate ORM 5.0 Migration Guide』を参照してください。
削除および非推奨となったクラス
以下のクラスは非推奨となり、Hibernate ORM 5 から削除されました。
クラスおよびパッケージのその他の変更
-
ブートストラップの再設計に合わせて、
org.hibernate.integrator.spi.Integrator
インターフェースが変更になりました。 -
新しいパッケージ
org.hibernate.engine.jdbc.env.spi
が作成されました。これには、org.hibernate.engine.jdbc.spi.JdbcServices
インターフェースから展開されたorg.hibernate.engine.jdbc.env.spi.JdbcEnvironment
インターフェースが含まれます。 -
org.hibernate.id.PersistentIdentifierGenerator
実装に影響する、新しいorg.hibernate.boot.model.relational.ExportableProducer
インターフェースが導入されました。 -
org.hibernate.id.Configurable
の署名が変更になり、org.hibernate.dialect.Dialect
のみでなくorg.hibernate.service.ServiceRegistry
を許可するようになりました。 -
org.hibernate.metamodel.spi.TypeContributor
インターフェースはorg.hibernate.boot.model.TypeContributor
に移行されました。 -
org.hibernate.metamodel.spi.TypeContributions
インターフェースはorg.hibernate.boot.model.TypeContributions
に移行されました。
タイプ処理
-
組み込みの
org.hibernate.type.descriptor.sql.SqlTypeDescriptor
実装は、org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry
で自動登録しないようになりました。 組み込みの実装を拡張し、その動作に依存するカスタムSqlTypeDescriptor
実装を使用するアプリケーションを更新し、SqlTypeDescriptorRegistry.addDescriptor()
を呼び出すようにする必要があります。 -
生成された UUID として定義された ID では、
BINARY(16)
を生成して適切に比較が行われるようにするため、一部のデータベースでは@Column(length=16)
を明示的に設定する必要があります。 -
javax.persistence.EnumType.STRING
name-mapping
を希望する、hbm.xml
に定義されたEnumType
マッピングでは、useNamed(true)
設定を使用するか、VARCHAR の値を12
に指定して、設定を明示的に示す必要があります。
トランザクション管理
-
Hibernate ORM 5 では、トランザクションSPI が大幅に再設計されました。Hibernate ORM 4.3 では、
org.hibernate.Transaction
API を使用して異なるバックエンドトランザクションストラテジーに直接アクセスしました。Hibernate ORM 5 には間接参照のレベルが導入されました。org.hibernate.Transaction
実装はバックエンドで、バックエンドストラテジーに応じて指定のセッションのトランザクションコンテキストを表すorg.hibernate.resource.transaction.TransactionCoordinator
と対話するようになりました。開発者への直接的な影響はありませんが、ブートストラップの設定に影響する可能性があります。これまで、アプリケーションは非推奨となったhibernate.transaction.factory_class
プロパティーを指定し、org.hibernate.engine.transaction.spi.TransactionFactory
FQN (完全修飾名) を参照しました。Hibernate ORM 5 では、hibernate.transaction.coordinator_class
設定を指定し、org.hibernate.resource.transaction.TransactionCoordinatorBuilder
を参照します。詳細は、「org.hibernate.cfg.AvailableSettings.TRANSACTION_COORDINATOR_STRATEGY
」を参照してください。 以下の短縮名が認識されるようになりました。
-
jdbc: JDBC
java.sql.Connection
を使用してトランザクションを管理します。これは、JPA 以外のトランザクションのデフォルトです。 jta: JTA を使用してトランザクションを管理します。
重要JPA アプリケーションが
hibernate.transaction.coordinator_class
プロパティーの設定を提供しない場合、Hibernate は永続化ユニットのトランザクションタイプを基にして自動的に適切なトランザクションコーディネーターを構築します。JPA でないアプリケーションが
hibernate.transaction.coordinator_class
プロパティーの設定を提供しない場合、Hibernate はデフォルトでjdbc
を使用してトランザクションを管理します。アプリケーションが実際に JTA ベースのトランザクションを使用する場合は、このデフォルトによって問題が発生します。JTA ベースのトランザクションを使用する JPA でないアプリケーションでは、hibernate.transaction.coordinator_class
プロパティーの値を明示的にjta
に設定するか、JTA ベースのトランザクションを適切に調整するorg.hibernate.resource.transaction.TransactionCoordinator
を構築するカスタムのorg.hibernate.resource.transaction.TransactionCoordinatorBuilder
を提供する必要があります。
-
jdbc: JDBC
Hibernate ORM 5 のその他の変更
-
cfg.xml
ファイルは完全に解析され、イベント、セキュリティー、およびその他の関数と統合されます。 -
EntityManagerFactory
を使用してcfg.xml
からロードされたプロパティーは、これまで名前の前にhibernate
が付きませんでしたが、他と統一するためにhibernate
が付けられるようになりました。 - 設定がシリアライズ不可能になりました。
-
org.hibernate.dialect.Dialect.getQuerySequencesString()
メソッドがカタログ、スキーマ、およびインクリメントの値を取得するようになりました。 -
AuditConfiguration
はorg.hibernate.envers.boot.internal.EnversService
から削除されました。 -
AuditStrategy
メソッドが変更され、廃止されたAuditConfiguration
を削除し、新しいEnversService
を使用するようになりました。 -
org.hibernate.hql.spi
パッケージおよびサブパッケージの複数のクラスおよびインターフェースが新しいorg.hibernate.hql.spi.id
に移動されました。これにはMultiTableBulkIdStrategy
クラスが含まれ、さらにAbstractTableBasedBulkIdHandler
、TableBasedDeleteHandlerImpl
、およびTableBasedUpdateHandlerImpl
インターフェースとそれらのサブクラスが含まれます。 - プロパティーアクセスコントラクトが完全に再設計されました。
-
有効な
hibernate.cache.default_cache_concurrency_strategy
設定の値は、org.hibernate.cache.spi.access.AccessType
列挙定数ではなく、org.hibernate.cache.spi.access.AccessType.getExternalName()
メソッドを使用して定義されるようになりました。これにより、他の Hibernate 設定と統一されます。
5.7.4. Hibernate ORM 5.0 から Hibernate ORM 5.1 への移行
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 のスキーマ管理ツールは、主に以下の項目を中心に変更されています。
-
hbm2ddl.auto
と Hibernate の JPAschema-generation
サポートの処理を統合。 - NoSQL データストアの Java Persistance (JPA) サポートを提供する永続化エンジンである Hibernate OGM の置き換えを容易にするため、SPI から JDBC の懸念事項を削除。
移行時にスキーマ管理ツールの変更に注意する必要があるのは、以下のクラスを直接使用するアプリケーションのみです。
-
org.hibernate.tool.hbm2ddl.SchemaExport
-
org.hibernate.tool.hbm2ddl.SchemaUpdate
-
org.hibernate.tool.hbm2ddl.SchemaValidator
-
org.hibernate.tool.schema.spi.SchemaManagementTool
またはこの委譲
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
プロパティー設定を使用します。
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
アノテーション
@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
および @CalendarBridge
アノテーション
@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 がリファクターされました。古いサービスコントラクトで統合している場合は、ServiceManager
、Service
、Startable
、およびStoppable
の『Hibernate 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」を参照してください。
TokenizerFactory
や TokenFilterFactory
などの 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 で削除される可能性があります。代わりに |
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 |
非推奨となったため |
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() |
代わりに、 |
org.hibernate.search.cfg.EntityDescriptor.setCacheInMemory(Map<String, Object>) |
今後削除される予定で、代替はありません。 |
org.hibernate.search.MassIndexer.threadsForSubsequentFetching(int) |
このメソッドは削除される予定です。 |
org.hibernate.search.query.dsl.FuzzyContext.withThreshold(float) |
|
Hibernate Search で非推奨となったコンストラクター
コンストラクター | 説明 |
---|---|
org.hibernate.search.cfg.NumericFieldMapping(PropertyDescriptor, EntityDescriptor, SearchMapping) |
代わりに |
上級インテグレーターに影響する変更
ここでは、パブリック API の一部ではない変更について説明します。これらのアーティファクトは、Hibernate Search フレームワークを拡張するインテグレーターのみがアクセスできる必要があるため、通常の開発者には影響はないはずです。
-
IndexWriterSetting.MAX_THREAD_STATES
およびIndexWriterSetting.TERM_INDEX_INTERVAL
列挙定数は非推奨になりました。これらは設定から読み取るプロパティーに影響します。実際にこれらの列挙定数がないと、hibernate.search.Animals.2.indexwriter.term_index_interval = default
などの設定プロパティーが無視されます。これによる影響は、プロパティーが適用されないことのみです。 -
SearchFactoryIntegrator
インターフェースが非推奨になりました。SearchIntegrator
を使用するよう、即座にすべてのコードを移行する必要があります。 -
SearchFactoryBuilder
クラスが非推奨になりました。代わりにSearchIntegrationBuilder
を使用してください。 -
HSQuery.getExtendedSearchIntegrator()
メソッドが非推奨になりました。SearchIntegrator
を使用できる可能性がありますが、このメソッドを削除することが推奨されます。 -
DocumentBuilderIndexedEntity.getFieldCacheOption()
メソッドが非推奨になりました。代替メソッドはありません。 -
BuildContext.getIndexingStrategy()
メソッドが非推奨になりました。代わりにBuildContext.getIndexingMode()
を使用してください。 -
DirectoryHelper.getVerifiedIndexDir(String, Properties, boolean)
メソッドが非推奨になりました。代わりにDirectoryHelper.getVerifiedIndexPath(java.lang.String, java.util.Properties, boolean)
を使用してください。 以下は、名前変更または再パッケージされた Hibernate Search クラスのリストになります。
以前のパッケージおよびクラス 新しいパッケージおよびクラス org.hibernate.search.engine.impl.SearchMappingBuilder
org.hibernate.search.engine.spi.SearchMappingHelper
org.hibernate.search.indexes.impl.DirectoryBasedIndexManager
org.hibernate.search.indexes.spi.DirectoryBasedIndexManager
org.hibernate.search.spi.MassIndexerFactory
org.hibernate.search.batchindexing.spi.MassIndexerFactory
org.hibernate.search.spi.SearchFactoryBuilder
org.hibernate.search.spi.SearchIntegratorBuilder
org.hibernate.search.spi.SearchFactoryIntegrator
org.hibernate.search.spi.SearchIntegrator
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 に同梱される bmt
、cmt
、および 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.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 での動作と同じであるため、アプリケーションの移行時に変更を加える必要はありません。
5.10.1. JBoss EAP 7.1 での JPA 永続プロパティーの変更
JBoss EAP 7.0 では、同期されていない永続化コンテキストエラーチェックが以下の場合で厳格に行われませんでした。
-
同期された CMP (Container-Managed Persistence) コンテキストは、JTA トランザクションと関連付けられた同期されていない拡張された永続化コンテキストを使用することが可能でしたが、同期されていない永続化コンテキストが使用されないように、
IllegalStateException
を発生すべきでした。 - デプロイメント記述子に指定された同期されていない永続化コンテキストが同期された永続化コンテキストとして処理されました。
さらに、JBoss EAP 7.0 では @PersistenceContext
でヒントする PersistenceProperty
は誤って無視されました。
これらの問題は JBoss EAP 7.1 で修正されました。これらの更新によってアプリケーションの動作が不適切に変更されるため、後方互換性を提供して以前の動作を維持するために JBoss EAP 7.1 には 2 つの新しい永続化ユニットプロパティーが導入されました。
プロパティー | 説明 |
---|---|
|
このプロパティーはエラーのチェックを無効にします。JBoss EAP 7.0 で動作したアプリケーションが JBoss EAP 7.1 で動作しない場合に一時的な対応策としてのみ使用してください。このプロパティーは今後のリリースで非推奨となる可能性があるため、可能な限り早期にアプリケーションコードを修正することが推奨されます。 |
|
このプロパティーは |
5.11. EJB クライアントコードの移行
5.11.1. JBoss EAP 7 での EJB クライアントの変更
JBoss EAP 7 ではデフォルトのリモートコネクターおよびポートが変更になりました。この変更の詳細は「リモート URL コネクターおよびポートの更新」を参照してください。
migrate
操作を使用してサーバー設定を移行した場合は、旧設定は保持されるため以下の変更を行う必要はありません。しかし、新しい JBoss EAP 7 のデフォルト設定で実行する場合は以下の変更を行う必要があります。
5.11.1.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.1.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
接続プロパティーremote.connection.default.protocol=remote
5.11.2. リモートネーミングクライアントコードの移行
新しいデフォルトの 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
5.11.3. JBoss EAP 7.1 に導入された EJB Client のその他の変更
JBoss EAP 7.0 には JBoss EJB Client 2.1.4 が同梱されていましたが、JBoss EAP 7.1 には JBoss EJB Client 4.0.x が同梱され、API に複数の変更が追加されました。
以下の新しいメソッドに
org.ejb.client.EJBClientInvocationContext
クラスが追加されました。メソッド タイプ 説明 isBlockingCaller()
boolean
この呼び出しによって呼び出しているスレッドが現在ブロックされているかどうかを判断します。
isClientAsync()
boolean
メソッドがクライアント非同期 (client-asynchronus) としてマークされているかどうかを判断します。マークされていると、サーバー側のメソッドが非同期であるかどうかに関わらず、呼び出しは非同期になります。
isIdempotent()
boolean
メソッドが冪等 (idempotent) としてマークされているかどうかを判断します。マークされていると、メソッドは追加の効果なしで複数回呼び出されることがあります。
setBlockingCaller(boolean)
void
この呼び出しによって呼び出しているスレッドが現在ブロックされているかどうかを確定します。
setLocator(EJBLocator<T>)
<T> void
呼び出し先のロケーターを設定します。
org.ejb.client.EJBLocator
クラスは以下の新しいメソッドに追加されました。メソッド タイプ 説明 asStateful()
StatefulEJBLocator<T>
ある場合、このロケーターをステートフルロケーターとして返します。
asStateless()
StatelessEJBLocator<T>
ある場合、このロケーターをステートレスロケーターとして返します。
isEntity()
boolean
これがエンティティーロケーターであるかどうかを判断します。
isHome()
boolean
これがホームロケーターであるかどうかを判断します。
isStateful()
boolean
これがステートフルロケーターであるかどうかを判断します。
isStateless()
boolean
これがステートレスロケーターであるかどうかを判断します。
withNewAffinity(Affinity)
abstract EJBLocator<T>
このロケーターのコピーを新しいアフィニティーで作成します。
特権のある EJB 操作へのアクセスを制御するために、
java.security.Permission
のサブクラスである新しいorg.ejb.client.EJBClientPermission
クラスが導入されました。以下のコンストラクターを提供します。
-
EJBClientPermission(String name)
-
EJBClientPermission(String name, String actions)
-
以下のメソッドを提供します。
メソッド タイプ 説明 equals(EJBClientPermission obj)
boolean
2 つの
EJBClientPermission
オブジェクトが等値であるかをチェックします。equals(Object obj)
boolean
2 つの
Permission
オブジェクトが等値であるかをチェックします。equals(Permission obj)
boolean
2 つの
Permission
オブジェクトが等値であるかをチェックします。getActions()
String
アクションを文字列として返します。
hashcode()
int
この
Permission
オブジェクトのハッシュコード値を返します。implies(EJBClientPermission permission)
boolean
指定パーミッションのアクションが、この
EJBClientPermission
オブジェクトのアクションによって 暗示 されたかどうかをチェックします。implies(Permission permission)
boolean
指定パーミッションのアクションが、この
Permission
オブジェクトのアクションによって 暗示 されたかどうかをチェックします。
特定の EJB メソッドを見つけるために、新しい
org.ejb.client.EJBMethodLocator
クラスが導入されました。以下のコンストラクターを提供します。
-
EJBMethodLocator(String methodName, String… parameterTypeNames)
-
以下のメソッドを提供します。
メソッド タイプ 説明 equals(EJBMethodLocator other)
boolean
このオブジェクトが別のオブジェクトと等しいかどうかを判断します。
equals(Object other)
boolean
このオブジェクトが別のオブジェクトと等しいかどうかを判断します。
forMethod(Method method)
static EJBMethodLocator
指定のリフレクションメソッドのメソッドロケーターを取得します。
getMethodName()
String
メソッド名を取得します。
getParameterCount()
int
パラメーターの数を取得します。
getParameterTypeName(int index)
String
指定インデックスのパラメーターの名前を取得します。
hashCode()
int
ハッシュコードを取得します。
失敗したケースに対して、
org.jboss.ejb.client.EJBReceiverInvocationContext.ResultProducer.Failed
クラスが新たに導入されました。以下のコンストラクターを提供します。
-
Failed(Exception cause)
-
以下のメソッドを提供します。
メソッド タイプ 説明 discardResult()
void
結果を破棄し、使用されないことを示します。
getResult()
Object
結果を取得します。
即座に結果を得るために、
org.jboss.ejb.client.EJBReceiverInvocationContext.ResultProducer.Immediate
クラスが新たに導入されました。以下のコンストラクターを提供します。
-
Failed(Exception cause)
-
以下のメソッドを提供します。
メソッド タイプ 説明 discardResult()
void
結果を破棄し、使用されないことを示します。
getResult()
Object
結果を取得します。
URIアフィニティーを指定するために、
org.jboss.ejb.client.Affinity
のサブクラスであるorg.jboss.ejb.client.URIAffinity
クラスが新たに導入されました。-
これは、
Affinity.forUri(URI)
を使用して作成されます。 以下のメソッドを提供します。
メソッド タイプ 説明 equals(Affinity other)
boolean
別のオブジェクトがこのオブジェクトと等しいかどうかを示します。
equals(Object other)
boolean
別のオブジェクトがこのオブジェクトと等しいかどうかを示します。
equals(URIAffinity other)
boolean
別のオブジェクトがこのオブジェクトと等しいかどうかを示します。
getURI()
URI
関連する URI を取得します。
hashCode()
int
ハッシュコードを取得します。
toString()
String
オブジェクトの文字列表現を返します。
-
これは、
org.jboss.ejb.client.EJBMetaDataImpl
クラスによって以下のメソッドが非推奨になりました。-
toAbstractEJBMetaData()
-
EJBMetaDataImpl(AbstractEJBMetaData<?,?>)
-
5.12. WildFly 設定ファイルを使用するようクライアントを移行
EJB や naming などの JBoss EAP クライアントライブラリーは、リリース 7.1 まで異なる設定ストラテジーを使用していました。サーバー設定と似た方法で、すべてのクライアント設定を 1 つの設定ファイルに統合するため、JBoss EAP 7.1 には wildfly-config.xml
ファイルが導入されました。
たとえば JBoss EAP 7.1 以前では、Java EJB クライアントの新しい InitialContext
の作成には、jboss-ejb-client.properties
ファイルを使用するか、Properties
クラスを使用してプログラミングでプロパティーファイルを設定しました。
例: jboss-ejb-client.properties
プロパティーファイル
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false remote.connections=one remote.connection.one.port=8080 remote.connection.one.host=127.0.0.1 remote.connection.one.username=quickuser remote.connection.one.password=quick-123
JBoss EAP 7.1 では、クライアントアーカイブの META-INF/
ディレクトリーに wildfly-config.xml
ファイルを作成します。これは、wildfly-config.xml
ファイルを使用した設定と同等です。
例: wildfly-config.xml
ファイルを使用した同等の設定
<configuration> <authentication-client xmlns="urn:elytron:1.0.1"> <authentication-rules> <rule use-configuration="ejb"/> </authentication-rules> <authentication-configurations> <configuration name="ejb"> <set-user-name name="quickuser"/> <credentials> <clear-password password="quick-123"/> </credentials> </configuration> </authentication-configurations> </authentication-client> <jboss-ejb-client xmlns="urn:jboss:wildfly-client-ejb:3.0"> <connections> <connection uri="remote+http://127.0.0.1:8080" /> </connections> </jboss-ejb-client> </configuration>
wildfly-config.xml
ファイルを使用して Elytron クライアントに対してクライアント認証を設定する方法については、JBoss EAP『How to Configure Identity Management』の「Configure Client Authentication with Elytron Client」を参照してください。
wildfly-config.xml
ファイルを使用して実行できるクライアント設定の種類に関する詳細は、JBoss EAP『開発ガイド』の「wildfly-config.xml
ファイルを使用したクライアント設定」参照してください。
5.13. デプロイメント計画設定の移行
Java EE Application Deployment specification (JSR-88) は、複数のプロバイダーからのツールを有効にし、すべての Java EE プラットフォーム製品上にアプリケーションを設定およびデプロイするための標準のコントラクトを定義することが目的でした。このコントラクトでは、Tool Providers によってアクセスされる DeploymentManager
および他の javax.enterprise.deploy.spi
インターフェースを Java EE Product Providors が実装する必要がありました。JBoss EAP 6 の場合、ZIP または JAR アーカイブでバンドルされる deployment-plan.xml
という名前の XML 記述子によってデプロイメント計画が識別されます。
ほとんどのアプリケーションサーバー製品は、より機能が充実した独自のデプロイメントソリューションを提供するため、この仕様はほとんど採用されませんでした。そのため、JSR-88 のサポートは Java EE 7 で廃止されたため、JBoss EAP 7 でも廃止されました。
JSR-88 を使用してアプリケーションをデプロイした場合、別の方法でアプリケーションをデプロイする必要があります。JBoss EAP 管理 CLI の deploy
コマンドを使用すると、標準的な方法でアーカイブをスタンドアロンサーバーまたは管理対象ドメインのサーバーグループにデプロイできます。管理 CLI に関する詳細は、『Management CLI Guide』を参照してください。
5.14. カスタムアプリケーションバルブの移行
カスタムバルブまたは 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『開発ガイド』の「カスタムハンドラーの作成」を参照してください。
カスタムオーセンティケーターバルブの移行
オーセンティケーターバルブを移行する方法については、「オーセンティケーターバルブの移行」を参照してください。
5.15. セキュリティーアプリケーションの変更
JBoss Web を Undertow で置き換えるには、JBoss EAP 7 のセキュリティー設定における変更が必要になります。
5.15.1. オーセンティケーターバルブの移行
JBoss EAP 6.4 で AuthenticatorBase
を拡張するカスタムオーセンティケーターバルブを作成した場合、JBoss EAP 7.1 では手作業でカスタム HTTP 認証実装に置き換える必要があります。HTTP 認証メカニズムは elytron
サブシステムで作成され、undertow
サブシステムで登録されます。カスタム HTTP 認証メカニズムの実装方法に関する詳細は、JBoss EAP 『開発ガイド』の「カスタム HTTP メカニズムの開発 」を参照してください。
5.15.2. PicketLink の変更
SSO の SAML v2 設定で必要となる変更についての情報は、JBoss EAP『How To Set Up SSO with SAML v2』の「Changes from Previous Versions of JBoss EAP」を参照してください。
5.15.3. その他のセキュリティーアプリケーションの変更
Kerberos による SSO 設定についての相違点については、JBoss EAP『How to Set Up SSO with Kerberos』の「Differences from Configuring Previous Versions JBoss EAP」を参照してください。
5.16. 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
パッケージにあります。
非推奨となったアノテーションクラスと代替クラスを以下の表に示します。
非推奨となったクラス | 代替クラス |
---|---|
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.17. 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 に対してコンパイルする必要があります。
例: JSF 2.1 API を使用する Java コード
Object obj = FacesContext.getCurrentInstance().getAttributes().get(FaceletContext.FACELET_CONTEXT_KEY);
詳細は「Prevent FaceletContext.FACELET_CONTEXT_KEY constant to be inlined by compiler」を参照してください。
5.18. モジュールクラスローティングの変更
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 つを使用して実現できます。
-
モジュール依存関係のクラスを複製する
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『開発ガイド』の「クラスローディングとモジュール」を参照してください。
5.19. アプリケーションクラスタリングの変更
5.19.1. 新しいクラスタリング機能の概要
以下のリストは、アプリケーションを JBoss EAP 6 から JBoss EAP 7 へ移行するときに注意する必要がある新しいクラスタリング機能の一部を示しています。
- JBoss EAP 7 には、シングルトンサービスのビルドを大幅に簡易化する、新しいパブリック API が導入されました。シングルトンサービスの詳細は JBoss EAP『開発ガイド』の「HA シングルトンサービス」を参照してください。
- 一度にクラスターで単一のノードのみをデプロイおよび開始するよう、シングルトンデプロイメントを設定できます。詳細は、JBoss EAP『開発ガイド』の「HA シングルトンデプロイメント」を参照してください。
- クラスター化されたシングルトン MDB を定義できるようになりました。詳細は、JBoss EAP『Developing EJB Applications 』で「Clustered Singleton MDBs」を参照してください。
- JBoss EAP 7 には、Undertow mod_cluster 実装が含まれています。これは、http web サーバーを必要としない純粋な Java ロードバランシングソリューションを提供します。詳細は、JBoss EAP 『設定ガイド』の「JBoss EAP をフロントエンドロードバランサーとして設定」を参照してください。
本セクションの残りの部分では、クラスタリングの変更がアプリケーションの JBoss EAP 7 への移行に及ぼす可能性のある影響について説明します。
5.19.2. Web セッションクラスタリングの変更
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
ファイルの廃止された要素と同様の動作を実現する方法を説明しています。
設定要素 | 変更の説明 |
---|---|
<max-active-sessions/> |
これまでの実装では、アクティブなセッションの数が
新しい実装では、 |
<passivation-config/> |
この設定要素とサブ要素は JBoss EAP 7 では使用されないようになりました。 |
<use-session-passivation/> |
以前の実装では、この属性を使用してパッシベーションが有効化されました。
新しい実装では、 |
<passivation-min-idle-time/> |
以前の実装では、パッシベーションの候補となる前にセッションは最小時間アクティブである必要がありました。そのため、パッシベーションが有効であってもセッションの作成に失敗することがありました。 新しい実装はこの論理をサポートしないため、サービス拒否 (DoS) 攻撃の発生を防ぎます。 |
<passivation-max-idle-time/> |
以前の実装では、セッションは指定期間アイドル状態であった後にパッシベートされました。
新しい実装はレイジー (Lazy) パッシベーションのみをサポートします。イーガー (Eager) パッシベーションはサポートしません。セッションは、 |
<replication-config/> |
新しい実装では複数のサブ要素が非推奨になりました。 |
<replication-trigger/> |
以前の実装では、この要素を使用してセッションレプリケーションがトリガーされるタイミングを決定しました。新しい実装では、この設定は単一の堅牢なストラテジーに変更されました。詳細は、JBoss EAP『開発ガイド』の「変更不能なセッション属性」を参照してください。 |
<use-jk/> |
以前の実装では、
新しい実装では、 |
<max-unreplicated-interval/> |
以前の実装では、この設定オプションは変更されたセッション属性がない場合にセッションのタイムスタンプがレプリケートされないようにする最適化を目的としていました。しかし、セッション属性が変更されたかどうかに関係なく、セッションのアクセスにはキャッシュトランザクション RPC が必要であるため、実際は RPC の実行を防ぐことはできません。 新しい実装では、リクエストごとにセッションのタイムスタンプがレプリケートされるようになりました。これにより、フェイルオーバーの後にセッションメタデータが陳腐化されないようにします。 |
<snapshot-mode/> |
これまでは、 |
<snapshot-interval/> |
これは |
<session-notification-policy/> |
以前の実装では、この属性によって指定された値はセッションイベントをトリガーするポリシーを定義しました。 新しい実装ではこの動作は仕様に応じて判断されるようになり、設定不可能になりました。 |
新しいこの実装は、ライトスルーキャッシュストアとパッシベーションのみのキャッシュストアもサポートします。通常、ライトスルーキャッシュストアはインバリデーションキャッシュとともに使用されます。JBoss EAP 6 の web セッションクラスタリング実装は、インバリデーションキャッシュの使用時に適切に動作しませんでした。
5.19.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.19.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 の GroupCommunicationService
、GroupMembershipNotifier
、および GroupRpcDispatcher
に代わるサービスです。これらの API は以前のリリースで利用できました。
詳細は、JBoss EAP『開発ガイド』の「クラスタリングサービスのパブリック API」を参照してください。
5.19.5. クラスタリング HA シングルトンの移行
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 シングルトンデプロイメント」を参照してください。