Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

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

4.1. サーバー設定移行オプション

サーバー設定を JBoss EAP 6 から JBoss EAP 7 に移行するには、JBoss Server Migration Tool 使用するか、管理 CLI の migrate 操作を使用して手作業で移行します。

JBoss Server Migration Tool

現在開発中の JBoss Server Migration Tool を使用して、既存の設定を保持しながら JBoss EAP 7 の新機能や新設定が含まれるように設定を更新することが推奨されます。

管理 CLI の migrate 操作

管理 CLI の migrate 操作を使用して JBoss EAP 6 設定ファイルの jacorbmessaging、および web サブシステムを更新すると、新しいリリースで実行できるようにすることができますが、完全な JBoss EAP 7 の設定にはならないことに注意してください。例を以下に示します。

  • この操作は、元の remote プロトコルおよびポート設定を JBoss EAP 7 で使用される新しい http-remoting およびポート設定に更新しません。
  • 設定には、新しい JBoss EAP サブシステム、クラスター化されたシングルトンデプロイメントなどの機能、正常シャットダウンが含まれません。
  • 設定には、バッチ処理などの新しい Java EE 7 の機能が含まれません。
  • The migrate operation does not migrate the ejb3 subsystem configuration. For information about possible EJB migration issues, see EJB Server Configuration Changes.

migrate 操作を使用したサーバー設定の移行に関する詳細は、管理 CLI の移行操作を参照してください。

4.2. 管理 CLI の移行操作

管理 CLI を使用して、JBoss EAP 7 上で実行するよう JBoss EAP 6 のサーバー設定ファイルを更新することができます。管理 CLI では、jacorbmessaging、および web サブシステムを以前のリリースから新しい設定へ自動的に更新する migrate 操作を実行できます。また、 jacorbmessaging、および web サブシステムに describe-migration 操作を実行すると、移行を行う前に提案された移行設定の変更を確認することもできます。cmpjaxr、および threads サブシステムの代替はないため、これらのサブシステムをサーバー設定から削除する必要があります。

重要

migrate 操作の制限については、サーバー設定移行オプションを参照してください。現在開発中の JBoss Server Migration Tool を使用して、既存の設定を保持しながら JBoss EAP 7 の新機能や新設定が含まれるように設定を更新することが推奨されます。

表4.1 サブシステムの移行および管理 CLI 操作

JBoss EAP 6 サブシステムJBoss EAP 7 サブシステム管理 CLI 操作

cmp

代替なし

remove

jacorb

iiop-openjdk

migrate

jaxr

代替なし

remove

messaging

messaging-activemq

migrate

threads

代替なし

remove

web

undertow

migrate

Start the Server and the Management CLI

以下の手順に従って、JBoss EAP 7 上で実行されるよう JBoss EAP 6 のサーバー設定を更新します。

  1. 移行を始める前に、重要データのバックアップおよびサーバー状態の確認の内容を見直してください。ここには、サーバーを良好な状態にし、適切なファイルをバックアップするための重要な情報が記載されています。
  2. JBoss EAP 6 の設定で JBoss EAP 7 のサーバーを起動します。

    1. JBoss EAP 7 サーバー設定ファイルをバックアップします。
    2. 以前のリリースの設定ファイルを JBoss EAP 7 ディレクトリーにコピーします。

      $ cp EAP6_HOME/standalone/configuration/standalone-full.xml EAP7_HOME/standalone/configuration
    3. JBoss EAP 7 のインストールディレクトリーへ移動し、--admin-only 引数を使用してサーバーを起動します。

      $ bin/standalone.sh -c standalone-full.xml --admin-only
      注記

      サーバーを起動すると、以下の org.jboss.as.controller.management-operation エラーがサーバーログに記録されます。これらのエラーは予期されたエラーで、レガシーサブシステムの設定を削除するか JBoss EAP 7 に移行する必要があることを示しています。

      • WFLYCTL0402: Subsystems [cmp] provided by legacy extension 'org.jboss.as.cmp' are not supported on servers running this version. Both the subsystem and the extension must be removed or migrated before the server will function.
      • WFLYCTL0402: Subsystems [jacorb] provided by legacy extension 'org.jboss.as.jacorb' are not supported on servers running this version. Both the subsystem and the extension must be removed or migrated before the server will function.
      • WFLYCTL0402: Subsystems [jaxr] provided by legacy extension 'org.jboss.as.jaxr' are not supported on servers running this version. Both the subsystem and the extension must be removed or migrated before the server will function.
      • WFLYCTL0402: Subsystems [messaging] provided by legacy extension 'org.jboss.as.messaging' are not supported on servers running this version. Both the subsystem and the extension must be removed or migrated before the server will function.
      • WFLYCTL0402: Subsystems [threads] provided by legacy extension 'org.jboss.as.threads' are not supported on servers running this version. Both the subsystem and the extension must be removed or migrated before the server will function.
      • WFLYCTL0402: Subsystems [web] provided by legacy extension 'org.jboss.as.web' are not supported on servers running this version. Both the subsystem and the extension must be removed or migrated before the server will function.
  3. 新しいターミナルを開いて、JBoss EAP 7 のインストールディレクトリーへ移動し、--controller=remote://localhost:9999 引数を使用して管理 CLI を開始します。

    $ bin/jboss-cli.sh --connect --controller=remote://localhost:9999

