JBoss EAP 7 の web サーバーは、JBoss Web から Undertow に変更になりました。そのため、web サブシステム設定を新しい JBoss EAP 7 undertow サブシステム設定に移行する必要があります。

管理 CLI migrate 操作を使うと、 web サブシステムをサーバー設定ファイル内の undertow に移行することができます。ただし、この操作では JBoss Web サブシステムのすべての設定が移行できるわけではないことに注意してください。"migration-warning" エントリーが表示される場合は、追加の管理 CLI コマンドを実行して設定を Undertow に移行する必要があります。管理 CLI migrate 操作についての詳細情報は、管理 CLI の移行操作 を参照してください。

以下の例は、JBoss EAP 6 のデフォルトの web サブシステム設定を示しています。

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
    <virtual-server name="default-host" enable-welcome-root="true">
        <alias name="localhost"/>
        <alias name="example.com"/>
    </virtual-server>
</subsystem>

以下の例は、JBoss EAP 7 のデフォルトの undertow サブシステム設定を示しています。

<subsystem xmlns="urn:jboss:domain:undertow:3.1">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <filter-ref name="server-header"/>
            <filter-ref name="x-powered-by-header"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <filters>
        <response-header name="server-header" header-name="Server" header-value="JBoss-EAP/7"/>
        <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
    </filters>
</subsystem>

管理 CLI の migrate 操作はリライト条件を自動的に移行できません。"migration-warnings" として報告され、手作業で移行する必要があります。Undertow の述語属性およびハンドラーを使用すると (Undertow Predicates Attributes and Handlers を参照)、JBoss EAP 7 で同等の設定を作成できます。

以下の例は、rewrite 設定を含む JBoss EAP 6 の web サブシステム設定を示しています。

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default" native="false">
    <virtual-server name="default" enable-welcome-root="true">
        <alias name="localhost"/>
        <rewrite name="test" pattern="(.*)/toberewritten/(.*)" substitution="$1/rewritten/$2" flags="NC"/>
        <rewrite name="test2" pattern="(.*)" substitution="-" flags="F">
            <condition name="get" test="%{REQUEST_METHOD}" pattern="GET"/>
            <condition name="andCond" test="%{REQUEST_URI}" pattern=".*index.html" flags="NC"/>
        </rewrite>
    </virtual-server>
</subsystem>

管理 CLI の移行操作 にある手順にしたがってサーバーと管理 CLI を開始し、以下のコマンドを使用して web サブシステム設定ファイルを移行します。

/subsystem=web:migrate

上記の設定で migrate 操作を実行すると、以下の "migration-warnings" がレポートされます。

/subsystem=web:migrate
{
    "outcome" => "success",
    "result" => {"migration-warnings" => [
        "WFLYWEB0002: Could not migrate resource {
    \"pattern\" => \"(.*)\",
    \"substitution\" => \"-\",
    \"flags\" => \"F\",
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\")
    ]
}",
        "WFLYWEB0002: Could not migrate resource {
    \"test\" => \"%{REQUEST_METHOD}\",
    \"pattern\" => \"GET\",
    \"flags\" => undefined,
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\"),
        (\"condition\" => \"get\")
    ]
}",
        "WFLYWEB0002: Could not migrate resource {
    \"test\" => \"%{REQUEST_URI}\",
    \"pattern\" => \".*index.html\",
    \"flags\" => \"NC\",
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\"),
        (\"condition\" => \"andCond\")
    ]
}"
    ]}
}

サーバー設定ファイルを確認すると、undertow サブシステムが以下の設定になっています。

<subsystem xmlns="urn:jboss:domain:undertow:3.1">
     <buffer-cache name="default"/>
     <server name="default-server">
         <http-listener name="http" socket-binding="http"/>
         <host name="default-host" alias="localhost, example.com">
             <location name="/" handler="welcome-content"/>
         </host>
     </server>
     <servlet-container name="default">
         <jsp-config/>
     </servlet-container>
     <handlers>
         <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
     </handlers>
 </subsystem>

管理 CLI を使用してフィルターを作成し、undertow サブシステムのリライト設定を置き換えます。各コマンドで "{"outcome" ⇒ "success"}" が表示されるはずです。

# Create the filters
/subsystem=undertow/configuration=filter/expression-filter="test1":add(expression="path('(.*)/toberewritten/(.*)') -> rewrite('$1/rewritten/$2')")
/subsystem=undertow/configuration=filter/expression-filter="test2":add(expression="method('GET') and path('.*index.html') -> response-code(403)")

# Add the filters to the default server
/subsystem=undertow/server=default-server/host=default-host/filter-ref="test1":add
/subsystem=undertow/server=default-server/host=default-host/filter-ref="test2":add

更新されたサーバー設定ファイルを確認します。JBoss Web サブシステムは完全に移行され、undertow サブシステムに設定されます。

