第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 設定ファイルの jacorb
、messaging
、および 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 では、jacorb
、messaging
、および web
サブシステムを以前のリリースから新しい設定へ自動的に更新する migrate
操作を実行できます。また、 jacorb
、messaging
、および web
サブシステムに describe-migration
操作を実行すると、移行を行う前に提案された移行設定の変更を確認することもできます。cmp
、jaxr
、および 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 のサーバー設定を更新します。
- 移行を始める前に、重要データのバックアップおよびサーバー状態の確認の内容を見直してください。ここには、サーバーを良好な状態にし、適切なファイルをバックアップするための重要な情報が記載されています。
JBoss EAP 6 の設定で JBoss EAP 7 のサーバーを起動します。
- JBoss EAP 7 サーバー設定ファイルをバックアップします。
以前のリリースの設定ファイルを JBoss EAP 7 ディレクトリーにコピーします。
$ cp EAP6_HOME/standalone/configuration/standalone-full.xml EAP7_HOME/standalone/configuration
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.
新しいターミナルを開いて、JBoss EAP 7 のインストールディレクトリーへ移動し、
--controller=remote://localhost:9999
引数を使用して管理 CLI を開始します。$ bin/jboss-cli.sh --connect --controller=remote://localhost:9999
jacorb
、messaging
、およびweb
サブシステムを移行します。移行を行う前にサブシステムに追加した設定変更を確認するには、
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")] } ] } }
migrate
操作を実行し、サブシステムの設定を JBoss EAP 7 の代替サブシステムに移行します。この操作では以下の構文を使用します。/subsystem=SUBSYSTEM_NAME:migrate
注記messaging
サブシステムのdescribe-migration
およびmigrate
操作を使用すると、引数を渡してレガシークライアントによるアクセスを設定することができます。コマンド構文の詳細は、Messaging サブシステムの移行および前方互換性を参照してください。このコマンドの結果を確認します。必ず、操作が正常に完了し、"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
警告のリストは、本ガイドの最後にあるリファレンス資料 に記載されています。- サーバー設定ファイルを確認し、拡張、サブシステム、および名前空間が更新され、既存のサブシステム設定が JBoss EAP 7 に移行されたことを確認します。
注記この手順は、以下のコマンドを使用して
jacorb
、messaging
、およびweb
の各サブシステムに対して繰り返す必要があります。/subsystem=jacorb:migrate /subsystem=messaging:migrate /subsystem=web:migrate
cmp
、jaxr
、およびthreads
サブシステムおよび拡張をサーバー設定から削除します。管理 CLI プロンプトで以下のコマンドを実行し、廃止された
cmp
、jaxr
、および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
サーバーを再起動する前に messaging
、jacorb
、および web
サブシステムを移行し、cmp
、jaxr
、および threads
拡張およびサブシステムを削除する必要があります。この作業の完了前にサーバーを再起動する必要がある場合は、サーバー起動のコマンドラインで --admin-only
引数を使用するようにしてください。これにより、サーバーの変更を継続できます。
4.3. ロギングメッセージの接頭辞の変更
ログメッセージには、メッセージを報告するサブシステムのプロジェクトコードが接頭辞として付けられます。JBoss EAP 7 では、すべてのログメッセージの接頭辞が変更になりました。
JBoss EAP 7 で使用されるログメッセージの新しいプロジェクトコード接頭辞の完全リストは、JBoss EAP Development Guide の Project 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 Guide の Configuring 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 Guide の Configuring Handlers を参照してください。
フィルターを設定する方法については、JBoss EAP 7 Configuration Guide の Configuring 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>
- ログエントリーを保存するデータベースのドライバーモジュールを作成します。
データベースのデータソースを設定し、ドライバーを
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>
式
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 Guide の Cluster Communication with JGroups を参照してください。
4.6. Infinispan サーバー設定の変更
4.6.1. Infinispan のデフォルトキャッシュ設定の変更
JBoss EAP 6 では、Web セッションレプリケーションおよび EJB レプリケーションのデフォルトのクラスター化キャッシュは ASYNC
キャッシュでレプリケートされましたが、これが JBoss EAP 7 では変更になりました。レプリケートされたキャッシュはデフォルトでは設定されません。レプリケートされたキャッシュの追加方法とレプリケートされたキャッシュをデフォルトにする方法はについては、JBoss EAP Configuration Guide の Configure 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-entries
が true
に設定されていると、messaging-activemq
サブシステムが legacy-connection-factory
リソースを作成し、legacy-entries
を jms-queue
および jms-topic
リソースに追加します。
ブール値の引数 add-legacy-entries
が false
に設定されていると、messaging-activemq
サブシステムにはレガシーリソースが作成されず、レガシー JMS クライアントは JBoss EAP 7 サーバーと通信できません。これがデフォルト値になります。
前方互換性および後方互換性に関する詳細は、JBoss EAP Configuring Messaging の Backward and Forward Compatibility を参照してください。
管理 CLI の migrate
および describe-migration
操作の詳細は、管理 CLI の移行操作を参照してください。
Messaging サブシステムの XML 設定
新しい messaging-activemq
サブシステムによって、他の JBoss EAP サブシステムとより一貫性のある XML スキームが提供されるようになり、XMLの設定は大幅に変更されました。
新しい messaging-activemq
サブシステムに準拠するために JBoss EAP messaging
サブシステムの XML 設定を変更しないでください。この代わりに、レガシーサブシステムの migrate
操作を呼び出してください。この操作は、実行の一部として新しい messaging-activemq の XML 設定を書き込みます。
4.7.2. メッセージングログの変更
messaging
サブシステムのログメッセージに付けられる接頭辞が JBAS から WFLYMSGAMQ に変更になりました。JBoss EAP 7 で使用されるログメッセージの新しいプロジェクトコード接頭辞の完全リストは、JBoss EAP Development Guide の Project Codes Used in JBoss EAP を参照してください。
4.7.3. メッセージングデータの移行
JMS サポートプロバイダーが HornetQ から ActiveMQ Artemis に変更になったため、JBoss EAP 7 ではメッセージングデータの形式と場所が変更になりました。
以下の 2 つの方法のいずれかを使用してデータを移行できます。
- 管理 CLI の
import-journal
操作を使用すると、以前のリリースから HornetQ のメッセージングデータをエクスポートし、インポートすることができます。詳細は、エクスポートおよびインポートを使用したメッセージングデータの移行を参照してください。 - JMS ブリッジを設定すると、以前のリリースからデータを移行できます。この手順は、JMS ブリッジを使用したメッセージングデータの移行に記載されています。
リリース間で行われたメッセージングデータフォルダー名の変更についての詳細は、メッセージングフォルダー名のマッピングを参照してください。
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/
ディレクトリー内に作成します。
以下の手順に従い、データをエクスポートします。
- JBoss EAP 6 サーバーを停止します。
- 上記の説明にあるようにカスタムモジュールを作成します。
以下のコマンドを実行してデータをエクスポートします。
$ 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
- コマンド完了後に、ログにエラーや警告メッセージがないことを確認します。
- 使用中のオペレーティングシステムで利用可能なツールを使用して、生成された出力ファイルの 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 サーバーの設定
- JBoss EAP 6 サーバーを停止します。
HornetQ のジャーナルおよび設定ファイルをバックアップします。
- デフォルトでは、HornetQ ジャーナルは
EAP6_HOME/standalone/data/
ディレクトリーにあります。 - 各リリースにおけるメッセージングフォルダーのデフォルトの場所は、メッセージングフォルダー名のマッピングを参照してください。
- デフォルトでは、HornetQ ジャーナルは
- JMS メッセージが含まれる
InQueue
JMS キューが JBoss EAP 6 サーバーで定義されていることを確認してください。 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 サーバーの設定
以前のリリースでは、JMS ブリッジ設定が HornetQ サーバーに接続するには、
org.hornetq
モジュールが必要です。このモジュールと直接の依存関係は JBoss EAP 7 では存在しないため、以前のリリースから以下のモジュールをコピーする必要があります。org.hornetq
モジュールを JBoss EAP 7EAP_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"/>
- このモジュールにパッチを適用していない場合は、JBoss EAP 6.4 サーバーの
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
フォルダーをコピーします。
- このモジュールにパッチを適用していない場合は、JBoss EAP 6.4 サーバーの
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"/>
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])
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>
- また、セキュリティーが JBoss EAP 6 に設定されている場合、接続の作成時に JNDI ルックアップで使用される正しいユーザー名およびパスワードを指定する
source-context
が含まれるよう、JMS ブリッジ設定<source>
要素を設定する必要もあります。
データの移行
以下の設定に提供する情報が正しいことを確認します。
- キューおよびトピック名
- JUDI ルックアップの java.naming.provider.url
- ターゲットの JMS 宛先が JBoss EAP 7 サーバーにデプロイされているようにしてください。
- 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 削除する属性
要素 | サポートされない属性 |
---|---|
|
|
|
|
以下の on/off
属性はサポート対象外となり、管理 CLI の migrate
操作を実行しても移行されません。これらの属性が on
に設定されていると移行の警告が表示されます。<security support-ssl="on|off">
などの、この表に記載されていない on/off
属性のサポートは継続され、正常に移行されます。唯一の違いは、値が on/off
から true/false
に変更されることです。
表4.5 off に設定するまたは削除する属性
要素 | off に設定する属性 |
---|---|
|
|
| (
|
|
|
4.9. threads サブシステム設定の移行
JBoss EAP 6 のサーバー設定には、サーバーの異なるサブシステムにまたがってスレッドプールを管理するために使用される threads
が含まれていました。
threads
サブシステムは JBoss EAP 7 では利用できないようになりました。この代わりに、各サブシステムが独自のスレッドプールを管理します。
infinispan
サブシステムのスレッドプールを設定する方法は、 JBoss EAP Configuration Guide の Configure Infinispan Thread Pools を参照してください。
jgroups
サブシステムのスレッドプールを設定する方法は、JBoss EAP Configuration Guide の Configure JGroups Thread Pools を参照してください。
JBoss EAP 6 では、threads
サブシステムに定義された executor
を参照して web
サブシステムのコネクターおよびリスナーのスレッドプールを設定しました。JBoss EAP 7 では、io
サブシステムに定義された worker
を参照して undertow
サブシステムのスレッドプールを設定します。詳細は、JBoss EAP Configuration Guide の Configuring the IO Subsystem を参照してください。
remoting
サブシステムのスレッドプール設定の変更に関する詳細は、本ガイドの Remoting サブシステム設定の移行 と、JBoss EAP Configuration Guide の Configuring 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 Guide の Configuring 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 の以前のリリースと現行リリースにおけるドライバー名の指定方法の違いが示されています。
mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1
mysql-connector-java-5.1.31-bin.jar_com.mysql.jdbc.Driver_5_1
4.14. セキュリティーサーバー設定の変更
Java Security Manager のサーバー設定の変更に関する詳細は、JBoss EAP How To Configure Server Security の Considerations 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 Guide の Disable Advertising for mod_cluster を参照してください。
mod_cluster 属性の詳細は、 JBoss EAP Configuration Guide の mod_cluster Subsystem Attributes を参照してください。
Comments