第4章 サーバー設定の変更

ログメッセージには、メッセージを報告するサブシステムのプロジェクトコードが接頭辞として付けられます。JBoss EAP 7 では、すべてのログメッセージの接頭辞が変更になりました。

JBoss EAP 7 で使用されるログメッセージの新しいプロジェクトコード接頭辞の完全リストは、JBoss EAP『開発ガイド』の「JBoss EAP で使用されるプロジェクトコード」を参照してください。

JBoss EAP 7.0 のルートロガーには、すべてのドメインサーバープロファイルと standalone-full-ha プロファイル以外のデフォルトのスタンドアロンプロファイル用のコンソールログハンドラーが含まれていました。JBoss EAP 7.1 のルートロガーには、管理対象ドメインプロファイルのコンソールログハンドラーが含まれていません。ホストコントローラーとプロセスコントローラーはデフォルトでコンソールにログが記録されます。JBoss EAP 7.0 で提供された機能を実現するには、JBoss EAP 『設定ガイド』の「Console ログハンドラーの設定」を参照してください。

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:4.0">
    <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:4.0">
     <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:4.0">
    <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 『設定ガイド』の「Web サーバーの設定」を参照してください。

以前のリリースの JBoss EAP では、システムプロパティーを使用して JBoss Web のデフォルトの動作を変更することが可能でした。Undertow で同じ動作を設定する方法は、「JBoss Web システムプロパティー移行のリファレンス」を参照してください。

JBoss EAP 6.4 から JBoss EAP 7.1 に移行するときに、アクセスログに予期される "Referer" および "User-agent" 値が書き込まれないことに気付くかもしれません。これは、JBoss EAP 6.4 に含まれていた JBoss Web は access-log で %{headername}i パターンを使用して受信ヘッダーをログに記録したためです。

<access-log pattern="%h %l %u %t &quot;%T sec&quot; &quot;%r&quot; %s %b &quot;%{Referer}i&quot; &quot;%{User-agent}i&quot;"/>

JBoss EAP 7.1 では Undertow が使用されるようになったため、受信ヘッダーのパターンは %{i,headername} に変更になりました。

<access-log pattern="%h %l %u %t &quot;%T sec&quot; &quot;%r&quot; %s %b &quot;%{i,Referer}&quot; &quot;%{i,User-Agent}&quot;"/>

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

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

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

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

ハンドラーの設定方法に関する詳細は、JBoss EAP 7『設定ガイド』の「ハンドラーの設定」を参照してください。

フィルターの設定方法に関する詳細は、JBoss EAP 7『設定ガイド』の「フィルターの設定」を参照してください。

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>

RFC2109 や RFC2965 など、Set-Cookie HTTP 応答ヘッダー構文の以前の仕様では、クッキー値が引用符で囲まれている場合はクッキー値に空白やその他の区切り文字を使用することができました。JBoss EAP 6.4 の JBoss Web は以前の仕様に準拠し、区切り文字が含まれるクッキー値を自動的に引用符で囲みました。

Set-Cookie HTTP 応答ヘッダー構文の RFC6265 仕様には、Set-Cookie 応答ヘッダーのクッキー値は特定の文法制約に準拠しなければならないと記載されています。たとえば、US-ASCII 文字でなければならず、CTRL (コントロール)、空白、2 重引用符、コンマ、セミコロン、またはバックスラッシュ文字を含んではいけません。

JBoss EAP 7.0 の累積パッチ Red Hat JBoss Enterprise Application Platform 7.0 Update 08 以前では、Undertow はこれらの無効な文字を制限せず、除外された文字が含まれたクッキーを引用符で囲みません。この累積パッチまたはこれ以降の累積パッチを適用し、 io.undertow.cookie.DEFAULT_ENABLE_RFC6265_COOKIE_VALIDATION システムプロパティーを true に設定すると、RFC6265 に準拠するクッキーの検証を有効にすることができます。

JBoss EAP 7.1 では、Undertow はデフォルトで RFC6265 に準拠するクッキーの検証を有効にしません。除外された文字が含まれたクッキーを引用符で囲みます。JBoss EAP 7.1 では、io.undertow.cookie.DEFAULT_ENABLE_RFC6265_COOKIE_VALIDATION システムプロパティーを使用して RFC6265 に準拠するクッキーの検証を有効にすることはできません。代わりに、rfc6265-cookie-validation リスナー属性を true に設定して HTTP、HTTPS、または AJP リスナーの RFC6265 に準拠するクッキーの検証を有効にします。以下の例は、HTTP リスナーの RFC6265 に準拠するクッキーの検証を有効にします。

/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=rfc6265-cookie-validation,value=true)

JBoss Web が web サーバーとして含まれていた JBoss EAP 6.4 では、デフォルトで HTTP TRACE メソッド呼び出しが許可されていました。