<subsystem xmlns="urn:jboss:domain:undertow:3.1">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="http" socket-binding="http"/>
        <host name="default-host" alias="localhost, example.com">
            <location name="/" handler="welcome-content"/>
            <filter-ref name="test1"/>
            <filter-ref name="test2"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <filters>
        <expression-filter name="test1" expression="path('(.*)/toberewritten/(.*)') -> rewrite('$1/rewritten/$2')"/>
        <expression-filter name="test2" expression="method('GET') and path('.*index.html') -> response-code(403)"/>
    </filters>
</subsystem>

管理 CLI を使用してフィルターとハンドラーを設定する方法については、JBoss EAP 7 Configuration Guide の Configuring the Web Server を参照してください。

以前のリリースの JBoss EAP ではバルブがサポートされました。バルブとは、リクエストの変更や追加処理を実行するために、サーブレットフィルターの前にアプリケーションのリクエスト処理パイプラインへ挿入されるカスタムクラスのことです。

この項では、グローバルバルブの移行方法について説明します。カスタムおよびオーセンティケーターバルブの移行については、本ガイドのカスタムアプリケーションバルブの移行を参照してください。

JBoss EAP 7 で JBoss Web の代わりに導入された Undertow はグローバルバルブをサポートしませんが、Undertow ハンドラーを使用すると同様の機能を実現できます。Undertow には共通の機能を提供する複数のビルトインハンドラーが含まれています。また、カスタムハンドラーを作成する機能も含まれ、カスタムバルブの機能を置き換えるために使用することができます。

アプリケーションがバルブを使用する場合、JBoss EAP 7 へ移行するときに適切な Undertow ハンドラーコードに置き換え、同様の機能を実現する必要があります。

ハンドラーを設定する方法については、JBoss EAP 7 Configuration Guide の Configuring Handlers を参照してください。

フィルターを設定する方法については、JBoss EAP 7 Configuration Guide の Configuring Filters を参照してください。

JBoss Web バルブの移行

以下の表では、JBoss EAP の前リリースで JBoss Web が提供していたバルブとそれに対応する Undertow ビルトインハンドラーを示しています。JBoss Web バルブは、org.apache.catalina.valves パッケージにあります。

管理 CLI の migrate 操作を使用すると、以下の基準を満たすグローバルバルブを自動的に移行できます。

管理 CLI の migrate 操作の詳細は、管理 CLI の移行操作 を参照してください。

JDBCAccessLogValve の手動移行の手順

org.apache.catalina.valves.JDBCAccessLogValve バルブはルールの例外で、io.undertow.server.handlers.JDBCLogHandler へ自動的に移行することができません。以下の手順に従って、次のバルブ例を移行します。

<valve name="jdbc" module="org.jboss.as.web" class-name="org.apache.catalina.valves.JDBCAccessLogValve">
    <param param-name="driverName" param-value="com.mysql.jdbc.Driver" />
    <param param-name="connectionName" param-value="root" />
    <param param-name="connectionPassword" param-value="password" />
    <param param-name="connectionURL" param-value="jdbc:mysql://localhost:3306/wildfly?zeroDateTimeBehavior=convertToNull" />
    <param param-name="format" param-value="combined" />
</valve>

JBoss EAP 6 のデフォルト設定では、JGroups はサーバー設定ファイルの <interfaces> セクションに定義された public インターフェースを使用しました。

専用のネットワークインターフェースを使用することが推奨されるため、JBoss EAP 7 では JGroups はサーバー設定ファイルの <interfaces> セクションに定義された新しい private インターフェースを使用するようになりました。

JGroups は JGroups チャネルで HA サービスのグループ通信サポートを提供します。JBoss EAP 7 では、サーバー設定ファイルの jgroups サブシステムに <channel> 要素が導入されました。管理 CLI を使用して JGroups チャネル設定を追加、削除、および変更できます。

JGroups の設定方法の詳細は、JBoss EAP Configuration Guide の Cluster Communication with JGroups を参照してください。

JBoss EAP 6 では、Web セッションレプリケーションおよび EJB レプリケーションのデフォルトのクラスター化キャッシュは ASYNC キャッシュでレプリケートされましたが、これが JBoss EAP 7 では変更になりました。レプリケートされたキャッシュはデフォルトでは設定されません。レプリケートされたキャッシュの追加方法とレプリケートされたキャッシュをデフォルトにする方法はについては、JBoss EAP Configuration Guide の Configure the Cache Mode を参照してください。

これは、新しい JBoss EAP 7 のデフォルト設定を使用する場合のみ影響します。JBoss EAP 6 から設定を移行する場合は、infinispan サブシステムの設定は保持されます。

ASYNC キャッシュストラテジーの動作が JBoss EAP 7 では変更になりました。

