第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 つ以上含まれる
コンストラクターを使用するよう既存コードを更新し、JAX-WS 2.2 以上を実装する必要があります。
javax.xml.ws.Service
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 記述子ファイルの対応するデータが上書きされます。