JBoss EAP 7 で JBoss Web の代わりに web サーバーとして導入された Undertow は、デフォルトでは HTTP TRACE メソッド呼び出しを許可しません。この設定は、undertow サブシステムで http-listener 要素の disallowed-methods 属性を使用して設定されます。この設定を確認するには、以下の read-resource コマンドの出力を確認します。disallowed-methods 属性の値が ["TRACE"] であることに注目してください。

/subsystem=undertow/server=default-server/http-listener=default:read-resource
{
    "outcome" => "success",
    "result" => {
        "allow-encoded-slash" => false,
        "allow-equals-in-cookie-value" => false,
        "always-set-keep-alive" => true,
        "buffer-pipelined-data" => false,
        "buffer-pool" => "default",
        "certificate-forwarding" => false,
        "decode-url" => true,
        "disallowed-methods" => ["TRACE"],
         ...
    }
}

JBoss EAP 7 およびそれ以降のバージョンで HTTP TRACE メソッド呼び出しを有効にするには、以下のコマンドを実行して disallowed-methods 属性リストから "TRACE" エントリーを削除する必要があります。

/subsystem=undertow/server=default-server/http-listener=default:list-remove(name=disallowed-methods,value="TRACE")

read-resource コマンドを再度実行すると、TRACE メソッド呼び出しが許可されないメソッドのリストから削除されたことが確認できます。

/subsystem=undertow/server=default-server/http-listener=default:read-resource
{
    "outcome" => "success",
    "result" => {
        "allow-encoded-slash" => false,
        "allow-equals-in-cookie-value" => false,
        "always-set-keep-alive" => true,
        "buffer-pipelined-data" => false,
        "buffer-pool" => "default",
        "certificate-forwarding" => false,
        "decode-url" => true,
        "disallowed-methods" => [],
         ...
    }
}

HTTP メソッドのデフォルト動作に関する詳細は、JBoss EAP『設定ガイド』の「HTTP メソッドのデフォルトの動作」を参照してください。

In JBoss EAP 7.0, the root context of a web application was disabled by default in mod_cluster.

This is no longer the case in JBoss EAP 7.1. This can have unexpected consequences if you are expecting the root context to be disabled. For example, requests can be misrouted to undesired nodes or a private application that should not be exposed can be inadvertently accessible through a public proxy. Undertow locations are also now registered with the mod_cluster load balancer automatically unless they are explicitly excluded.

Use the following management CLI command to exclude ROOT from the modcluster subsystem configuration.

/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=excluded-contexts,value=ROOT)

Use the following management CLI command to disable the default welcome web application.

/subsystem=undertow/server=default-server/host=default-host/location=\/:remove
/subsystem=undertow/configuration=handler/file=welcome-content:remove
reload

For more information about how to configure the default welcome web application, see Configure the Default Welcome Web Application in the Development Guide for JBoss EAP.

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『設定ガイド』の「JGroups を用いたクラスター通信」を参照してください。

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

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

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

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

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

JBoss EAP 7.1 にて、パッシベーションに対してカスタムステートフルセッション bean (SFSB) を設定する場合は、以下の制限に注意してください。

JBoss EAP 7.0 の動作が JBoss EAP 7.1 で変更になったため、キャッシュコンテナートランスポートプロトコルの更新はバッチモードで実行するか、特別なヘッダーを使用して実行する必要があります。この動作の変更は、JBoss EAP サーバーの管理に使用されたすべてのツールにも影響があります。

以下は、JBoss EAP 7.0 でキャッシュコンテナートランスポートプロトコルの設定に使用された管理 CLI コマンドの例になります。

/subsystem=infinispan/cache-container=my:add()
/subsystem=infinispan/cache-container=my/transport=jgroups:add()
/subsystem=infinispan/cache-container=my/invalidation-cache=mycache:add(mode=SYNC)

以下は、JBoss EAP 7.1 で同じ設定を実行するために必要な管理 CLI コマンドの例になります。コマンドはバッチモードで実行されることに注意してください。

batch
/subsystem=infinispan/cache-container=my:add()
/subsystem=infinispan/cache-container=my/transport=jgroups:add()
/subsystem=infinispan/cache-container=my/invalidation-cache=mycache:add(mode=SYNC)
run-batch

バッチモードを使用したくない場合は、代わりにトランスポートの定義時に allow-resource-service-restart=true 操作ヘッダーを指定できます。これによりサービスが再起動され、操作が適用されますが、このサービスが再起動するまで一部のサービスが停止する可能性があります。

スクリプトを使用してキャッシュコンテナートランスポートプロトコルを更新する場合は、スクリプトを確認し、バッチモードを追加してください。

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:2.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 の移行操作」を参照してください。

forward-when-no-consumers 属性の動作変更

JBoss EAP 7 では、forward-when-no-consumers 属性の動作が変更になりました。

JBoss EAP 6 では、forward-when-no-consumers が false に設定され、クラスターにコンシューマーがない場合に、メッセージはクラスターのすべてのノードへ再分散されました。