JBoss EAP 6 では、ASYNC キャッシュの読み取りにロックはありませんでした。ブロックは発生しませんでしたが、フェイルオーバーなどで陳腐データのダーティーリードが発生する傾向にありました。これは、リクエストの完了前に同じユーザーの次のリクエストを開始できたためです。これは、クラスタートポロジーの変更がセッションアフィニティーに影響し、容易にデータが陳腐化することがあるため、分散モードを使用するときは許可されません。

JBoss EAP 7 では、ASYNC キャッシュの読み取りにロックが必要になりました。レプリケーションが終了するまで同じユーザーの新しいリクエストをブロックするようになったため、ダーティーリードが発生しないようになりました。

EAP_HOME/modules/system/layers/base/ にあった org.jboss.as.messaging モジュール拡張は、 org.wildfly.extension.messaging-activemq 拡張モジュールに置き換えられました。

urn:jboss:domain:messaging:3.0 サブシステム設定ネームスペースは urn:jboss:domain:messaging-activemq:1.0 ネームスペースに置き換えられました。

管理モデル

ほとんどの場合で、要素名と属性名は以前のリリースとできる限り同じになるよう努力しています。以下の表は変更の一部を表しています。

新しい messaging-activemq サブシステム上で呼び出される管理操作は、/subsystem=messaging/hornetq-server= から /subsystem=messaging-activemq/server= に変更になりました。

migrate 操作を呼び出すと、既存の JBoss EAP 6 の messaging サブシステム設定を JBoss EAP 7 の messaging-activemq サブシステムに移行できます。

/subsystem=messaging:migrate

migrate 操作を実行する前に describe-migration 操作を呼び出して、既存の JBoss EAP 6 の messaging サブシステム設定から JBoss EAP 7 サーバーの messaging-activemq サブシステムへの移行を実行する管理操作のリストを確認するとよいでしょう。

/subsystem=messaging:describe-migration

migrate および describe-migration 操作は、自動的に移行されないリソースや属性の migration-warnings のリストも表示します。

Messaging サブシステムの移行および前方互換性

messaging サブシステムの describe-migration およびmigrate 操作は、追加の設定引数を提供します。メッセージングを設定してレガシー JBoss EAP 6 クライアントが JBoss EAP 7 サーバーに接続できるようにするには、以下のようにブール値の add-legacy-entries 引数を describe-migration または migrate 操作に追加します。

/subsystem=messaging:describe-migration(add-legacy-entries=true)
/subsystem=messaging:migrate(add-legacy-entries=true)

ブール値の引数 add-legacy-entries が true に設定されていると、messaging-activemq サブシステムが legacy-connection-factory リソースを作成し、legacy-entries を jms-queue および jms-topic リソースに追加します。

ブール値の引数 add-legacy-entries が false に設定されていると、messaging-activemq サブシステムにはレガシーリソースが作成されず、レガシー JMS クライアントは JBoss EAP 7 サーバーと通信できません。これがデフォルト値になります。

前方互換性および後方互換性に関する詳細は、JBoss EAP Configuring Messaging の Backward and Forward Compatibility を参照してください。

管理 CLI の migrate および describe-migration 操作の詳細は、管理 CLI の移行操作を参照してください。

Messaging サブシステムの XML 設定

新しい messaging-activemq サブシステムによって、他の JBoss EAP サブシステムとより一貫性のある XML スキームが提供されるようになり、XMLの設定は大幅に変更されました。

新しい messaging-activemq サブシステムに準拠するために JBoss EAP messaging サブシステムの XML 設定を変更しないでください。この代わりに、レガシーサブシステムの migrate 操作を呼び出してください。この操作は、実行の一部として新しい messaging-activemq の XML 設定を書き込みます。

messaging サブシステムのログメッセージに付けられる接頭辞が JBAS から WFLYMSGAMQ に変更になりました。JBoss EAP 7 で使用されるログメッセージの新しいプロジェクトコード接頭辞の完全リストは、JBoss EAP Development Guide の Project Codes Used in JBoss EAP を参照してください。

JMS サポートプロバイダーが HornetQ から ActiveMQ Artemis に変更になったため、JBoss EAP 7 ではメッセージングデータの形式と場所が変更になりました。

以下の 2 つの方法のいずれかを使用してデータを移行できます。

リリース間で行われたメッセージングデータフォルダー名の変更についての詳細は、メッセージングフォルダー名のマッピングを参照してください。

java -jar -mp MODULE_PATH org.hornetq.exporter  MESSAGING_BINDINGS_DIRECTORY MESSAGING_JOURNAL_DIRECTORY MESSAGING_PAGING_DIRECTORY MESSAGING_LARGE_MESSAGES_DIRECTORY > OUTPUT_DATA.xml

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.hornetq.exporter">
    <main-class name="org.hornetq.jms.persistence.impl.journal.XmlDataExporter"/>
    <properties>
        <property name="jboss.api" value="deprecated"/>
    </properties>
    <dependencies>
        <module name="org.hornetq"/>
    </dependencies>