Migrate the JacORB, Messaging, and Web Subsystems

  1. 移行を行う前にサブシステムに追加した設定変更を確認するには、describe-migration 操作を実行します。

    describe-migration 操作では以下の構文を使用します。

    /subsystem=SUBSYSTEM_NAME:describe-migration

    以下の例は、JBoss EAP 7 に移行されるときに JBoss EAP 6.4 の standalone-full.xml 設定ファイルに加えられる設定の変更を示しています。見やすくするため、エントリーは出力から削除されています。

    例: describe-migration 操作

    [standalone@localhost:9999 /] /subsystem=messaging:describe-migration
    {
        "outcome" => "success",
        "result" => {
            "migration-warnings" => [],
            "migration-operations" => [
                {
                    "operation" => "add",
                    "address" => [("extension" => "org.wildfly.extension.messaging-activemq")],
                    "module" => "org.wildfly.extension.messaging-activemq"
                },
                {
                    "operation" => "add",
                    "address" => [("subsystem" => "messaging-activemq")]
                },
                <!-- *** Entries removed for readability *** -->
                {
                    "operation" => "remove",
                    "address" => [("subsystem" => "messaging")]
                },
                {
                    "operation" => "remove",
                    "address" => [("extension" => "org.jboss.as.messaging")]
                }
            ]
        }
    }

  2. migrate 操作を実行し、サブシステムの設定を JBoss EAP 7 の代替サブシステムに移行します。この操作では以下の構文を使用します。

    /subsystem=SUBSYSTEM_NAME:migrate
    注記

    messaging サブシステムの describe-migration および migrate 操作を使用すると、引数を渡してレガシークライアントによるアクセスを設定することができます。コマンド構文の詳細は、Messaging サブシステムの移行および前方互換性を参照してください。

  3. このコマンドの結果を確認します。必ず、操作が正常に完了し、"migration-warning" エントリーがないことを確認してください。これは、サブシステムの移行設定が完了したことを意味します。

    例: 警告のない成功した migrate 操作

    [standalone@localhost:9999 /] /subsystem=messaging:migrate
    {
        "outcome" => "success",
        "result" => {"migration-warnings" => []}
    }

    サーバー設定の移行が正常に完了したにも関わらず、すべての要素と属性を移行できなかった場合、ログに "migration-warnings" エントリーが表示されます。"migration-warnings" が示す提案に従い、追加の管理 CLI コマンドを実行してこれらの設定を編集する必要があります。"migration-warnings" を返す migrate 操作の例を以下に示します。

    例: 警告のある migrate 操作

    [standalone@localhost:9999 /] /subsystem=messaging:migrate
    {
        "outcome" => "success",
        "result" => {"migration-warnings" => [
            "WFLYMSG0080: Could not migrate attribute group-address from resource [
        (\"subsystem\" => \"messaging-activemq\"),
        (\"server\" => \"default\"),
        (\"broadcast-group\" => \"groupB\")
    ]. Use instead the socket-binding attribute to configure this broadcast-group.",
            "WFLYMSG0080: Could not migrate attribute group-port from resource [
        (\"subsystem\" => \"messaging-activemq\"),
        (\"server\" => \"default\"),
        (\"broadcast-group\" => \"groupB\")
    ]. Use instead the socket-binding attribute to configure this broadcast-group.",
            "WFLYMSG0080: Could not migrate attribute local-bind-address from resource [
        (\"subsystem\" => \"messaging-activemq\"),
        (\"server\" => \"default\"),
        (\"broadcast-group\" => \"groupA\")
    ]. Use instead the socket-binding attribute to configure this broadcast-group.",
            "WFLYMSG0080: Could not migrate attribute local-bind-port from resource [
        (\"subsystem\" => \"messaging-activemq\"),
        (\"server\" => \"default\"),
        (\"broadcast-group\" => \"groupA\")
    ]. Use instead the socket-binding attribute to configure this broadcast-group.",
            "WFLYMSG0080: Could not migrate attribute group-address from resource [
        (\"subsystem\" => \"messaging-activemq\"),
        (\"server\" => \"default\"),
        (\"broadcast-group\" => \"groupA\")
    ]. Use instead the socket-binding attribute to configure this broadcast-group.",
            "WFLYMSG0080: Could not migrate attribute group-port from resource [
        (\"subsystem\" => \"messaging-activemq\"),
        (\"server\" => \"default\"),
        (\"broadcast-group\" => \"groupA\")
    ]. Use instead the socket-binding attribute to configure this broadcast-group."
        ]}
    }

    注記

    各サブシステムの migrate および describe-migration 警告のリストは、本ガイドの最後にあるリファレンス資料 に記載されています。

  4. サーバー設定ファイルを確認し、拡張、サブシステム、および名前空間が更新され、既存のサブシステム設定が JBoss EAP 7 に移行されたことを確認します。

    注記

    この手順は、以下のコマンドを使用して jacorbmessaging、および web の各サブシステムに対して繰り返す必要があります。

    /subsystem=jacorb:migrate
    /subsystem=messaging:migrate
    /subsystem=web:migrate
  5. cmpjaxr、および threads サブシステムおよび拡張をサーバー設定から削除します。

    管理 CLI プロンプトで以下のコマンドを実行し、廃止された cmpjaxr、および threads サブシステムを削除します。

    /subsystem=cmp:remove
    /extension=org.jboss.as.cmp:remove
    /subsystem=jaxr:remove
    /extension=org.jboss.as.jaxr:remove
    /subsystem=threads:remove
    /extension=org.jboss.as.threads:remove
重要

サーバーを再起動する前に messagingjacorb、および web サブシステムを移行し、cmpjaxr、および threads 拡張およびサブシステムを削除する必要があります。この作業の完了前にサーバーを再起動する必要がある場合は、サーバー起動のコマンドラインで --admin-only 引数を使用するようにしてください。これにより、サーバーの変更を継続できます。

4.3. ロギングメッセージの接頭辞の変更

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

For a complete list of the new log message project code prefixes used in JBoss EAP 7, see Project Codes Used in JBoss EAP in the JBoss EAP Development Guide.

4.4. Web サーバー設定の変更

4.4.1. Undertow による Web サブシステムの置換

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

  • サーバー設定ファイルの urn:jboss:domain:web:2.2 サブシステム設定ネームスペースは urn:jboss:domain:undertow:3.1 ネームスペースに置き換えられました。
  • EAP_HOME/modules/system/layers/base/ にあった org.jboss.as.web 拡張モジュールは、org.wildfly.extension.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>

4.4.2. JBoss Web リライト条件の移行

管理 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>

For more information about how to configure filters and handlers using the management CLI, see Configuring the Web Server in the JBoss EAP 7 Configuration Guide.

4.4.3. Migrate JBoss Web System Properties

In the previous release of JBoss EAP, system properties could be used to modify the default JBoss Web behavior. For information about how to configure the same behavior in Undertow, see JBoss Web System Properties Migration Reference

4.4.4. Migrate JBoss Web jboss-web.xml Overlay

In JBoss EAP 6, JBoss Web supported the ability to specify additional static files for a web application using the overlay element in the jboss-web.xml file. This feature did not actually overlay existing files, but instead added static files to a deployment outside of the WAR archive.

In the following jboss-web.xml file example, /tmp/mycontents/test.html was returned by the JBoss EAP 6 server when you accessed the URL http://localhost:8080/example/test.html.

<jboss-web>
    <context-root>/example</context-root>
    <overlay>/tmp/mycontents/</overlay>
</jboss-web>

Undertow, which replaces JBoss Web in JBoss EAP 7, does not support the jboss-web.xml file overlay feature.

4.4.5. グローバルバルブの移行

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

  • グローバルバルブは、デプロイされたすべてのアプリケーションのリクエスト処理パイプラインへ挿入され、サーバー設定ファイルで設定されます。
  • オーセンティケーターバルブはリクエストのクレデンシャルを認証します。
  • カスタムアプリケーションバルブは、org.apache.catalina.valves.ValveBase クラスを拡張して作成され、jboss-web.xml 記述子ファイルの <valve> 要素で設定されます。これらのバルブは手作業で移行する必要があります。

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

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

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

For more information about how to configure handlers, see Configuring Handlers in the JBoss EAP 7 Configuration Guide.

For more information about how to configure filters, see Configuring Filters in the JBoss EAP 7 Configuration Guide.

JBoss Web バルブの移行

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

表4.2 バルブとハンドラーのマッピング

バルブハンドラー

AccessLogValve

io.undertow.server.handlers.accesslog.AccessLogHandler

CrawlerSessionManagerValve

io.undertow.servlet.handlers.CrawlerSessionManagerHandler

ExtendedAccessLogValve

io.undertow.server.handlers.accesslog.AccessLogHandler

JDBCAccessLogValve

手順については JDBCAccessLogValve の手動移行の手順を参照してください。

RemoteAddrValve

io.undertow.server.handlers.IPAddressAccessControlHandler

RemoteHostValve

io.undertow.server.handlers.AccessControlListHandler

RemoteIpValve

io.undertow.server.handlers.ProxyPeerAddressHandler

RequestDumperValve

io.undertow.server.handlers.RequestDumpingHandler

RewriteValve

これらのバルブを手作業で移行する手順は、JBoss Web リライト条件の移行 を参照してください。

StuckThreadDetectionValve

io.undertow.server.handlers.StuckThreadDetectionHandler

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

  • 前述の表にリストされている、手動処理の必要がないバルブに限定されます。
  • サーバー設定ファイルの web サブシステムに定義されている必要があります。

管理 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>
  1. ログエントリーを保存するデータベースのドライバーモジュールを作成します。
  2. データベースのデータソースを設定し、ドライバーを datasources サブシステムの利用可能なドライバーのリストに追加します。

    <datasources>
        <datasource jndi-name="java:jboss/datasources/accessLogDS" pool-name="accessLogDS" enabled="true" use-java-context="true">
            <connection-url>jdbc:mysql://localhost:3306/wildfly?zeroDateTimeBehavior=convertToNull</connection-url>
            <driver>mysql</driver>
            <security>
               <user-name>root</user-name>
               <password>Password1!</password>
            </security>
        </datasource>
        ...
        <drivers>
            <driver name="mysql" module="com.mysql">
                <driver-class>com.mysql.jdbc.Driver</driver-class>
            </driver>
        ...
        </drivers>
    </datasources>
  3. jdbc-access-log(datasource=DATASOURCE_JNDI_NAME) を使用して、undertow サブシステムの expression-filter を設定します。

    <filters>
        <expression-filter name="jdbc-access" expression="jdbc-access-log(datasource='java:jboss/datasources/accessLogDS')" />
        ...
    </filters>

4.5. JGroups サーバー設定の変更

4.5.1. JGroups はデフォルトでプライベートネットワークインターフェースを使用

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

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

4.5.2. JGroups チャネルの変更

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

For more information about how to configure JGroups, see Cluster Communication with JGroups in the JBoss EAP Configuration Guide.

4.6. Infinispan サーバー設定の変更

4.6.1. Infinispan のデフォルトキャッシュ設定の変更

In JBoss EAP 6, the default clustered caches for web session replication and EJB replication were replicated ASYNC caches. This has changed in JBoss EAP 7. The default clustered caches are now distributed ASYNC caches. The replicated caches are no longer even configured by default. See Configure the Cache Mode in the JBoss EAP Configuration Guide for information about how to add a replicated cache and make it the default.

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

4.6.2. Infinispan のキャッシュストラテジーの変更

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

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

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

4.7. EJB Server Configuration Changes

If you use the management CLI migrate operation to upgrade your existing configuration, you might see exceptions in the server log when you deploy your EJB applications.

重要

If you use the JBoss Server Migration Tool to update your server configuration, the ejb3 subsystem should be configured correctly and you should not see any issues when you deploy your EJB applications.

DuplicateServiceException

The following DuplicateServiceException is caused by caching changes in JBoss EAP 7.

DuplicateServiceException in Server Log

ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: org.jboss.msc.service.StartException in service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: Failed to start service
...
Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.infinispan.ejb."mdb-1.0-SNAPSHOT.jar".config is already registered

You must reconfigure the cache to resolve this error.

  1. Follow the instructions to Start the Server and the Management CLI.
  2. Issue the following commands to reconfigure caching in the ejb3 subsystem.

    /subsystem=ejb3/file-passivation-store=file:remove
    /subsystem=ejb3/cluster-passivation-store=infinispan:remove
    /subsystem=ejb3/passivation-store=infinispan:add(cache-container=ejb, max-size=10000)
    
    /subsystem=ejb3/cache=passivating:remove
    /subsystem=ejb3/cache=clustered:remove
    /subsystem=ejb3/cache=distributable:add(passivation-store=infinispan, aliases=[passivating, clustered])

4.8. メッセージングサーバー設定の変更

JBoss EAP 7 では、JMS サポートプロバイダーが HornetQ から ActiveMQ Artemis に変更になりました。ここでは、設定と関連するメッセージングデータの移行方法を説明します。

4.8.1. メッセージングサブシステムサーバー設定の変更

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 ネームスペースに置き換えられました。

管理モデル

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

表4.3 メッセージング属性のマッピング

HornetQ での名前ActiveMQ での名前 

hornetq-server

server

hornetq-serverType

serverType

connectors

connector

discovery-group-name

discovery-group

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

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

/subsystem=messaging:migrate

Before you execute the migrate operation, you can invoke the describe-migration operation to review the list of management operations that will be performed to migrate from the existing JBoss EAP 6 messaging subsystem configuration to the messaging-activemq subsystem on the JBoss EAP 7 server.

/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-entriestrue に設定されていると、messaging-activemq サブシステムが legacy-connection-factory リソースを作成し、legacy-entriesjms-queue および jms-topic リソースに追加します。

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

For more information about forward and backward compatibility see the Backward and Forward Compatibility in Configuring Messaging for JBoss EAP.

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

Change in Behavior of forward-when-no-consumers Attribute

The behavior of the forward-when-no-consumers attribute has changed in JBoss EAP 7.

In JBoss EAP 6, when forward-when-no-consumers was set to false and there were no consumers in a cluster, messages were redistributed to all nodes in a cluster.

This behavior has changed in JBoss EAP 7. When forward-when-no-consumers is set to false and there are no consumers in a cluster, messages are not redistributed. Instead, they are kept on the original node to which they were sent.

Messaging サブシステムの XML 設定

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

It is strongly advised that you do not attempt to modify the JBoss EAP messaging subsystem XML configuration to conform to the new messaging-activemq subsystem. Instead, invoke the legacy subsystem migrate operation. This operation will write the XML configuration of the new messaging-activemq subsystem as a part of its execution.

4.8.2. メッセージングデータの移行

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

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

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

4.8.2.1. エクスポートおよびインポートを使用したメッセージングデータの移行

この方法では、HornetQ の exporter ユーティリティーを使用して以前のリリースからデータをエクスポートします。その後、import-journal 操作を使用して XML 形式の出力ファイルをインポートします。

警告

現在、この方法には既知の問題が存在します。この問題の最新状況を確認するには、 JBEAP-4407 - Consumer crashes with IndexOutOfBoundsException when reading large messages from imported journal (インポートされたジャーナルから大型のメッセージを読み取ると、IndexOutOfBoundsException によってコンシューマーがクラッシュする) を参照してください。

前リリースからのメッセージングデータのエクスポート
重要

メッセージングデータをエクスポートする前に、JBoss EAP 6 サーバーを停止する必要があります。

HornetQ exporter ユーティリティーは、メッセージングデータを生成し、JBoss EAP 6 から XML 形式のファイルへエクスポートします。このコマンドでは、JBoss EAP 6 に同梱されている必須の HornetQ JAR へのパスを指定し、以前のリリースからの messagingbindings/messagingjournal/messagingpaging/、および messaginglargemessages/ フォルダーへのパスを引数として渡し、エクスポートされる XML データを書き込む出力ファイルを指定する必要があります。

以下は HornetQ exporter ユーティリティーで必要となる構文です。

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

カスタムモジュールを作成し、パッチやアップグレードでインストールされた JAR を含む HornetQ JAR の正しいバージョンがロードされ、exporter ユーティリティーで利用可能になるようにします。好みのエディターを使用して、EAP6_HOME/modules/org/hornetq/exporter/main/ ディレクトリー内に module.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>
注記

カスタムモジュールは modules/system/layers/base/ ディレクトリーではなく、modules/ ディレクトリー内に作成します。

以下の手順に従い、データをエクスポートします。

  1. JBoss EAP 6 サーバーを停止します。
  2. 上記の説明にあるようにカスタムモジュールを作成します。
  3. 以下のコマンドを実行してデータをエクスポートします。

    $ java -jar jboss-modules.jar -mp modules/ org.hornetq.exporter standalone/data/messagingbindings/ standalone/data/messagingjournal/ standalone/data/messagingpaging standalone/data/messaginglargemessages/ > OUTPUT_DIRECTORY/OldMessagingData.xml
  4. コマンド完了後に、ログにエラーや警告メッセージがないことを確認します。
  5. 使用中のオペレーティングシステムで利用可能なツールを使用して、生成された出力ファイルの XML を検証します。
XML 形式のメッセージングデータのインポート

その後は、以下のように import-journal 操作で XML 形式の出力ファイルをインポートします。

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

4.8.2.2. JMS ブリッジを使用したメッセージングデータの移行

この方法では、JBoss EAP 6 の HornetQ キューから JBoss EAP 7 の ActiveMQ Artemis キューへメッセージを移行する JMS ブリッジを JBoss EAP 7 サーバーに設定およびデプロイします。

JMS ブリッジはソースの JMS キューまたはトピックからメッセージを消費し、通常は異なるサーバーにあるターゲットの JMS キューまたはトピックへ送信します。JMS 1.1 に準拠する JMS サーバーの間でメッセージをブリッジするために使用できます。送信元および宛先の JMS リソースは、JNDI を使用してルックアップされ、JNDI ルックアップのクライアントクラスはモジュールでバンドルされる必要があります。モジュール名は JMS ブリッジ設定で宣言されます。

ここでは、メッセージングデータを JBoss EAP 6 から JBoss EAP 7 に移動するためにサーバーを設定し、JMS ブリッジをデプロイする方法を説明します。

JBoss EAP 6 サーバーの設定
  1. JBoss EAP 6 サーバーを停止します。
  2. HornetQ のジャーナルおよび設定ファイルをバックアップします。

    • デフォルトでは、HornetQ ジャーナルは EAP6_HOME/standalone/data/ ディレクトリーにあります。
    • 各リリースにおけるメッセージングフォルダーのデフォルトの場所は、メッセージングフォルダー名のマッピングを参照してください。
  3. JMS メッセージが含まれる InQueue JMS キューが JBoss EAP 6 サーバーで定義されていることを確認してください。
  4. messaging サブシステムの設定に以下と似た RemoteConnectionFactory のエントリーが含まれていることを確認してください。

    <connection-factory name="RemoteConnectionFactory">
        <entries>
            <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
        </entries>
        ...
    </connection-factory>

    エントリーが含まれていない場合は、以下の管理 CLI コマンドを使用して作成します。

    /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:add(factory-type=XA_GENERIC, connector=[netty], entries=[java:jboss/exported/jms/RemoteConnectionFactory],ha=true,block-on-acknowledge=true,retry-interval=1000,retry-interval-multiplier=1.0,reconnect-attempts=-1)
JBoss EAP 7 サーバーの設定
  1. 以前のリリースでは、JMS ブリッジ設定が HornetQ サーバーに接続するには、org.hornetq モジュールが必要です。このモジュールと直接の依存関係は JBoss EAP 7 では存在しないため、以前のリリースから以下のモジュールをコピーする必要があります。

    • org.hornetq モジュールを JBoss EAP 7 EAP_HOME/modules/org/ ディレクトリーにコピーします。

      • If you did not apply patches to this module, copy this folder from the JBoss EAP 6.4 server: EAP6_HOME/modules/system/layers/base/org/hornetq/
      • If you did apply patches to this module, copy this folder from the JBoss EAP 6.4 server: EAP6_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.x.CP/org/hornetq/
    • Remove the <resource-root> for the HornetQ lib path from the JBoss EAP 7 EAP_HOME/modules/org/hornetq/main/module.xml file.

      • If you did not apply patches to the JBoss EAP 6.4 org.hornetq module, remove the following line from the file:

        <resource-root path="lib"/>
      • If you did apply patches to the JBoss EAP 6.4 org.hornetq module, remove the following lines from the file:

        <resource-root path="lib"/>
        <resource-root path="../../../../../org/hornetq/main/lib"/>
        警告

        Failure to remove the HornetQ lib path resource-root will cause the bridge to fail with the following error in the log file.

        2016-07-15 09:32:25,660 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
            ("subsystem" => "messaging-activemq"),
            ("jms-bridge" => "myBridge")
        ]) - failure description: "WFLYMSGAMQ0086: Unable to load module org.hornetq"
    • Copy the org.jboss.netty module into the JBoss EAP 7 EAP_HOME/modules/org/jboss/ directory.

      • If you did not apply patches to this module, copy this folder from the JBoss EAP 6.4 server: EAP6_HOME/modules/system/layers/base/org/jboss/netty/
      • If you did apply patches to this module, copy this folder from the JBoss EAP 6.4 server: EAP6_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.x.CP/org/jboss/netty
  2. JBoss EAP 6 サーバーから受信したメッセージを格納するために JSM キューを作成します。以下は、MigratedMessagesQueue JMS キューを作成してメッセージを受信する管理 CLI コマンドの例になります。

    jms-queue add --queue-address=MigratedMessagesQueue --entries=[jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue]

    このコマンドにより、JBoss EAP 7 サーバーの messaging-activemq サブシステムに以下のデフォルトサーバー用の jms-queue 設定が作成されます。

    <jms-queue name="MigratedMessagesQueue" entries="jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue"/>
  3. messaging-activemq サブシステムの default サーバーに以下と似た InVmConnectionFactory connection-factory の設定が含まれるようにしてください。

    <connection-factory name="InVmConnectionFactory" factory-type="XA_GENERIC" entries="java:/ConnectionFactory" connectors="in-vm"/>

    エントリーが含まれていない場合は、以下の管理 CLI コマンドを使用して作成します。

    /subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:add(factory-type=XA_GENERIC, connectors=[in-vm], entries=[java:/ConnectionFactory])
  4. JBoss EAP 6 サーバーで設定された InQueue JMS キューからメッセージを読み取る JMS ブリッジを作成およびデプロイし、JBoss EAP 7 サーバーで設定された MigratedMessagesQueue に転送します。

    /subsystem=messaging-activemq/jms-bridge=myBridge:add(add-messageID-in-header=true,max-batch-time=100,max-batch-size=10,max-retries=-1,failure-retry-interval=1000,quality-of-service=AT_MOST_ONCE,module=org.hornetq,source-destination=jms/queue/InQueue,source-connection-factory=jms/RemoteConnectionFactory,source-context=[("java.naming.factory.initial"=>"org.jboss.naming.remote.client.InitialContextFactory"),("java.naming.provider.url"=>"remote://127.0.0.1:4447")],target-destination=jms/queue/MigratedMessagesQueue,target-connection-factory=java:/ConnectionFactory)

    これにより、JBoss EAP 7 サーバーの messaging-activemq サブシステムに以下の jms-bridge 設定が作成されます。

    <jms-bridge name="myBridge" add-messageID-in-header="true" max-batch-time="100" max-batch-size="10" max-retries="-1" failure-retry-interval="1000" quality-of-service="AT_MOST_ONCE" module="org.hornetq">
        <source destination="jms/queue/InQueue" connection-factory="jms/RemoteConnectionFactory">
            <source-context>
                <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
                <property name="java.naming.provider.url" value="remote://127.0.0.1:4447"/>
            </source-context>
        </source>
        <target destination="jms/queue/MigratedMessagesQueue" connection-factory="java:/ConnectionFactory"/>
    </jms-bridge>
  5. また、セキュリティーが JBoss EAP 6 に設定されている場合、接続の作成時に JNDI ルックアップで使用される正しいユーザー名およびパスワードを指定する source-context が含まれるよう、JMS ブリッジ設定 <source> 要素を設定する必要もあります。
データの移行
  1. 以下の設定に提供する情報が正しいことを確認します。

    • キューおよびトピック名
    • JUDI ルックアップの java.naming.provider.url
  2. ターゲットの JMS 宛先が JBoss EAP 7 サーバーにデプロイされているようにしてください。
  3. JBoss EAP 6 サーバーと JBoss EAP 7 サーバーを両方起動します。

4.8.2.3. メッセージングフォルダー名のマッピング

以下の表では、JBoss EAP の以前および現在のリリースで対応するメッセージングディレクトリーの名前を示しています。ディレクトリーは jboss.server.data.dir ディレクトリーに相対的で、指定がない場合はデフォルトで EAP_HOME/standalone/data/ になります。

jBoss EAP 6 の ディレクトリー名JBoss EAP 7 のディレクトリー名

messagingbindings/

activemq/bindings/

messagingjournal/

activemq/journal/

messaginglargemessages/

activemq/largemessages/

messagingpaging/

activemq/paging/

注記

The messaginglargemessages/ and messagingpaging/ directories might not be present if there are no large messages or if paging is disabled.

4.8.3. JMS 宛先の移行

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>

4.8.4. メッセージングインターセプターの移行

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

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

The messaging-activemq subsystem included in JBoss EAP 7 does not require modification of a module.xml file. User interceptor classes, which now implement the Apache ActiveMQ Artemis Interceptor interface, can now be loaded from any server module. You specify the module from which the interceptor should be loaded in the messaging-activemq subsystem of the server configuration file.

インターセプター設定の例

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

4.8.5. Netty サーブレット設定の変更

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

4.9. JMX Management Changes

The HornetQ component in JBoss EAP 6 provided its own JMX management; however, it was not recommended and is now deprecated and no longer supported. If you relied on this feature in JBoss EAP 6, you must migrate your management tooling to use either the JBoss EAP management CLI or the JMX management provided with JBoss EAP 7.

You must also upgrade your client libraries to use the jboss-client.jar that ships with JBoss EAP 7.

The following is an example of HornetQ JMX management code that was used in JBoss EAP 6.

JMXConnector connector = null;
try {
    HashMap environment = new HashMap();
    String[] credentials = new String[]{"admin", "Password123!"};
    environment.put(JMXConnector.CREDENTIALS, credentials);

    // HornetQ used the protocol "remoting-jmx" and port "9999"
    JMXServiceURL beanServerUrl = new JMXServiceURL("service:jmx:remoting-jmx://127.0.0.1:9999");

    connector = JMXConnectorFactory.connect(beanServerUrl, environment);
    MBeanServerConnection mbeanServer = connector.getMBeanServerConnection();

    // The JMX object name pointed to the HornetQ JMX management
    ObjectName objectName = new ObjectName("org.hornetq:type=Server,module=JMS");

    // The invoked method name was "listConnectionIDs"
    String[] connections = (String[]) mbeanServer.invoke(objectName, "listConnectionIDs", new Object[]{}, new String[]{});
    for (String connection : connections) {
        System.out.println(connection);
    }
} finally {
    if (connector != null) {
      connector.close();
   }
}

The following is an example of the equivalent code needed for ActiveMQ Artemis in JBoss EAP 7.

JMXConnector connector = null;
try {
    HashMap environment = new HashMap();
    String[] credentials = new String[]{"admin", "Password123!"};
    environment.put(JMXConnector.CREDENTIALS, credentials);

    // ActiveMQ Artemis uses the protocol "remote+http" and port "9990"
    JMXServiceURL beanServerUrl = new JMXServiceURL("service:jmx:remote+http://127.0.0.1:9990");

    connector = JMXConnectorFactory.connect(beanServerUrl, environment);
    MBeanServerConnection mbeanServer = connector.getMBeanServerConnection();

    // The JMX object name points to the new JMX management in the `messaging-activemq` subsystem
    ObjectName objectName = new ObjectName("jboss.as:subsystem=messaging-activemq,server=default");

    // The invoked method name is now "listConnectionIds"
    String[] connections = (String[]) mbeanServer.invoke(objectName, "listConnectionIds", new Object[]{}, new String[]{});
    for (String connection : connections) {
        System.out.println(connection);
    }
} finally {
    if (connector != null) {
      connector.close();
   }
}

Notice that the method names and parameters have changed in the new implementation. You can find the new method names in the JConsole by following these steps.

  1. Connect to the JConsole using the following command.

    EAP_HOME/bin/jconsole.sh
  2. Connect to JBoss EAP local process. Note that it should start with "jboss-modules.jar".
  3. In the MBeans tab, choose jboss.asmessaging-activemqdefaultOperations to display the list of method names and attributes.

4.10. ORB サーバー設定の変更

JBoss EAP 7 では、JacORB 実装が OpenJDK ORB のダウンストリームブランチに変更になりました。

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

サーバー設定ファイルの urn:jboss:domain:jacorb:1.4 サブシステム設定ネームスペースは urn:jboss:domain:iiop-openjdk:1.0 ネームスペースに置き換えられました。

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

<subsystem xmlns="urn:jboss:domain:jacorb:1.4">
    <orb socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
        <initializers security="identity" transactions="spec"/>
    </orb>
</subsystem>

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

<subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
    <orb socket-binding="jacorb" ssl-socket-binding="jacorb-ssl" />
    <initializers security="identity" transactions="spec" />
</subsystem>

新しい iiop-openjdk サブシステム設定は、レガシー要素および属性のサブセットのみを受け入れます。以下は、有効な要素および属性がすべて含まれる、前リリースの JBoss EAP の jacorbサブシステム設定例になります。

<subsystem xmlns="urn:jboss:domain:jacorb:1.4">
   <orb name="JBoss" print-version="off" use-imr="off" use-bom="off"  cache-typecodes="off"
       cache-poa-names="off" giop-minor-version="2" socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
       <connection retries="5" retry-interval="500" client-timeout="0" server-timeout="0"
           max-server-connections="500" max-managed-buf-size="24" outbuf-size="2048"
           outbuf-cache-timeout="-1"/>
       <initializers security="off" transactions="spec"/>
   </orb>
   <poa monitoring="off" queue-wait="on" queue-min="10" queue-max="100">
       <request-processors pool-size="10" max-threads="32"/>
   </poa>
   <naming root-context="JBoss/Naming/root" export-corbaloc="on"/>
   <interop sun="on" comet="off" iona="off" chunk-custom-rmi-valuetypes="on"
       lax-boolean-encoding="off" indirection-encoding-disable="off" strict-check-on-tc-creation="off"/>
   <security support-ssl="off" add-component-via-interceptor="on" client-supports="MutualAuth"
       client-requires="None" server-supports="MutualAuth" server-requires="None"/>
   <properties>
       <property name="some_property" value="some_value"/>
   </properties>
</subsystem>

以下の要素属性はサポート対象外になったため、削除する必要があります。

表4.4 削除する属性

要素サポートされない属性

<orb>

  • client-timeout
  • max-managed-buf-size
  • max-server-connections
  • outbuf-cache-timeout
  • outbuf-size
  • connection retries
  • retry-interval
  • name
  • server-timeout

<poa>

  • queue-min
  • queue-max
  • pool-size
  • max-threads

以下の on/off 属性はサポート対象外となり、管理 CLI の migrate 操作を実行しても移行されません。これらの属性が on に設定されていると移行の警告が表示されます。<security support-ssl="on|off"> などの、この表に記載されていない on/off 属性のサポートは継続され、正常に移行されます。唯一の違いは、値が on/off から true/false に変更されることです。

表4.5 off に設定するまたは削除する属性

要素off に設定する属性

<orb>

  • cache-poa-names
  • cache-typecodes
  • print-version
  • use-bom
  • use-imr

<interop>

(sun 以外すべて)

  • comet
  • iona
  • chunk-custom-rmi-valuetypes
  • indirection-encoding-disable
  • lax-boolean-encoding
  • strict-check-on-tc-creation

<poa/>

  • monitoring
  • queue-wait

4.11. threads サブシステム設定の移行

JBoss EAP 6 のサーバー設定には、サーバーの異なるサブシステムにまたがってスレッドプールを管理するために使用される threads が含まれていました。

threads サブシステムは JBoss EAP 7 では利用できないようになりました。この代わりに、各サブシステムが独自のスレッドプールを管理します。

For information about how to configure thread pools for the infinispan subsystem, see Configure Infinispan Thread Pools in the JBoss EAP Configuration Guide.

For information about how to configure thread pools for the jgroups subsystem, see Configure JGroups Thread Pools in the JBoss EAP Configuration Guide.

In JBoss EAP 6, you configured thread pools for connectors and listeners for the web subsystem by referencing an executor that was defined in the threads subsystem. In JBoss EAP 7, you now configure thread pools for the undertow subsystem by referencing a worker that is defined in the io subsystem. For more information, see Configuring the IO Subsystem in the JBoss EAP Configuration Guide.

For information about about changes to thread pool configuration in the remoting subsystem, see Migrate the Remoting Subsystem Configuration in this guide, and Configuring the Endpoint in the JBoss EAP Configuration Guide.

4.12. Remoting サブシステム設定の移行

JBoss EAP 6 では、複数の worker-* 属性を設定して remoting サブシステムのスレッドプールを設定しました。JBoss EAP 7 では remoting サブシステムでワーカースレッドプールを設定しないようになりました。既存の設定を変更しようとすると、以下のメッセージが表示されます。

WFLYRMT0022: Worker configuration is no longer used, please use endpoint worker configuration

JBoss EAP 7 では、ワーカースレッドプールは、io サブシステムで定義される worker を参照するエンドポイント設定に置き換えられました。

For information about how to configure the endpoint, see Configuring the Endpoint in the JBoss EAP Configuration Guide.

4.13. WebSocket サーバー設定の変更

JBoss EAP 6 で WebSockets を使用するには、以下と同様のコマンドを使用して JBoss EAP サーバー設定ファイルの web サブシステムにある http コネクターに対して非ブロッキング Java NIO2 コネクターを有効にする必要がありました。

/subsystem=web/connector=http/:write-attribute(name=protocol,value=org.apache.coyote.http11.Http11NioProtocol)

アプリケーションで WebSockets を使用するには、アプリケーションの WEB-INF/jboss-web.xml ファイル内で <enable-websockets> 要素を作成し、これを true に設定する必要もありました。

JBoss EAP 7 では、デフォルトの WebSocket サポートに対してサーバーを設定したり、アプリケーションがそれを使用するように設定したりする必要がなくなりました。WebSocket は Java EE 7 では必須で、必要なプロトコルはデフォルトで設定されています。さらに複雑な WebSocket の設定は、JBoss EAP サーバー設定ファイルの undertow サブシステムにある servlet-container で行います。以下のコマンドを実行すると、使用できる設定を表示できます。

/subsystem=undertow/servlet-container=default/setting=websockets:read-resource(recursive=true)
{
   "outcome" => "success",
   "result" => {
       "buffer-pool" => "default",
       "dispatch-to-worker" => true,
       "worker" => "default"
   }
}

また、WebSocket のコードサンプルは JBoss EAP に同梱されるクイックスタートに含まれています。

4.14. シングルサインオンサーバーの変更

The infinispan subsystem still provides distributed caching support for HA services in the form of Infinispan caches in JBoss EAP 7; however the caching and distribution of authentication information is handled differently than in previous releases.

JBoss EAP 6 では、シングルサインオン (SSO) が Infinispan キャッシュに提供されないと、キャッシュが分散されませんでした。

JBoss EAP 7 では、HA プロファイルを選択すると SSO が自動的に分散されるようになりました。HA プロファイルを実行している場合、各ホストは web キャッシュコンテナーのデフォルトキャッシュを基にした独自の Infinispan キャッシュを持ちます。このキャッシュは関連するセッションとホストの SSO クッキーの情報を格納します。JBoss EAP は、各キャッシュ情報をすべてのホストに伝搬する処理を行います。JBoss EAP 7 では、明確に Infinispan キャッシュを SSO に割り当てる方法はありません。

JBoss EAP 7 では、SSO はサーバー設定ファイルの undertow サブシステムで設定されます。

JBoss EAP 7 に移行する際、アプリケーションコードを変更する必要はありません。

4.15. データソース設定の変更

4.15.1. JBDC データソースドライバー名

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

JAR_NAME と DRIVER_CLASS_NAME の間にアンダースコアが加えられています。

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

JBoss EAP 6 ドライバー名の例

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

JBoss EAP 7 ドライバー名の例

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

4.16. セキュリティーサーバー設定の変更

For information about Java Security Manager server configuration changes, see Considerations Moving from Previous Versions in How To Configure Server Security for JBoss EAP.

4.17. トランザクションサブシステムの変更

JBoss EAP 6 の transactions サブシステムで使用できた Transaction Manager 設定属性の一部が JBoss EAP 7 で変更になりました。

Removed Transactions Subsystem Attributes

以下の表は、JBoss EAP 7 の transactions サブシステムから削除された JBoss EAP 6 の属性と、それらの代替となる同等の属性を示しています。

JBoss EAP 6 の属性JBoss EAP 7 で代替となる属性

パス

object-store-path

relative-to

object-store-relative-to

非推奨となったトランザクションサブシステム属性

The following attributes that were available in the transactions subsystem in JBoss EAP 6 are deprecated in JBoss EAP 7. The deprecated attributes might be removed in a future release of the product. The following table lists the equivalent replacement attributes.

JBoss EAP 6 の属性JBoss EAP 7 で代替となる属性

use-hornetq-store

use-journal-store

hornetq-store-enable-async-io-to

journal-store-enable-async-io

enable-statistics

statistics-enabled

4.18. mod_cluster 設定の変更

JBoss EAP 7 では、mod_cluster の静的プロキシーの設定が変更になりました。

JBoss EAP 6 では、hostname:port の形式で指定された httpd プロキシーアドレスのカンマ区切りリストである proxy-list 属性を設定しました。

proxy-list 属性は JBoss EAP 7 では非推奨になりました。この属性は、アウトバウンドソケットバインディング名のリストである proxies 属性に置き換えられました。

This change impacts how you define a static proxy list, for example, when disabling advertising for mod_cluster. For information about how to disable advertising for mod_cluster, see Disable Advertising for mod_cluster in the JBoss EAP Configuration Guide.

For more information about mod_cluster attributes, see ModCluster Subsystem Attributes in the JBoss EAP Configuration Guide.