この挙動は JBoss EAP 7 では変更になりました。forward-when-no-consumers が false に設定され、クラスターにコンシューマーがない場合にメッセージは再分散されず、メッセージの送信先のノードに保持されます。

デフォルトのクラスター負荷分散ポリシーの変更

JBoss では、デフォルトのクラスター負荷分散ポリシーが変更になりました。

JBoss EAP 6 ではデフォルトの負荷分散ポリシーは STRICT と似ており、レガシーの forward-when-no-consumers パラメーターを true に設定した場合と同様でした。JBoss EAP 7 では、デフォルトは ON_DEMAND になり、レガシーの forward-when-no-consumers パラメーターを false に設定した場合と同様になります。これらの設定の詳細は、JBoss EAP『Configuring Messaging』の「Cluster Connection Attributes」を参照してください。

Messaging サブシステムの XML 設定

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

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

You can use one of the following approaches to migrate messaging data from a previous release to the current release of JBoss EAP.

JMS サポートプロバイダーが HornetQ から ActiveMQ Artemis に変更になったため、JBoss EAP 7 およびそれ以上のリリースではメッセージングデータの形式と場所が変更になりました。6.4 から 7.x リリースで変更になったメッセージングデータフォルダー名と場所の詳細は、「メッセージングフォルダー名のマッピング」を参照してください。

$ 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/path=journal-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=paging-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=bindings-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=large-messages-directory:resolve-path

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:2.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 アクセプターを使用するよう、サーブレット設定を変更する必要があります。

サードパーティー JMS プロバイダーと使用するために汎用 JMS リソースアダプターを設定する方法は JBoss EAP 7 で変更になりました。詳細は、JBoss EAP『Configuring Messaging』の「Deploying a Generic JMS Resource Adapter」を参照してください。

JBoss EAP 7.0 では、check-for-live-server 属性を指定せずに replication-master ポリシーを設定した場合のデフォルト値が false でした。JBoss EAP 7.1 ではこれが変更になり、check-for-live-server 属性のデフォルト値が true になりました。

以下は、check-for-live-server 属性を指定せずに replication-master を設定する管理 CLI コマンドの例になります。

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:add(cluster-name=my-cluster,group-name=group1)

管理 CLI を使用してリソースを読み取ると、check-for-live-server 属性の値が true に設定されることに注意してください。

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "check-for-live-server" => true,
        "cluster-name" => "my-cluster",
        "group-name" => "group1",
        "initial-replication-sync-timeout" => 30000L
    },
    "response-headers" => {"process-state" => "reload-required"}
}

JMS 1.1 と JMS 2.0.0 では、javax.jms.JMSException の serialVersionUID が変更になりました。そのため、JMS 1.1 を使用して JMSException のインスタンスまたは JMSException のサブクラスをシリアライズした場合、JMS 2.0.0 を使用してデシリアライズすることはできません。その逆も同様です。JMS 2.0.0 を使用して JMSException のインスタンスをシリアライズした場合、JMS 1.1 を使用してデシリアライズすることはできません。両方の場合で以下のような例外が発生します。

javax.jms.JMSException: javax.jms.JMSException; local class incompatible: stream classdesc serialVersionUID = 8951994251593378324, local class serialVersionUID = 2368476267211489441

この問題は、JMS 2.0.1 メンテナンスリリースで修正されました。

以下の表は、各 JBoss EAP リリースの JMS 実装の詳細を表しています。

serialVersionUID の互換性が維持されないと、以下の状況で移行時に問題が発生することがあります。

JBoss EAP 6.4 クライアントを使用して JMSException が含まれるメッセージを送信し、メッセージングデータを JBoss EAP 7.1 に移行した後、JBoss EAP 7.1 クライアントを使用してそのメッセージをデシリアライズした場合、JMS 1.1 の serialVersionUID は JMS 2.0.1 の serialVersionUID と互換性があるため、デシリアライズに成功します。

以前のリリースの 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

FIPS モードで実行している場合、JBoss EAP 7.0 のデフォルト動作が JBoss EAP 7.1 では変更になったことに注意してください。

レガシーセキュリティーレルムを使用している場合、JBoss EAP 7.1 では開発の目的で自己署名証明書が自動的に生成されます。この機能は JBoss EAP 7.0 にはなく、デフォルトで有効になっています。そのため、FIPS モードで実行している場合、サーバーを設定して自己署名証明書の自動作成を無効にする必要があります。無効にしないと、サーバーの起動時に以下のエラーが発生することがあります。

ERROR [org.xnio.listener] (default I/O-6) XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: WFLYDM0114: Failed to lazily initialize SSL context
...
Caused by: java.lang.RuntimeException: WFLYDM0112: Failed to generate self signed certificate
...
Caused by: java.security.KeyStoreException: Cannot get key bytes, not PKCS#8 encoded

自己署名証明書の自動作成に関する詳細は、JBoss EAP『How to Configure Server Security』の「Automatic Self-signed Certificate Creation for Applications」を参照してください。