</module>

/subsystem=messaging-activemq/server=default:import-journal(file=OUTPUT_DIRECTORY/OldMessagingData.xml)

JBoss EAP のこれまでのリリースでは、JMS 宛先キューは messaging サブシステムの <hornetq-server> 要素下にある <jms-destinations> 要素に設定されました。

<hornetq-server>
  ...
  <jms-destinations>
     <jms-queue name="testQueue">
        <entry name="queue/test"/>
         <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
  </jms-destinations>
  ...
</hornetq-server>

JBoss EAP 7 では、JMS 宛先キューは messaging-activemq サブシステムのデフォルトの <server> 要素に設定されます。

<server name="default">
  ...
  <jms-queue name="testQueue" entries="queue/test java:jboss/exported/jms/queue/test"/>
  ...
</server>

JBoss EAP 7 では、JMS メッセージングプロバイダーが HornetQ から ActiveMQ Artemis に変更されたため、メッセージングインターセプターが大幅に変更されました。

以前の JBoss EAP リリースに含まれていた HornetQ messaging サブシステムでは、HornetQ インターセプターを JAR に追加し、HornetQ module.xml ファイルを修正するというインストール方法が必要でした。

JBoss EAP 7 に含まれる messaging-activemq サブシステムは、module.xml ファイルの修正を必要としません。Apache ActiveMQ Artemis Interceptor インターフェースを実装するユーザーインターセプタークラスは、どのサーバーモジュールからでもロードすることが可能です。インターセプターのロード先となるモジュールは、サーバー設定ファイルの messaging-activemq サブシステムで指定します。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
  <server name="default">
    ...
    <incoming-interceptors>
      <class name="com.mycompany.incoming.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.incoming.myOtherInterceptor" module="com.othercompany" />
    </incoming-interceptors>
    <outgoing-interceptors>
      <class name="com.mycompany.outgoing.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.outgoing.myOtherInterceptor" module="com.othercompany" />
    </outgoing-interceptors>
  </server>
</subsystem>

JBoss EAP 6 では、Netty サーブレットトランスポートと動作するようサーブレットエンジンを設定することができました。JBoss EAP 7 では、ビルトインメッセージングプロバイダーが HornetQ から ActiveMQ Artemis に変更になったため、この設定は使用できなくなりました。新しいビルトインメッセージング HTTP コネクターおよび HTTP アクセプターを使用するよう、サーブレット設定を変更する必要があります。

以前のリリースの JBoss EAP でデータソースを設定した場合、ドライバー名に指定される値は JDBC ドライバー JAR に含まれる META-INF/services/java.sql.Driver ファイルにリストされたクラスの数によって決まりました。

単一クラスを含むドライバー

META-INF/services/java.sql.Driver ファイルで指定されたクラスが 1 つのみであった場合、ドライバー名は単に JDBC ドライバー JAR の名前でした。これは JBoss EAP 7 でも変更ありません。

複数クラスを含むドライバー

JBoss EAP 6 では、META-INF/services/java.sql.Driver ファイルに複数のクラスが記載されている場合、以下の形式で JAR 名にドライバークラスにするクラスの名前とメジャーおよびマイナーバージョンを追加してクラスを指定していました。

JAR_NAME + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION

JBoss EAP 7 ではこれが変更され、以下の形式でドライバー名を指定します。

JAR_NAME + "_" + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION

2 つのクラスが含まれるドライバーの例としては、MySQL 5.1.31 JDBC ドライバーが挙げられます。このドライバークラス名は com.mysql.jdbc.Driver となります。以下の 2 つの例では、JBoss EAP の以前のリリースと現行リリースにおけるドライバー名の指定方法の違いが示されています。

mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1

mysql-connector-java-5.1.31-bin.jar_com.mysql.jdbc.Driver_5_1

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

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

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

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

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

Apache CXF インターセプター

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

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

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

Apache CXF の機能

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

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

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

Apache CXF HTTP トランスポート

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

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

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

client.setChunkingThreshold(8192);
...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

クライアント API

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

StringConverter

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

ResteasyProviderFactory Add メソッド

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

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

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

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

SignedInput および SignedOuput

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

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

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

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

非同期 HTTP サポート

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

サーバー側のキャッシュ

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

SPI 例外

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

InjectorFactory および Registry

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

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

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

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

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

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

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

明示的な依存関係の定義方法については、JBoss EAP Development Guide の Add an Explicit Module Dependency to a Deployment を参照してください。

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

以下は、前リリースと本リリースの 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

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

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

新しいデフォルトの 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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