第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 の機能が含まれません。

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

以下の手順に従って、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
  4. jacorbmessaging、および web サブシステムを移行します。

    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 では、すべてのログメッセージの接頭辞が変更になりました。

JBoss EAP 7 で使用されるログメッセージの新しいプロジェクトコード接頭辞の完全リストは、JBoss EAP Development GuideProject Codes Used in JBoss EAP を参照してください。

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>

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

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

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

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

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

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

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

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

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

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 チャネル設定を追加、削除、および変更できます。

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

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

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

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

これは、新しい 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. メッセージングサーバー設定の変更

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

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

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

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

前方互換性および後方互換性に関する詳細は、JBoss EAP Configuring MessagingBackward 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 設定を書き込みます。

4.7.2. メッセージングログの変更

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

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

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

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

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

4.7.3.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/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.7.3.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/ ディレクトリーにコピーします。

      • このモジュールにパッチを適用していない場合は、JBoss EAP 6.4 サーバーの EAP6_HOME/modules/system/layers/base/org/hornetq/ フォルダーをコピーします。
      • このモジュールにパッチを適用した場合は、JBoss EAP 6.4 サーバーの EAP6_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.x.CP/org/hornetq/ フォルダーをコピーします。

        注記

        パッチが適用されたバージョンでは、以下の行を JBoss EAP 7 の modules/system/layers/base/org/hornetq/main/module.xml ファイルから削除する必要があります。

        <resource-root path="../../../../../org/hornetq/main/lib"/>
    • org.jboss.netty モジュールを JBoss EAP 7 の EAP_HOME/modules/org/jboss/ ディレクトリーへコピーします。

      • このモジュールにパッチを適用していない場合は、JBoss EAP 6.4 サーバーの EAP6_HOME/modules/system/layers/base/org/jboss/netty/ フォルダーをコピーします。
      • このモジュールにパッチを適用した場合は、JBoss EAP 6.4 サーバーの 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.7.3.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/

注記

大型のメッセージがない場合や、ページングが無効になっている場合は、 messaginglargemessages/ および messagingpaging/ ディレクトリーが存在しないことがあります。

4.7.4. 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.7.5. メッセージングインターセプターの移行

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>

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

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

4.8. 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.9. threads サブシステム設定の移行

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

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

infinispan サブシステムのスレッドプールを設定する方法は、 JBoss EAP Configuration GuideConfigure Infinispan Thread Pools を参照してください。

jgroups サブシステムのスレッドプールを設定する方法は、JBoss EAP Configuration GuideConfigure JGroups Thread Pools を参照してください。

JBoss EAP 6 では、threads サブシステムに定義された executorを参照して web サブシステムのコネクターおよびリスナーのスレッドプールを設定しました。JBoss EAP 7 では、io サブシステムに定義された worker を参照して undertow サブシステムのスレッドプールを設定します。詳細は、JBoss EAP Configuration GuideConfiguring the IO Subsystem を参照してください。

remoting サブシステムのスレッドプール設定の変更に関する詳細は、本ガイドの Remoting サブシステム設定の移行 と、JBoss EAP Configuration GuideConfiguring the Endpoint を参照してください。

4.10. 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 を参照するエンドポイント設定に置き換えられました。

エンドポイントの設定方法については、JBoss EAP Configuration GuideConfiguring the Endpoint を参照してください。

4.11. 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.12. シングルサインオンサーバーの変更

JBoss EAP 7 でも、Infinispan サブシステムによって HA サービスの分散キャッシングサポートが Infinispan キャッシュの形式で提供されます。しかし、認証情報のキャッシングおよび分散の処理方法はこれまでのリリースとは異なります。

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.13. データソース設定の変更

4.13.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.14. セキュリティーサーバー設定の変更

Java Security Manager のサーバー設定の変更に関する詳細は、JBoss EAP How To Configure Server SecurityConsiderations Moving from Previous Versions を参照してください。

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

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

削除されたトランザクションサブシステム属性

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

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

パス

object-store-path

relative-to

object-store-relative-to

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

JBoss EAP 6 の transactions サブシステムで使用できた以下の属性は、JBoss EAP 7 では非推奨となりました。非推奨となった属性は将来のリリースで削除される可能性があります。以下の表はそれらの代替となる同等の属性を示しています。

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.16. mod_cluster 設定の変更

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

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

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

この変更は、mod_cluster のアドバタイズを無効にするときなど、静的プロキシーリストを定義する方法に影響します。mod_cluster のアドバタイズを無効化する方法の詳細は、JBoss EAP Configuration GuideDisable Advertising for mod_cluster を参照してください。

mod_cluster 属性の詳細は、 JBoss EAP Configuration Guidemod_cluster Subsystem Attributes を参照してください。


このページには機械翻訳が使用されている場合があります (詳細はこちら)。