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 設定ファイルの jacorb、messaging、および web サブシステムを更新すると、新しいリリースで実行できるようにすることができますが、完全な JBoss EAP 7 の設定にはならないことに注意してください。例を以下に示します。
-
この操作は、元の
remoteプロトコルおよびポート設定を JBoss EAP 7 で使用される新しいhttp-remotingおよびポート設定に更新しません。 - 設定には、新しい JBoss EAP サブシステム、クラスター化されたシングルトンデプロイメントなどの機能、正常シャットダウンが含まれません。
- 設定には、バッチ処理などの新しい Java EE 7 の機能が含まれません。
-
The
migrateoperation does not migrate theejb3subsystem 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 では、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 |
Start the Server and the Management CLI
以下の手順に従って、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
Migrate the JacORB, Messaging, and Web Subsystems
移行を行う前にサブシステムに追加した設定変更を確認するには、
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 では、すべてのログメッセージの接頭辞が変更になりました。
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>- ログエントリーを保存するデータベースのドライバーモジュールを作成します。
データベースのデータソースを設定し、ドライバーを
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 チャネル設定を追加、削除、および変更できます。
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.
- Follow the instructions to Start the Server and the Management CLI.
Issue the following commands to reconfigure caching in the
ejb3subsystem./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-entries が true に設定されていると、messaging-activemq サブシステムが legacy-connection-factory リソースを作成し、legacy-entries を jms-queue および jms-topic リソースに追加します。
ブール値の引数 add-legacy-entries が false に設定されていると、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 つの方法のいずれかを使用してデータを移行できます。
-
管理 CLI の
import-journal操作を使用すると、以前のリリースから HornetQ のメッセージングデータをエクスポートし、インポートすることができます。詳細は、エクスポートおよびインポートを使用したメッセージングデータの移行を参照してください。 - JMS ブリッジを設定すると、以前のリリースからデータを移行できます。この手順は、JMS ブリッジを使用したメッセージングデータの移行に記載されています。
リリース間で行われたメッセージングデータフォルダー名の変更についての詳細は、メッセージングフォルダー名のマッピングを参照してください。
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/ ディレクトリー内に作成します。
以下の手順に従い、データをエクスポートします。
- JBoss EAP 6 サーバーを停止します。
- 上記の説明にあるようにカスタムモジュールを作成します。
以下のコマンドを実行してデータをエクスポートします。
$ 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
- コマンド完了後に、ログにエラーや警告メッセージがないことを確認します。
- 使用中のオペレーティングシステムで利用可能なツールを使用して、生成された出力ファイルの 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 サーバーの設定
- JBoss EAP 6 サーバーを停止します。
HornetQ のジャーナルおよび設定ファイルをバックアップします。
-
デフォルトでは、HornetQ ジャーナルは
EAP6_HOME/standalone/data/ディレクトリーにあります。 - 各リリースにおけるメッセージングフォルダーのデフォルトの場所は、メッセージングフォルダー名のマッピングを参照してください。
-
デフォルトでは、HornetQ ジャーナルは
-
JMS メッセージが含まれる
InQueueJMS キューが 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/ディレクトリーにコピーします。-
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/
-
If you did not apply patches to this module, copy this folder from the JBoss EAP 6.4 server:
Remove the
<resource-root>for the HornetQlibpath from the JBoss EAP 7EAP_HOME/modules/org/hornetq/main/module.xmlfile.If you did not apply patches to the JBoss EAP 6.4
org.hornetqmodule, remove the following line from the file:<resource-root path="lib"/>
If you did apply patches to the JBoss EAP 6.4
org.hornetqmodule, remove the following lines from the file:<resource-root path="lib"/> <resource-root path="../../../../../org/hornetq/main/lib"/>
警告Failure to remove the HornetQ
libpathresource-rootwill 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.nettymodule into the JBoss EAP 7EAP_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
-
If you did not apply patches to this module, copy this folder from the JBoss EAP 6.4 server:
JBoss EAP 6 サーバーから受信したメッセージを格納するために JSM キューを作成します。以下は、
MigratedMessagesQueueJMS キューを作成してメッセージを受信する管理 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サーバーに以下と似たInVmConnectionFactoryconnection-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 サーバーで設定された
InQueueJMS キューからメッセージを読み取る 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.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.
Connect to the JConsole using the following command.
EAP_HOME/bin/jconsole.sh- Connect to JBoss EAP local process. Note that it should start with "jboss-modules.jar".
- In the MBeans tab, choose jboss.as → messaging-activemq → default → Operations 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 削除する属性
| 要素 | サポートされない属性 |
|---|---|
|
|
|
|
|
|
以下の on/off 属性はサポート対象外となり、管理 CLI の migrate 操作を実行しても移行されません。これらの属性が on に設定されていると移行の警告が表示されます。<security support-ssl="on|off"> などの、この表に記載されていない on/off 属性のサポートは継続され、正常に移行されます。唯一の違いは、値が on/off から true/false に変更されることです。
表4.5 off に設定するまたは削除する属性
| 要素 | off に設定する属性 |
|---|---|
|
|
|
|
|
(
|
|
|
|
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.