Red Hat Training

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

管理および設定ガイド

JBoss Enterprise Application Platform 6.4

Red Hat JBoss Enterprise Application Platform 6 向け

Red Hat Customer Content Services

概要

本書は、Red Hat JBoss Enterprise Application Platform 6 およびそのパッチリリースに関する管理および設定ガイドです。

第1章 はじめに

1.1. Red Hat JBoss Enterprise Application Platform 6

Red Hat JBoss Enterprise Application Platform 6 (JBoss EAP 6) は、オープンな標準に基いて構築され、Java Enterprise Edition 6 の仕様に準拠するミドルウェアプラットフォームです。高可用性クラスタリング、メッセージング、分散キャッシングなどの技術が JBoss Application Server 7 と統合されます。
JBoss EAP 6 には、必要な場合にだけサービスを有効にできる新しいモジュール構造が含まれます (サービスの起動時間が短縮されます)。
管理コンソールと管理コマンドラインインターフェースにより、XML 設定ファイルの編集が不必要になり、タスクをスクリプト化および自動化する機能が追加されました。
また、JBoss EAP 6 には、セキュアでスケーラブルな Java EE アプリケーションの迅速な開発を可能にする API と開発フレームワークが含まれます。

1.2. JBoss EAP 6 の機能

表1.1 JBoss EAP 6 の機能

機能 説明
Java 証明書 認定された Java Enterprise Edition 6 の Full Profile と Web Profile。
管理対象ドメイン
  • 複数のサーバーインスタンスおよび物理ホストを一元管理し、スタンドアロンサーバーで単一のサーバーインスタンスを使用することを可能にします。
  • 設定、デプロイメント、ソケットバインディング、モジュール、拡張機能、およびシステムプロパティーをサーバーグループごとに管理します。
  • アプリケーションのセキュリティー (セキュリティードメインを含む) の管理を一元化および簡略化します。
管理コンソールおよび管理 CLI 新しいドメインまたはスタンドアロンサーバー管理インターフェース。XML 設定ファイルの編集は必要なくなりました。管理 CLI には、管理タスクをスクリプト化および自動化できるバッチモードも含まれます。
単純化されたディレクトリーレイアウト modules ディレクトリーにはすべてのアプリケーションサーバーモジュールが含まれるようになりました。共通でサーバー固有の lib ディレクトリーは廃止されました。domain ディレクトリーと standalone ディレクトリーには、それぞれドメインデプロイメント用のアーティファクトおよび設定ファイルと、スタンドアロンデプロイメント用のアーティファクトおよび設定ファイルが含まれます。
モジュラークラスローディングメカニズム モジュールはオンデマンドでロードおよびアンロードされます。これにより、パフォーマンスが向上し、セキュリティーの利点が提供され、起動および再起動の時間が短縮されます。
簡略化されたデータソース管理 データベースドライバーは他のサービスと同様にデプロイされます。また、データソースは、管理コンソールまたは管理 CLI で直接作成および管理されます。
リソースの使用の削減と効率化 JBoss EAP 6 はより少ないシステムリソースを使用し、以前のバージョンよりも効率的に使用します。その他の利点として、JBoss EAP 6 では JBoss EAP 5 よりも起動および停止時間が短縮されます。

1.3. JBoss EAP 6 の操作モード

JBoss EAP 6 は、JBoss EAP 6 インスタンスに対してスタンドアローンサーバーと管理対象ドメインの 2 つの操作モードを提供します。
2 つのモードはサーバーの管理方法が異なりますが、エンドユーザーの要求に対応する能力は変わりません。高可用性 (HA) クラスターの機能はどちらのモードからでも利用できることに注意してください。複数のスタンドアロンサーバーを設定して、HA クラスターを構築できます。

1.4. スタンドアロンサーバー

スタンドアロンサーバーモードは独立したプロセスで、以前のバージョンの JBoss EAP で唯一存在した実行モードと似ています。
スタンドアロンサーバーとして実行する JBoss EAP のインスタンスは単一インスタンスのみですが、オプションとしてクラスター化された設定で実行することも可能です。

1.5. 管理対象ドメイン

管理対象ドメイン操作モードでは、単一の制御点から複数の JBoss EAP 6 インスタンスを管理できます。
一元管理された複数の JBoss EAP 6 サーバーは、ドメインのメンバーと呼ばれます。ドメインの JBoss EAP 6 インスタンスは共通の管理ポリシーを共有します。
各ドメインは 1 つのドメインコントローラー、1 つ以上のホストコントローラー、およびホスト毎に 0 個以上のサーバーグループによって構成されます。
ドメインコントローラーは、ドメインが制御される中心点であり、各サーバーはドメインの管理ポリシーに従って設定されます。ドメインコントローラーはホストコントローラーとしても機能します。
ホストコントローラーは、domain.sh または domain.bat スクリプトが実行される物理または仮想ホストです。ホストコントローラーは、ドメイン管理タスクをドメインコントローラーへ委譲するために設定されます。
各ホスト上のホストコントローラーはドメインコントローラーと対話して、ホスト上で実行されているアプリケーションサーバーインスタンスのライフサイクルを制御し、ドメインコントローラーがこれらのインスタンスを管理できるようにします。各ホストに複数のサーバーグループが含まれるようにすることが可能です。
サーバーグループは、JBoss EAP がインストールされているサーバーインスタンスのセットで、すべてが 1 つとして管理および設定されます。ドメインコントローラーはサーバーグループにデプロイされたアプリケーションの設定を管理します。そのため、サーバーグループの各サーバーは同じ設定とデプロイメントを共有します。
同じ物理システム上の同じ JBoss EAP 6 インスタンス内で、単一のドメインコントローラー、単一のホストコントローラー、および複数のサーバーを実行できます。
ホストコントローラーは特定の物理 (または仮想) ホストに割り当てられます。異なる設定を使用する場合は、同じハードウェア上で複数のホストコントローラーを実行でき、ポートとその他のリソースが競合しないようにします。
A managed domain with one domain controller, three host controllers, and three server groups. Servers are members of server groups, and may be located on any of the host controllers in the domain.

図1.1 管理対象ドメインを表す図

1.6. ドメインコントローラー

ドメインコントローラーは、ドメインの集中管理点として動作する JBoss EAP 6 サーバーインスタンスです。1 つのホストコントローラーインスタンスがドメインコントローラーとして動作するよう設定されます。
ドメインコントローラーの主な役割は次のとおりです。
  • ドメインの集中管理ポリシーを維持する。
  • すべてのホストコントローラーが現在のコンテンツを認識するようにする。
  • 実行中のすべての JBoss EAP 6 インスタンスがこのポリシーに従って設定されるよう、ホストコントローラーをサポートする。
デフォルトでは、集中管理ポリシーは domain/configuration/domain.xml ファイルに格納されます。このファイルは、ドメインコントローラーのホストのファイルシステム上にある未展開の JBoss EAP 6 インストールファイル内にあります。
domain.xml ファイルは、ドメインコントローラーとして実行するよう設定されたホストコントローラーの domain/configuration/ ディレクトリーに存在する必要があります。このファイルは、ドメインコントローラーとして実行しないホストコントローラー上のインストールには必要ありませんが、このようなサーバー上に domain.xml ファイルがあっても問題はありません。
domain.xml ファイルには、あるドメインのサーバーインスタンス上で実行できるプロファイル設定が含まれています。プロファイル設定には、プロファイルを構成するさまざまなサブシステムの詳細設定が含まれます。また、ドメイン設定にはソケットのグループの定義やサーバーグループの定義も含まれます。

1.7. ドメインコントローラーの検索およびフェールオーバー

管理対象ドメインを設定するとき、ドメインコントローラーに接続するために必要な情報を使用して各ホストコントローラーを設定する必要があります。JBoss EAP 6 では、ドメインコントローラーを検索する複数のオプションを使用して各ホストコントローラーを設定できます。ホストコントローラーは、適切なオプションが見つかるまでオプションのリストを繰り返し処理します。
これにより、バックアップドメインコントローラーのコンタクト情報を用いてホストコントローラーを事前設定できます。プライマリードメインコントローラーに問題がある場合は、バックアップホストコントローラーをマスターに昇格でき、昇格後にホストコントローラーを新しいマスターへ自動的にフェールオーバーできます。
以下は、ドメインコントローラー検索の複数のオプションを持つホストコントローラーを設定する方法の例になります。

例1.1 複数のドメインコントローラーオプションで設定したホストコントローラー

<domain-controller>  
    <remote security-realm="ManagementRealm">  
          <discovery-options>  
              <static-discovery name="primary" host="172.16.81.100" port="9999"/>  
              <static-discovery name="backup" host="172.16.81.101" port="9999"/>  
          </discovery-options>  
    </remote>  
</domain-controller>
静的検出オプションには、以下の必須属性が含まれます。

name
このドメインコントローラー検索オプションの名前。
host
リモートドメインコントローラーのホスト名。
port
リモートドメインコントローラーのポート。
上記の例では、最初の検索オプションが指定されることが予想されます。2 つ目のオプションはフェールオーバーの状況で使用される可能性があります。
プライマリードメインコントローラーで問題が発生した場合、--backup オプションで開始されたホストコントローラーをドメインコントローラーとして動作するよう昇格できます。

注記

--backup オプションでホストコントローラーを開始すると、コントローラーによってドメイン設定のローカルコピーが維持されます。この設定は、ホストコントローラーがドメインコントローラーとして動作するよう再設定された場合に使用されます。

手順1.1 ホストコントローラーを昇格してドメインコントローラーにする

  1. 元のドメインコントローラーが停止した状態であることを確認します。
  2. 管理 CLI を使用して、新しいドメインコントローラーとなるホストコントローラーへ接続します。
  3. 以下のコマンドを実行してホストコントローラーを設定し、新しいドメインコントローラーとして動作するようにします。
    /host=HOST_NAME:write-local-domain-controller
  4. 以下のコマンドを実行し、ホストコントローラーをリロードします。
    reload --host=HOST_NAME
2. で選択したホストコントローラーがドメインコントローラーとして動作するようになります。

1.8. ホストコントローラー

ホストコントローラーは、domain.sh または domain.bat スクリプトがホスト上で実行されると起動します。
ホストコントローラーの主な役割はサーバーを管理することです。ドメイン管理タスクを委譲し、ホスト上で実行される個別のアプリケーションサーバープロセスを開始および停止します。
ホストコントローラーはドメインコントローラーと対話し、サーバーとドメインコントローラー間の通信を管理できるようにします。ドメインの複数のホストコントローラーは 1 つのドメインコントローラーのみと対話できます。そのため、単一のドメインモード上で実行されるホストコントローラーおよびサーバーインスタンスはすべて単一のドメインコントローラーを持ち、同じドメインに属する必要があります。
デフォルトでは、各ホストコントローラーは domain/configuration/host.xml ファイルから設定を読み取ります。このファイルは、ホストのファイルシステム上にある未展開の JBoss EAP 6 インストールファイルに存在します。host.xml ファイルには、特定のホストに固有する以下の設定情報が含まれています。
  • このインストールから実行される JBoss EAP 6 インスタンスの名前。
  • 次の設定のいずれか。
    • ホストコントローラーがドメインコントローラーへ通知して、ホストコントローラー自体を登録し、ドメイン設定へアクセスする方法。
    • リモートドメインコントローラーの検索および通知方法。
    • ホストコントローラーはドメインコントローラーとして動作する。
  • ローカルの物理インストールに固有する設定。たとえば、domain.xml に宣言された名前付きインターフェースの定義は host.xml にある実際のマシン固有の IP アドレスへマップできます。さらに、domain.xml の抽象パス名を host.xml のファイルシステムパスへマップできます。

1.9. サーバーグループ

サーバーグループとは、1 つのグループとして管理および設定される複数のサーバーインスタンスのことです。管理対象ドメインでは、各アプリケーションサーバーインスタンスは唯一のメンバーである場合でも 1 つのサーバーグループに属します。グループのサーバーインスタンスは同じプロファイル設定とデプロイされた内容を共有します。
ドメインコントローラーとホストコントローラーは、ドメインにある各サーバーグループのすべてのインスタンスに標準設定を強制します。
ドメインは複数のサーバーグループで構成されます。異なるサーバーグループを異なるプロファイルやデプロイメントで設定できます。たとえば、ドメインは異なるサービスを提供する異なるサーバー層で設定できます。
異なるサーバーグループが同じプロファイルやデプロイメントを持つこともできます。これにより、最初のサーバーグループでアプリケーションがアップグレードされた後に 2 つ目のサーバーグループでアプリケーションがアップデートされるアプリケーションのローリングアップグレードが可能になり、サービスの完全停止を防ぎます。
以下はサーバーグループ定義の例になります。

例1.2 サーバーグループ定義

<server-group name="main-server-group" profile="default">
 <socket-binding-group ref="standard-sockets"/>
  <deployments>
   <deployment name="foo.war_v1" runtime-name="foo.war"/>
   <deployment name="bar.ear" runtime-name="bar.ear"/>
  </deployments>
</server-group>
サーバーグループに含まれる必須の属性は次のとおりです。
  • name: サーバーグループの名前。
  • profile: サーバーグループのプロファイル名。
  • socket-binding-group: グループのサーバーに対して使用されるデフォルトのソケットバインディンググループ。この名前は host.xml でサーバーごとに上書きできます。しかし、すべてのサーバーグループの必須要素であるため、この要素がないとドメインが起動できません。
サーバーグループに含まれる任意の属性は次のとおりです。
  • deployments: グループのサーバー上にデプロイするデプロイメントコンテンツ。
  • system-properties: グループのサーバーに設定するシステムプロパティー。
  • jvm: グループの全サーバーに対するデフォルトの JVM 設定。ホストコントローラーはこれらの設定を host.xml の他の設定とマージし、サーバーの JVM を開始するために使用される設定を作成します。
  • socket-binding-port-offset: ソケットバインディンググループにより提供されたポート値に追加するデフォルトオフセット。
  • management-subsystem-endpoint: リモートサブシステムからエンドポイントを使用してサーバーグループに属するサーバーを再びホストコントローラに接続するために true に設定されます (動作するにはリモートサブシステムが必要です)。

1.10. JBoss EAP 6 プロファイル

以前のバージョンの JBoss EAP で使用されたプロファイルのコンセプトは使用されないようになりました。JBoss EAP 6 では、設定に関するすべての情報を保持する少数の設定ファイルが使用されるようになりました。
モジュールとドライバーは必要に応じてロードされるようになりました。そのため、サーバーを効率的に起動するために以前のバージョンの JBoss EAP 6 で使用されたデフォルトプロファイルの概念は適用されません。
デプロイメント時に、サーバーまたはドメインコントローラーによってモジュールの依存性が決定、順番付け、および解決され、正しい順番でロードされます。モジュールはデプロイメントで必要がなくなったときにアンロードされます。
設定からサブシステムを削除すると、手作業でモジュールを無効にしたり、ドライバーまたは他のサービスをアンロードしたりできますが、ほとんどの場合でこの作業は必要ありません。モジュールを使用するアプリケーションがない場合、モジュールはロードされません。

第2章 アプリケーションサーバー管理

2.1. JBoss EAP ドキュメンテーション規則

本書で記述されたすべての EAP_HOME は、JBoss EAP ルートインストールディレクトリーを示します。JBoss EAP ルートインストールディレクトリーは、使用したインストール方法によって異なります。

Zip インストール方法
EAP_HOME は、JBoss EAP ZIP ファイルが解凍されたディレクトリーを示します。
GUI または CLI インストール方法
EAP_HOME は、JBoss EAP をインストールするために選択したディレクトリーを示します。
RPM インストール方法
EAP_HOME は、ディレクトリー /usr/share/jbossas を示します。

注記

EWS_HOME という表記は、上述した JBoss EAP の規則と同じ規則に基いて JBoss EWS インストールの場所を示すために使用されます。

2.2. JBoss EAP 6 の起動および停止

2.2.2. JBoss EAP 6 をスタンドアロンサーバーとして起動

概要

ここでは、JBoss EAP 6 をスタンドアロンサーバーとして起動する手順を説明します。

手順2.1 プラットフォームサービスをスタンドアロンサーバーとして起動

  1. Red Hat Enterprise Linux の場合

    次のコマンドを実行します: EAP_HOME/bin/standalone.sh
  2. Microsoft Windows Server の場合

    次のコマンドを実行します: EAP_HOME\bin\standalone.bat
  3. 他のパラメーターを指定する (任意)

    起動スクリプトに渡すことができる他のパラメーターの一覧を出力するには、-h パラメーターを使います。
結果

JBoss EAP 6 スタンドアロンサーバーインスタンスが起動します。

2.2.3. JBoss EAP 6 を管理対象ドメインとして起動

操作の順序

ドメイン内のサーバーグループのスレーブサーバーを起動する前にドメインコントローラーを起動する必要があります。最初に、この手順をドメインコントローラーで使用した後に、関連するホストコントローラーおよびドメインに関連する他のホストに対して使用してください。

手順2.2 プラットフォームサービスを管理対象ドメインとして起動

  1. Red Hat Enterprise Linux の場合

    次のコマンドを実行します: EAP_HOME/bin/domain.sh
  2. Microsoft Windows Server の場合

    次のコマンドを実行します: EAP_HOME\bin\domain.bat
  3. 他のパラメーターを起動スクリプトに渡す (任意)

    起動スクリプトに渡すことができる各種パラメーターを確認するには、-h パラメーターを使います。
結果

JBoss EAP 6 管理対象ドメインインスタンスが起動します。

2.2.4. 管理対象ドメインのホストの名前設定

概要

管理対象ドメインで実行されている各ホストには一意な名前を付ける必要があります。管理を容易にし、複数のホストで同じホスト設定ファイルを使用できるようにするために、以下の優先順位を用いてホスト名が決定されます。

  1. host.xml 設定ファイルにある host 要素の name 属性 (設定されている場合)。
  2. jboss.host.name システムプロパティーの値。
  3. jboss.qualified.host.name システムプロパティーの最後のピリオド (.) の後に続く値、または最後のピリオドがない場合は全体の値。
  4. POSIX ベースのオペレーティングシステムでは、HOSTNAME 環境変数のピリオド (.) の後に続く値。Microsoft Windows では COMPUTERNAME 環境変数のピリオドの後に続く値。最後のピリオドがない場合は、全体の値。

環境変数の設定方法は、ご使用のオペレーティングシステムのドキュメントを参照してください。システムプロパティーの設定方法は、「管理 CLI を使用したシステムプロパティーの設定」を参照してください。
本トピックでは、システムプロパティーまたはハードコードされた名前を使用して、設定ファイルのホストの名前を設定する方法について説明します。

手順2.3 システムプロパティーを用いたホスト名の設定

  1. 編集するホスト設定ファイル (例: host.xml) を開きます。
  2. ファイルにある host 要素を見つけます。以下に例を示します。
    <host name="master" xmlns="urn:jboss:domain:1.6">
  3. この要素が存在する場合は、name="HOST_NAME" 属性宣言を削除します。削除後、host 要素は以下のようになるはずです。
    <host xmlns="urn:jboss:domain:1.6">
  4. 以下の例のように、-Djboss.host.name 引数を渡してサーバーを起動します。
    -Djboss.host.name=HOST_NAME

手順2.4 特定の名前を用いたホスト名の設定

  1. 以下の構文を使用して、JBoss EAP スレーブホストを起動します。
    bin/domain.sh --host-config=HOST_FILE_NAME
    例:
    bin/domain.sh --host-config=host-slave01.xml
  2. 管理 CLI を起動します。
  3. 以下の構文を使用してホスト名を置き換えます。
    /host=EXISTING_HOST_NAME:write-attribute(name="name",value=UNIQUE_HOST_NAME)
    例:
    /host=master:write-attribute(name="name",value="host-slave01")
    次の結果が表示されるはずです。
     "outcome" => "success"
    これは、host-slave01.xml ファイルのホスト name 属性を以下のように変更します。
    <host name="host-slave01" xmlns="urn:jboss:domain:1.6">
  4. この処理を完了するには、変更前のホスト名を使用してサーバー設定をリロードする必要があります。
    reload --host=EXISTING_HOST_NAME
    例:
    reload --host=master

2.2.5. 2 台のマシンでの管理対象ドメインの作成

注記

この例の実行には、ファイアウォールの設定が必要になることがあります。
1 台のマシンがドメインコントローラーで、別のマシンがホストである 2 台のマシンで、管理対象ドメインを作成できます。詳細については、「ドメインコントローラー」を参照してください。
  • IP1 = ドメインコントローラーの IP アドレス (マシン 1)
  • IP2 = ホストの IP アドレス (マシン 2)

手順2.5 2 台のマシンで管理対象ドメインを作成

  1. マシン 1 での作業

    1. ホストがドメインコントローラーを認証できるようにするために、add-user.sh スクリプトを使用して管理ユーザー (例: slave01) を追加します。add-user 出力の SECRET_VALUE に注意してください。
    2. 専用のドメインコントローラー向けに事前設定された host-master.xml 設定ファイルでドメインを起動します。
    3. -bmanagement=$IP1 を使用して、他のマシンがドメインコントローラーを見えるようにします。
      [$JBOSS_HOME/bin]$ ./domain.sh --host-config=host-master.xml -bmanagement=$IP1
  2. マシン 2 での作業

    1. ユーザークレデンシャルを用いて $JBOSS_HOME/domain/configuration/host-slave.xml ファイルを更新します。
      	<?xml version='1.0' encoding='UTF-8'?>
              <host xmlns="urn:jboss:domain:1.6" name="slave01">   
              <!-- add user name here -->
               <management>
                  <security-realms>
                     <security-realm name="ManagementRealm">
                        <server-identities>
                          <secret value="$SECRET_VALUE" />   
                          <!-- use secret value from add-user.sh output-->
                        </server-identities> 
                        ...
    2. ホストを起動します。
      [$JBOSS_HOME/bin]$ ./domain.sh --host-config=host-slave.xml  -Djboss.domain.master.address=$IP1 -b=$IP2
  3. ドメインを管理します。

    CLI を使用する場合:
    [$JBOSS_HOME/bin]$ ./jboss-cli.sh -c --controller=$IP1
    
    Web コンソールを使用する場合:
    http://$IP1:9990
    
    サーバーのインデックスページへアクセスします。
    http://$IP2:8080/
    http://$IP2:8230/
    

2.2.6. 代替設定を用いた JBoss EAP 6 の起動

設定ファイルを指定しない場合、サーバーはデフォルトファイルで起動します。しかし、サーバーを起動してから設定を手動で指定することができます。この手順は管理対象ドメインとスタンドアロンサーバーのどちらを使用するか、またどのオペレーティングシステムを使用するかによって多少の違いがあります。

前提条件

  • 代替の設定ファイルを使用する前に、デフォルト設定をテンプレートとして使用して、代替の設定ファイルを作成します。管理対象ドメインの場合は、設定ファイルを EAP_HOME/domain/configuration/ ディレクトリーに置く必要があります。スタンドアロンサーバーの場合は、設定ファイルを EAP_HOME/standalone/configuration/ ディレクトリーに置く必要があります。

注記

EAP_HOME/docs/examples/configs/ ディレクトリーに複数の設定例が含まれています。これらの例を使用し、クラスタリングや Transaction XTS API などの追加機能を有効にします。
一部の設定例は、使用する前に変更する必要があります。standalone-picketlink.xmlstandalone-genericjms.xml、および standalone-hornetq-colocated.xml の設定ファイルを変更せずに使用するとエラーが発生します。

手順2.6 代替設定を用いたインスタンスの起動

  1. スタンドアロンサーバー

    スタンドアロンサーバーでは、--server-config パラメーターに設定ファイルのファイル名をオプションとして指定します。設定ファイルは EAP_HOME/standalone/configuration/ ディレクトリーに置く必要があり、このディレクトリーからの相対パスで設定ファイルを指定する必要があります。

    例2.1 Red Hat Enterprise Linux のスタンドアロンサーバーに別の設定ファイルを使用

    [user@host bin]$ ./standalone.sh --server-config=standalone-alternate.xml
    この例は、EAP_HOME/standalone/configuration/standalone-alternate.xml 設定ファイルを使用します。

    例2.2 Microsoft Windows Server のスタンドアロンサーバーに別の設定ファイルを使用

    C:\EAP_HOME\bin> standalone.bat --server-config=standalone-alternate.xml
    この例は、EAP_HOME\standalone\configuration\standalone-alternative.xml 設定ファイルを使用します。
  2. 管理対象ドメイン

    管理対象ドメインでは、設定ファイルのファイル名を --domain-config パラメーターのオプションとして指定します。設定ファイルは EAP_HOME/domain/configuration/ ディレクトリーに置く必要があり、このディレクトリーからの相対パスを指定する必要があります。

    例2.3 Red Hat Enterprise Linux の管理対象ドメインに別の設定ファイルを使用

    [user@host bin]$ ./domain.sh --domain-config=domain-alternate.xml
    この例は、EAP_HOME/domain/configuration/domain-alternate.xml 設定ファイルを使用します。

    例2.4 Microsoft Windows Server の管理対象ドメインに別の設定ファイルを使用

    C:\EAP_HOME\bin> domain.bat --domain-config=domain-alternate.xml
    
    
    この例は、EAP_HOME\domain\configuration\domain-alternate.xml 設定ファイルを使用します。
結果

代替の設定ファイルを使用して JBoss EAP が起動されます。

2.2.7. JBoss EAP 6 の停止

JBoss EAP 6 を停止する方法は、起動方法によって異なります。このタスクでは、対話的に起動されたインスタンスを停止し、サービスにより起動されたインスタンスを停止して、スクリプトによりバックグラウンドにフォークされたインスタンスを停止します。

注記

管理対象ドメインでサーバーまたはサーバーグループを停止する方法の詳細については、「管理コンソールを使用したサーバーの停止」を参照してください。管理 CLI を使用してサーバーを停止する方法の詳細については、「管理 CLI を使用したサーバーの起動および停止」を参照してください。
  • 手順2.7 JBoss EAP 6 のインスタンスの停止

    • コマンドラインプロンプトから対話的に起動したインスタンスの停止

      JBoss EAP 6 が実行されているターミナルで Ctrl-C を押します。
  • 手順2.8 オペレーティングシステムサービスとして起動されたインスタンスの停止

    オペレーティングシステムに応じて、以下のいずれかの手順を実行します。
      • Red Hat Enterprise Linux

        Red Hat Enterprise Linux でサービススクリプトを記述したときは、stop 機能を使用します。これは、スクリプトに記述する必要があります。次に、service scriptname stop を使用できます。ここで scriptname はスクリプトの名前に置き換えます。
      • Microsoft Windows Server

        Microsoft Windows の場合は、net service コマンドを使用するか、コントロールパネルの サービス アプレットからサービスを停止します。
  • 手順2.9 バックグラウンドで実行されているインスタンスの停止 (Red Hat Enterprise Linux)

    1. プロセスのプロセス ID (PID) を取得します。
      • 単一のインスタンスのみが実行されている場合 (スタンドアロンモード)

        以下のコマンドはいずれも JBoss EAP 6 の単一インスタンスの PID を返します。
        • pidof java
        • jps
          (jps コマンドは、jboss-modules.jarjps 自体の 2 つのプロセスに対する ID を返します。jboss-modules.jar の ID を使用して EAP インスタンスを停止します)。
      • 複数の EAP インスタンスが実行されている場合 (ドメインモード)

        複数の EAP インスタンスが実行されている場合、正しいプロセスを識別するには、さらに包括的なコマンドを使用する必要があります。
        • 詳細モードで jps コマンドを使用すると、見つかった java プロセスに関する詳細情報が提供されます。
          以下は、実行している EAP プロセスを PID およびロールで識別する、詳細な jps コマンドからの出力の一部になります。
          $ jps -v
          12155 jboss-modules.jar -D[Server:server-one] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1303m 
          ...
          
          12196 jboss-modules.jar -D[Server:server-two] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1303m 
          ...
          
          12096 jboss-modules.jar -D[Host Controller] -Xms64m -Xmx512m -XX:MaxPermSize=256m 
          ...
          
          11872 Main -Xms128m -Xmx750m -XX:MaxPermSize=350m -XX:ReservedCodeCacheSize=96m -XX:+UseCodeCacheFlushing 
          ...
          
          11248 jboss-modules.jar -D[Standalone] -XX:+UseCompressedOops -verbose:gc 
          ...
          
          12892 Jps 
          ...
          
          12080 jboss-modules.jar -D[Process Controller] -Xms64m -Xmx512m -XX:MaxPermSize=256m 
          ...
          
        • ps aux コマンドを使用して複数の EAP インスタンスの情報を返すこともできます。
          以下は、実行している EAP プロセスを PID およびロールで識別する、詳細な ps コマンドからの出力の一部になります。
          $ ps aux | grep java
          username 12080  0.1  0.9 3606588 36772 pts/0   Sl+  10:09   0:01 /path/to/java -D[Process Controller] -server -Xms128m -Xmx128m -XX:MaxPermSize=256m 
          ...
          
          username 12096  1.0  4.1 3741304 158452 pts/0  Sl+  10:09   0:13 /path/to/java -D[Host Controller] -Xms128m -Xmx128m -XX:MaxPermSize=256m 
          ...
          
          username 12155  1.7  8.9 4741800 344224 pts/0  Sl+  10:09   0:22 /path/to/java -D[Server:server-one] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1000m -Xmx1000m -server -
          ...
          
          username 12196  1.8  9.4 4739612 364436 pts/0  Sl+  10:09   0:22 /path/to/java -D[Server:server-two] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1000m -Xmx1000m -server 
          ...
          
        上記の例では、ドメイン全体を停止するには Process Controller プロセスを停止します。
        これらのコマンドに grep ユーティリティーを使用すると Process Controller を識別できます。
        jps -v | grep "Process Controller"
        ps aux | grep "Process Controller"
    2. kill PID を実行して、TERM シグナルをプロセスに送信します。PID は前述のコマンドの 1 つを使用して識別されたプロセス IDに置き換えます。
結果

JBoss EAP 6 がクリーンにシャットダウンされ、データは失われません。

2.2.8. サーバー実行時に渡すスイッチと引数のリファレンス

アプリケーションサーバーの起動スクリプトは実行時に追加の引数とスイッチを受け取ります。これらのパラメーターを使用すると、standalone.xmldomain.xml、および host.xml の設定ファイルで定義されたものとは別の設定でサーバーを起動できます。これには、ソケットバインディングの代替セットや二次設定でのサーバーの起動が含まれることがあります。起動時にヘルプスイッチを渡すと、利用可能なこれらのパラメーターのリストを表示できます。
次の例は「JBoss EAP 6 をスタンドアロンサーバーとして起動」および「JBoss EAP 6 を管理対象ドメインとして起動」で説明されているサーバーの起動に似ていますが、-h または --help スイッチが追加されています。ヘルプスイッチの結果は下表を参照してください。

例2.5 'help' スイッチ

スタンドアロンモード:
[localhost bin]$ standalone.sh -h
ドメインモード:
[localhost bin]$ domain.sh -h

表2.1 実行時スイッチおよび引数

引数またはスイッチ モード 説明
--admin-only スタンドアロン サーバーの実行タイプを ADMIN_ONLY に設定します。これにより管理インターフェースが開かれ、管理要求が許可されますが、他のランタイムサービスは起動されず、エンドユーザーの要求は許可されません。
--admin-only ドメイン ホストコントローラーの実行タイプを ADMIN_ONLY に設定します。これにより管理インターフェースが開かれ、管理要求が許可されますが、サーバーは起動しません。ホストコントローラーがドメインのマスターである場合はスレーブホストコントローラーからの受信接続が許可されます。
-b <value>, -b=<value> スタンドアロン、ドメイン システムプロパティー jboss.bind.address を該当する値に設定します。
-b<interface>=<value> スタンドアロン、ドメイン システムプロパティー jboss.bind.address.<interface> を指定の値に設定します。
--backup ドメイン このホストがドメインコントローラーではない場合でも永続ドメイン設定のコピーを保持します。
-c <config>, -c=<config> スタンドアロン 使用するサーバー設定ファイルの名前。デフォルト値は standalone.xml です。
-c <config>, -c=<config> ドメイン 使用するサーバー設定ファイルの名前。デフォルト値は domain.xml です。
--cached-dc ドメイン ホストがドメインコントローラーではなく、起動時にドメインコントローラーに接続できない場合、ローカルでキャッシュされたドメイン設定のコピーを使用してブートします。
--debug [<port>] スタンドアロン オプションの引数を用いてデバッグモードを有効にし、ポートを指定します。起動スクリプトがサポートする場合のみ動作します。
-D<name>[=<value>] スタンドアロン、ドメイン システムプロパティーを設定します。
--domain-config=<config> ドメイン 使用するサーバー設定ファイルの名前。デフォルト値は domain.xml です。
-h, --help スタンドアロン、ドメイン ヘルプメッセージを表示し、終了します。
--host-config=<config> ドメイン 使用するホスト設定ファイルの名前。デフォルト値は host.xml です。
--interprocess-hc-address=<address> ドメイン ホストコントローラーがプロセスコントローラーからの通信をリッスンしなければならないアドレス。
--interprocess-hc-port=<port> ドメイン ホストコントローラーがプロセスコントローラーからの通信をリッスンしなければならないポート。
--master-address=<address> ドメイン システムプロパティー jboss.domain.master.address を指定の値に設定します。デフォルトのスレーブホストコントローラーの設定では、マスターホストコントローラーのアドレスを設定するために使用されます。
--master-port=<port> ドメイン システムプロパティー jboss.domain.master.port を指定の値に設定します。デフォルトのスレーブホストコントローラーの設定では、マスターホストコントローラーによるネイティブ管理の通信で使用されるポートを設定するために使用されます。
--read-only-server-config=<config> スタンドアロン 使用するサーバー設定ファイルの名前。元のファイルは上書きされないため、--server-config および -c とは異なります。
--read-only-domain-config=<config> ドメイン 使用するドメイン設定ファイルの名前。最初のファイルは上書きされないため、--domain-config および -c とは異なります。
--read-only-host-config=<config> ドメイン 使用するホスト設定ファイルの名前。最初のファイルは上書きされないため、--host-config とは異なります。
-P <url>, -P=<url>, --properties=<url> スタンドアロン、ドメイン 該当する URL からシステムプロパティーをロードします。
--pc-address=<address> ドメイン プロセスコントローラーが制御するプロセスからの通信をリッスンするアドレス。
--pc-port=<port> ドメイン プロセスコントローラーが制御するプロセスからの通信をリッスンするポート。
-S<name>[=<value>] スタンドアロン セキュリティープロパティーを設定します。
--server-config=<config> スタンドアロン 使用するサーバー設定ファイルの名前。デフォルト値は standalone.xml です。
-u <value>, -u=<value> スタンドアロン、ドメイン システムプロパティー jboss.default.multicast.address を指定の値に設定します。
-v, -V, --version スタンドアロン、ドメイン アプリケーションサーバーのバージョンを表示し、終了します。

2.3. サーバーの起動と停止

2.3.1. 管理 CLI を使用したサーバーの起動および停止

スタンドアロンモードでは、管理 CLI または管理コンソールを使用してサーバーを起動および停止できます。ドメインモードでは、サーバーインスタンスのみを起動できます。これらの管理ツールを使用すると、単一のスタンドアロンサーバーインスタンスを制御したり、管理対象ドメインのデプロイメント全体で複数のサーバーを選択的に管理したりできます。ドメインモードで管理コンソールを使用する場合は、「管理コンソールを使用したサーバーの起動」の手順を参照してください。管理 CLI を使用する場合は、スタンドアロンサーバーインスタンスと管理対象ドメインインスタンスでプロセスが異なります。
管理 CLI を用いたスタンドアロンサーバーの起動および停止

スタンドアロンサーバーインスタンスは、コマンドラインスクリプトで起動でき、管理 CLI より shutdown コマンドを使用してシャットダウンできます。インスタンスが再度必要な場合は、「JBoss EAP 6 をスタンドアロンサーバーとして起動」の説明どおりに起動プロセスを再実行します。

例2.6 管理 CLI よりスタンドアロンサーバーインスタンスを停止する

[standalone@localhost:9999 /] shutdown
管理 CLI を用いた管理対象ドメインの起動および停止

管理対象ドメインを実行している場合は、管理コンソールを使用するとドメインの特定サーバーを選択的に起動または停止できます。これには、ドメイン全体のサーバーグループや、ホスト上の特定サーバーインスタンスが含まれます。

例2.7 管理 CLI より管理対象ドメインのサーバーホストを停止する

スタンドアロンサーバーと同様に、宣言された管理対象ドメインホストをシャットダウンするには shutdown コマンドを使用します。この例では、シャットダウン操作を呼び出す前にインスタンス名を宣言し、「master」という名前のサーバーホストを停止します。tab キーを使用して文字列を補完し、利用可能なホスト値などの可視変数を表示します。
[domain@localhost:9999 /] /host=master:shutdown

例2.8 管理 CLI より管理対象ドメインのサーバーホストを起動および停止する

この例は、start および stop 操作を呼び出す前に、サーバーグループを宣言することで、main-server-group という名前のデフォルトのサーバーグループを起動します。tab キーを使用して文字列を補完し、利用可能なサーバーグループ名の値などの可視変数を表示します。
[domain@localhost:9999 /] /server-group=main-server-group:start-servers
[domain@localhost:9999 /] /server-group=main-server-group:stop-servers

例2.9 管理 CLI より管理対象ドメインのサーバーインスタンスを起動および停止する

この例は、start および stop 操作を呼び出す前に、ホストおよびサーバーの設定を宣言することで、master ホスト上の server-one という名前のサーバーインスタンスを起動および停止します。tab キーを使用して文字列を補完し、利用可能なホストおよびサーバー設定の値などの可視変数を表示します。
[domain@localhost:9999 /] /host=master/server-config=server-one:start
[domain@localhost:9999 /] /host=master/server-config=server-one:stop

2.3.2. 管理コンソールを使用したサーバーの起動

手順2.10 管理対象ドメイン向けのサーバーの起動

  1. コンソールの右上にある Runtime タブを選択します。Server メニューを展開し、Overview を選択します。
  2. Server Instances のリストから、起動するサーバーを選択します。実行されているサーバーはチェックマークで示されます。
    このリストにあるインスタンスにカーソルを合わせ、サーバーの詳細の下に青色でオプションを表示します。
  3. インスタンスを起動するには、表示された Start Server テキストをクリックします。クリックすると、ダイアログボックスが開きます。Confirm ボタンをクリックしてサーバーを起動します。
結果

選択したサーバーが起動し、稼働状態になります。

2.3.3. 管理コンソールを使用したサーバーの停止

手順2.11 管理コンソールを使用した管理対象ドメインのサーバーの停止

  1. コンソールの右上にある Runtime タブを選択します。Domain メニューを展開し、Overview を選択します。
  2. Hosts, groups and server instances の表に使用可能な Server Instances のリストが表示されます。稼働中のサーバーにはチェックマークが付きます。
  3. 選択したサーバーにカーソルを合わせ、表示される Stop Server テキストをクリックします。確認ダイアログウインドウが表示されます。
  4. Confirm をクリックし、サーバーを停止します。
結果

選択されたサーバーが停止します。

2.4. ファイルシステムパス

2.4.1. ファイルシステムパス

JBoss EAP 6 では、ファイルシステムパスに論理名を使用します。domain.xmlhost.xml、および standalone.xml の設定には、パスを宣言できるセクションが含まれます。設定の他のセクションは、各インスタンスの絶対パスを宣言せず論理名を使用することにより、これらのパスを参照できます。これにより、特定のホスト設定をユニバーサルな論理名に解決できるため、設定や管理がしやすくなります。
たとえば、ロギングサブシステム設定には、サーバーの log ディレクトリーを示す jboss.server.log.dir パスへの参照が含まれます。

例2.10 ロギングディレクトリーの相対パス例

<file relative-to="jboss.server.log.dir" path="server.log"/>
JBoss EAP 6 では、複数の標準的なパスが自動的に提供されるため、ユーザーが設定ファイルでこれらのパスを設定する必要はありません。

表2.2 標準的なパス

Value 説明
java.ext.dirs JDK 拡張機能ディレクトリーパス。
jboss.home.dir JBoss EAP 6 ディストリビューションのルートディレクトリー。
user.home ユーザーホームディレクトリー。
user.dir ユーザーのカレントワーキングディレクトリー。
java.home Java インストールディレクトリー。
jboss.server.base.dir 各サーバーインスタンスのルートディレクトリー。
jboss.server.data.dir サーバーが永続データファイルストレージに使用するディレクトリー。
jboss.server.config.dir サーバー設定が含まれるディレクトリー。
jboss.server.log.dir サーバーがファイルストレージに使用するディレクトリー。
jboss.server.temp.dir サーバーが一時ファイルストレージに使用するディレクトリー。
jboss.server.deploy.dir サーバーがデプロイ済みコンテンツを格納するために使用するディレクトリー。
jboss.controller.temp.dir ホストコントローラーが一時的なファイルストレージとして使用するディレクトリー。
jboss.domain.base.dir ドメインコンテンツ用ベースディレクトリー。
jboss.domain.config.dir ドメイン設定を含むディレクトリー。
jboss.domain.data.dir ドメインが永続データファイルストレージに使用するディレクトリー。
jboss.domain.log.dir ドメインが永続ログファイルストレージに使用するディレクトリー。
jboss.domain.temp.dir ドメインが一時ファイルストレージに使用するディレクトリー。
jboss.domain.deployment.dir ドメインがデプロイ済みコンテンツを格納するために使用するディレクトリー。
jboss.domain.servers.dir ドメインが管理対象ドメインインスタンスの出力を格納するために使用するディレクトリー。
パスのオーバーライド

スタンドアロンサーバーを実行している場合は、以下の 2 つの方法の 1 つを用いて jboss.server.base.dirjboss.server.log.dir、または jboss.server.config.dir パスをオーバーライドできます。

  1. サーバーの起動時に、コマンドラインで引数を渡すことができます。例は次のとおりです。
    bin/standalone.sh -Djboss.server.log.dir=/var/log
  2. サーバー設定ファイルの JAVA_OPTS 変数を編集できます。EAP_HOME/bin/standalone.conf ファイルを開き、ファイルの最後に以下の行を追加します。
    JAVA_OPTS="$JAVA_OPTS Djboss.server.log.dir=/var/log"
パスのオーバーライドは、管理対象ドメインで実行しているサーバーではサポートされません。

カスタムパスの追加

カスタムパスを作成することも可能です。たとえば、ロギングに使用する相対パスを定義できます。次に、my.relative.path を使用するようログハンドラーを変更できます。

例2.11 カスタムロギングパス

my.relative.path=/var/log

2.5. 設定ファイル

2.5.1. JBoss EAP 6 の設定ファイル

JBoss EAP 6 の設定は、以前のバージョンから大幅に変更されました。最も大きな違いの 1 つは、以下のファイルが 1 つ以上含まれる簡素化された設定ファイル構造を使用することです。

表2.3 設定ファイルの場所

サーバーモード 場所 目的
domain.xml EAP_HOME/domain/configuration/domain.xml 管理対象ドメインの主要の設定ファイルです。ドメインマスターのみがこのファイルを読み取ります。他のドメインメンバーでは削除が可能です。
host.xml EAP_HOME/domain/configuration/host.xml このファイルには、管理対象ドメインの物理ホスト固有の設定情報が含まれています (ネットワークインターフェース、ソケットバインディング、ホスト名、その他のホスト固有の詳細など)。host.xml ファイルには、host-master.xml および host-slave.xml (詳細については、下記参照) の両方の機能がすべて含まれています。このファイルはスタンドアロンサーバーの場合は存在しません。
host-master.xml EAP_HOME/domain/configuration/host-master.xml このファイルには、サーバーを管理対象ドメインのマスターサーバーとして実行するために必要な設定情報のみが含まれています。このファイルはスタンドアロンサーバーでは存在しません。
host-slave.xml EAP_HOME/domain/configuration/host-slave.xml このファイルには、サーバーを管理対象ドメインのスレーブサーバーとして実行するために必要な設定情報のみが含まれています。このファイルはスタンドアロンサーバーでは存在しません。
standalone.xml EAP_HOME/standalone/configuration/standalone.xml スタンドアロンサーバーのデフォルトの設定ファイルです。このファイルにはサブシステム、ネットワーキング、デプロイメント、ソケットバインディング、その他の設定情報などを含むスタンドアロンサーバーに関するすべての情報が含まれています。スタンドアロンサーバーの起動時にこの設定が自動的に使用されます。
standalone-full.xml EAP_HOME/standalone/configuration/standalone-full.xml スタンドアロンサーバーの設定例です。高可用性を要するサブシステムを除く、可能な全サブシステムのサポートが含まれます。使用するには、サーバーを停止し、次のコマンドを使用して再起動します: EAP_HOME/bin/standalone.sh -c standalone-full.xml
standalone-ha.xml EAP_HOME/standalone/configuration/standalone-ha.xml このサンプル設定ファイルは、デフォルトのサブシステムをすべて有効にし、高可用性または負荷分散クラスターに参加できるよう mod_cluster および JGroups サブシステムをスタンドアロンサーバーに対して追加します。このファイルは管理対象ドメインには適用されません。この設定を使用するには、サーバーを停止し、次のコマンドを使用して再起動します: EAP_HOME/bin/standalone.sh -c standalone-ha.xml
standalone-full-ha.xml EAP_HOME/standalone/configuration/standalone-full-ha.xml これはスタンドアロンサーバーの設定例です。高可用性に必要となるサブシステムを含む、可能なすべてのサブシステムのサポートが含まれます。使用するにはサーバーを停止し、次のコマンドを使用して再起動します: EAP_HOME/bin/standalone.sh -c standalone-full-ha.xml
これらはデフォルトの場所です。実行時に異なる設定ファイルを指定できます。

2.5.2. 記述子ベースのプロパティー置換

アプリケーションの設定 (データソース接続パラメーターなど) は、通常は開発デプロイメント、テストデプロイメント、および本番稼働デプロイメントによって異なります。Java EE 仕様にはこれらの設定を外部化するメソッドが含まれていないため、このような違いはビルドシステムスクリプトで対応することがあります。JBoss EAP 6 では、記述子ベースのプロパティー置換を使用して設定を外部的に管理できます。
記述子ベースのプロパティー置換は、記述子を基にプロパティーを置き換えるため、アプリケーションやビルドチェーンから環境に関する仮定を除外できます。環境固有の設定は、アノテーションやビルドシステムスクリプトでなく、デプロイメント記述子に指定できます。設定はファイルに指定したり、パラメーターとしてコマンドラインで提供したりできます。
記述子ベースのプロパティー置換は、standalone.xml または domain.xml からグローバルに有効化されます。

例2.12 記述子ベースのプロパティー置換

<subsystem xmlns="urn:jboss:domain:ee:1.1">
  <spec-descriptor-property-replacement>
    true
  </spec-descriptor-property-replacement>
  <jboss-descriptor-property-replacement>
    true
  </jboss-descriptor-property-replacement>
</subsystem>
Java EE 記述子置換はデフォルトで無効になります。有効な場合は、ejb-jar.xmlpersistence.xml の設定ファイルで記述子を置換できます。
Java 固有の記述子置換はデフォルトで有効になります。有効な場合は、次の設定ファイルで記述子を置換できます。
  • jboss-ejb3.xml
  • jboss-app.xml
  • jboss-web.xml
  • *-jms.xml
  • *-ds.xml
たとえば、以下のアノテーションを持つ Bean があるとします。

例2.13 アノテーションの例

@ActivationConfigProperty(propertyName = "connectionParameters", propertyValue = "host=192.168.1.1;port=5445")
記述子ベースのプロパティー置換が有効になっている場合、コマンドラインで以下のように connectionParameters を指定できます。
./standalone.sh -DconnectionParameters='host=10.10.64.1;port=5445'
システムプロパティーを使用して同じことを行う場合は、リテラル値の代わりにを使用します。式の形式は ${parameter:default} のようになります。式が設定で使用された場合は、そのパラメーターの値が使用されます。パラメーターが存在しない場合は、指定されたデフォルト値が代わりに使用されます。

例2.14 記述子での式の使用

<activation-config>
  <activation-config-property>
    <activation-config-property-name>
      connectionParameters
      </activation-config-property-name>
    <activation-config-property-value>
      ${jms.connection.parameters:'host=10.10.64.1;port=5445'}
    </activation-config-property-value>
  </activation-config-property>
</activation-config>
${jms.connection.parameters:'host=10.10.64.1;port=5445'} では、デフォルト値を提供しながら、コマンドラインで提供されたパラメーターによって接続パラメーターが上書きされます。

2.5.3. 記述子ベースのプロパティー置換の有効化/無効化

概要

記述子プロパティー置換の限定的な制御が、jboss-as-ee_1_1.xsd に導入されました。このタスクには、記述子ベースのプロパティー置換を設定するのに必要な手順が含まれます。

記述子ベースのプロパティー置換フラグはブール値を持ちます。
  • true に設定された場合は、プロパティー置換が有効になります。
  • false に設定された場合は、プロパティー置換が無効になります。

手順2.12 jboss-descriptor-property-replacement

jboss-descriptor-property-replacement は、次の記述子でプロパティー置換を有効または無効にするために使用されます。
  • jboss-ejb3.xml
  • jboss-app.xml
  • jboss-web.xml
  • *-jms.xml
  • *-ds.xml
jboss-descriptor-property-replacement のデフォルト値は true です。
  1. 管理 CLI では、次のコマンドを実行して jboss-descriptor-property-replacement の値を決定します。
    /subsystem=ee:read-attribute(name="jboss-descriptor-property-replacement")
  2. 次のコマンドを実行して動作を設定します。
    /subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)

手順2.13 spec-descriptor-property-replacement

spec-descriptor-property-replacement は、次の記述子でプロパティー置換を有効または無効にするために使用されます。
  • ejb-jar.xml
  • persistence.xml
  • application.xml
  • web.xml
spec-descriptor-property-replacement のデフォルト値は false です。
  1. 管理 CLI では、次のコマンドを実行して spec-descriptor-property-replacement の値を確認します。
    /subsystem=ee:read-attribute(name="spec-descriptor-property-replacement")
  2. 次のコマンドを実行して動作を設定します。
    /subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)
結果

記述子ベースのプロパティー置換が正常に設定されます。

2.5.4. ネストされた式

式はネストすることができるため、固定値の代わりにさらに高度な式を使用できます。ネストされた式の書式は、通常の式の場合と同様ですが、ある式が別の式に組み込まれます。例を以下に示します。

例2.15 ネストされた式

${system_value_1${system_value_2}}
ネストされた式は、再帰的に評価されるため、最初に inner 式が評価され、次に outer 式が評価されます。ネストされた式は式が許可された場所ならどこでも許可されます (ただし、管理 CLI コマンドを除く)。
通常の式の場合と同様に、ネストされた式を解決するサポート対象ソースはシステムプロパティー、環境変数、およびボールトです。デプロイメントの場合のみ、ソースは、デプロイメントアーカイブの META-INF/jboss.properties ファイルにリストされたプロパティーになります。サブデプロイメントをサポートする EAR または他のデプロイメントタイプでは、META-INF/jboss.properties が外側のデプロイメント (EAR など) 内にある場合はスコープ対象がすべてのサブデプロイメントになり、META-INF/jboss.properties がサブデプロイメントアーカイブ (EAR 内部の WAR など) 内にある場合はスコープ対象が 1 つのサブデプロイメントになります。

例2.16 設定ファイルでのネストされた式の使用

ネストされた式の実際の適用は、データソース定義で行います。データソース定義で使用されたパスワードがマスクされると、データソース定義の行は結果的に以下のようになります。
<password>${VAULT::ds_ExampleDS::password::1}</password>
ネストされた式を使用する場合、ds_ExampleDS の値は、システムプロパティーで置き換えることができます。システムプロパティー datasource_name に値 ds_ExampleDS が割り当てられた場合、データソース定義の行は以下のようになります。
<password>${VAULT::${datasource_name}::password::1}</password>
JBoss EAP は、最初に式 ${datasource_name} を評価し、次にこれを大きい式に入力して、結果となる式を評価します。この設定の利点は、データソースの名前が固定された設定から抽象化されることです。
式は再帰的にすることもできます。この場合、式は解決される式に解決されます。ネストされた式と再帰的な式は間接の形をとります。再帰的な式は管理 CLI コマンドで許可されないことに注意してください。

例2.17 再帰的な式

前の例では、さらに式 ${VAULT::ds_ExampleDS::password::1} に解決される式 ${foo} を使用できます (ボールトに含まれる値に解決されます: secret)。

2.5.5. ファイルの履歴設定

アプリケーションサーバーの設定ファイルには、standalone.xmldomain.xml、および host.xml ファイルが含まれます。これらのファイルは直接編集して変更できますが、管理 CLI や管理コンソールといった利用可能な管理操作でアプリケーションサーバーモデルを設定する方法が推奨されます。
サーバーインスタンスの保守および管理をしやすくするため、アプリケーションサーバーは起動時に元の設定ファイルにタイムスタンプを付けたものを作成します。管理操作によってその他の設定変更が行われると、元のファイルが自動的にバックアップされ、インスタンスの作業用コピーが参照およびロールバック向けに保持されます。このアーカイブ機能には、サーバー設定のスナップショットの保存、ロード、および削除が含まれ、リコールおよびロールバックを可能にします。

2.5.6. 以前の設定でのサーバーの起動

以下の例は、standalone.xml を使用してスタンドアロンサーバーの以前の設定でアプリケーションサーバーを起動する方法を示しています。同じコンセプトは、domain.xmlhost.xml のそれぞれを使用した管理対象ドメインに適用されます。
この例では、管理操作によってサーバーモデルが変更される場合にアプリケーションサーバーにより自動的に保存される以前の設定が呼び出されます。

例2.18 サーバーを保存済みの設定で起動

  1. 起動するバックアップバージョンを特定します。この例では、正常な起動後に最初加えられた変更前のサーバーモデルのインスタンスが再度呼び出されます。
    EAP_HOME/standalone/configuration/standalone_xml_history/current/standalone.v1.xml
  2. jboss.server.config.dir 下で相対ファイル名を渡し、バックアップモデルのこの設定を用いてサーバーを起動します。
    EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/current/standalone.v1.xml
結果

アプリケーションサーバーが、選択された設定で起動されます。

注記

ドメイン設定の履歴は、EAP_HOME/domain/configuration/domain_xml_history/current/domain.v1.xml にあります。
jboss.domain.config.dir 下で相対ファイル名を渡し、バックアップモデルのこの設定を用いてサーバーを起動します。
この設定を用いてドメインを起動するには、以下を実行します。
EAP_HOME/bin/domain.sh --domain-config=domain_xml_history/current/domain.v1.xml

2.5.7. 管理 CLI を使用した設定スナップショットの保存

概要

設定スナップショットは、現在のサーバー設定のポイントインタイムコピーです。これらのコピーは、管理者が保存およびロードできます。

次の例では standalone.xml 設定ファイルを使用しますが、同じプロセスが domain.xml および host.xml 設定ファイルにも適用されます。

手順2.14 設定スナップショットの撮影および保存

  • スナップショットの保存

    take-snapshot 操作を実行して、現在のサーバー設定のコピーを取得します。
    [standalone@localhost:9999 /] :take-snapshot
    {
        "outcome" => "success",
        "result" => "/home/User/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-172258657standalone.xml"
    
結果

現在のサーバー設定のスナップショットが保存されます。

2.5.8. 管理 CLI を使用した設定スナップショットのロード

設定スナップショットは、現在のサーバー設定のポイントインタイムコピーです。これらのコピーは、管理者が保存およびロードできます。スナップショットのロードのプロセスは、「以前の設定でのサーバーの起動」 で使用された方法に似ており、スナップショットを作成、リスト、および削除するために使用される管理 CLI インターフェースではなくコマンドラインから実行します。
次の例では standalone.xml ファイルを使用しますが、同じプロセスが domain.xml および host.xml ファイルにも適用されます。

手順2.15 設定スナップショットのロード

  1. ロードするスナップショットを識別します。この例では、スナップショットディレクトリーから以下のファイルが呼び出されます。スナップショットファイルのデフォルトのパスは以下のとおりです。
    EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110812-191301472standalone.xml
    スナップショットは相対パスにより表されます。たとえば、上記の例は次のように記述できます。
    jboss.server.config.dir/standalone_xml_history/snapshot/20110812-191301472standalone.xml
  2. ファイル名を渡し、選択したスナップショットを用いてサーバーを起動します。
    EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/snapshot/20110913-164449522standalone.xml
結果

ロードしたスナップショットに選択された設定を用いてサーバーが再起動します。

2.5.9. 管理 CLI を使用した設定スナップショットの削除

設定スナップショットは、現在のサーバー設定のポイントインタイムコピーです。これらのコピーは、管理者が保存およびロードできます。
次の例では standalone.xml ファイルを使用しますが、同じプロセスが domain.xml および host.xml ファイルにも適用されます。

手順2.16 特定のスナップショットの削除

  1. ロードするスナップショットを指定します。この例では、スナップショットディレクトリーから以下のファイルが削除されます。
    EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-165714239standalone.xml
  2. :delete-snapshot コマンドを実行して、特定のスナップショットを削除します。以下の例のようにスナップショットの名前を指定します。
    [standalone@localhost:9999 /] :delete-snapshot(name="20110630-165714239standalone.xml")
    {"outcome" => "success"}
    
結果

スナップショットが削除されます。

手順2.17 スナップショットすべてを削除

  • :delete-snapshot(name="all") コマンドを以下の例のとおりに実行し、スナップショットをすべて削除します。
    [standalone@localhost:9999 /] :delete-snapshot(name="all")
    {"outcome" => "success"}
    
結果

スナップショットがすべて削除されます。

2.5.10. 管理 CLI を使用したすべての設定スナップショットのリスト

設定スナップショットは、現在のサーバー設定のポイントインタイムコピーです。これらのコピーは、管理者が保存およびロードできます。
次の例では standalone.xml ファイルを使用しますが、同じプロセスが domain.xml および host.xml ファイルにも適用されます。

手順2.18 すべての設定スナップショットのリスト

  • すべてのスナップショットのリスト

    :list-snapshotsコマンドを実行して、保存されたすべてのスナップショットをリストします。
    [standalone@localhost:9999 /] :list-snapshots
    {
        "outcome" => "success",
        "result" => {
            "directory" => "/home/hostname/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot",
            "names" => [
                "20110818-133719699standalone.xml",
                "20110809-141225039standalone.xml",
                "20110802-152010683standalone.xml",
                "20110808-161118457standalone.xml",
                "20110912-151949212standalone.xml",
                "20110804-162951670standalone.xml"
            ]
        }
    }
    
結果

スナップショットがリストされます。

第3章 管理インターフェース

3.1. アプリケーションサーバーの管理

JBoss EAP 6 は、必要なときに実装を設定および管理できる複数の管理ツールを提供します。これらの管理ツールには、新しい管理コンソールや管理コマンドラインインターフェース (CLI) が含まれます。基礎となる管理 API を使用すると、上級ユーザーは必要に応じて独自のツールを開発できます。

3.2. 管理アプリケーションプログラミングインターフェース (API)

管理クライアント

JBoss EAP 6 は、サーバーを設定および管理する 3 つの方法 (Web インターフェース、コマンドラインクライアント、および XML 設定ファイルのセット) を提供します。推奨される設定ファイルの編集方法には管理コンソールと管理 CLI が含まれますが、これらの 3 つの方法で設定に加えられた編集は、異なるビューにわたって常に同期され、最終的に XML ファイルに永続化されます。サーバーインスタンスの実行中に XML 設定ファイルで行われた編集は、サーバーモデルによって上書きされることに注意してください。

HTTP API

HTTP API エンドポイントは、管理レイヤーと統合するために HTTP プロトコルに依存する管理クライアント (管理コンソールなど) のエントリーポイントです。このエンドポイントは、 JSON エンコードプロトコルとデタイプ (de-typed) の RPC スタイル API を使用して管理ドメインまたはスタンドアロンサーバーに対して管理操作を定義および実行します。このエンドポイントは Web コンソールによって使用されますが、さまざまな他のクライアントと統合することもできます。

HTTP API エンドポイントはドメインコントローラまたはスタンドアロンサーバーインスタンスと共存します。HTTP API エンドポイントは、管理操作を実行するためのコンテキストと Web インターフェースにアクセスするためのコンテキストの 2 つの異なるコンテキストを処理します。デフォルトでは、ポート 9990 で実行されます。

例3.1 HTTP API 設定ファイルの例

<management-interfaces>
  [...]
  <http-interface security-realm="ManagementRealm">
     <socket-binding http="management-http"/>
  </http-interface>
</management-interfaces>
Web コンソールは、HTTP 管理 API と同じポートで実行されます。管理コンソールまたは HTTP API にどのようにアクセスするかを区別することが重要です (デフォルトの localhost でアクセスされる管理コンソールと、特定のホストとポートの組み合わせまたは公開されたドメイン HTTP API によりリモートでアクセスされる管理コンソール)。

表3.1 管理コンソールまたは公開された HTTP API にアクセスする URL

URL 説明
http://localhost:9990/console ローカルホストでアクセスされる管理コンソール (管理対象ドメイン設定を制御します)。
http://hostname:9990/console リモートでアクセスされる管理コンソール (ホストを指定し、管理対象ドメイン設定を制御します)。
http://hostname:9990/management HTTP 管理 API は管理コンソールと同じポートで実行され、API に公開された raw 属性と値を表示します。
ネイティブ API

ネイティブ API ツールの例には管理 CLI があります。この管理ツールは管理対象ドメインまたはスタンドアロンサーバーインスタンスに使用できるため、ユーザーはドメインコントローラーまたはスタンドアロンサーバーインスタンスに接続し、デタイプ (detyped) の管理モデルを介して利用可能な管理操作を実行できます。

ネイティブ API エンドポイントは、管理レイヤーと統合するためにネイティブプロトコルに依存する管理クライアントのエントリーポイントです。管理操作を定義および実行するために、オープンバイナリプロトコルと、非常に少数の Java タイプに基づいた RPC スタイルの API を使用します。これは、管理 CLI 管理ツールによって使用されますが、他のクライアントの統合機能も提供します。
ネイティブ API エンドポイントはホストコントローラーまたはスタンドアロンサーバーと共存します。管理 CLI を使用するには、これを有効にする必要があります。デフォルトでは、ポート 9999 で実行されます。

例3.2 ネイティブ API 設定ファイルの例

<management-interfaces>
  <native-interface security-realm="ManagementRealm">
    <socket-binding native="management-native"/>
  </native-interface>
  [...]
</management-interfaces>

3.3. 管理コンソールと管理 CLI

JBoss EAP 6 では、すべてのサーバーインスタンスと設定が、XML ファイルの編集ではなく管理インターフェースによって管理されます。設定 XML ファイルは引き続き編集できますが、管理インターフェースによる管理は、サーバーインスタンスの永続的な管理に対して追加の検証機能および高度な機能を提供します。サーバーインスタンスの実行中に XML 設定ファイルに加えられた変更はサーバーモデルによって上書きされ、追加された XML コメントもすべて削除されます。サーバーインスタンスの実行中は管理インターフェースのみを使用して設定ファイルを変更する必要があります。
Web ブラウザーでグラフィカルユーザーインターフェースを使用してサーバーを管理するには、管理コンソールを使用します。
コマンドラインインターフェースを使用してサーバーを管理するには、管理 CLI を使用します。

3.4. 管理コンソール

3.4.1. 管理コンソール

管理コンソールは JBoss EAP 6 の Web ベースの管理ツールです。
管理コンソールを使用して、サーバーの開始および停止、アプリケーションのデプロイおよびアンデプロイ、システム設定の調整、サーバー設定の変更の永続化を行います。管理コンソールは管理タスクも実行でき、変更後にサーバーインスタンスの再起動またはリロードが必要な場合はライブ通知も行います。
管理対象ドメインでは、同じドメイン内のサーバーインスタンスやサーバーグループをドメインコントローラーの管理コンソールから集中管理できます。

3.4.2. 管理コンソールへのログイン

前提条件

  1. 管理コンソールのスタートページへのアクセス

    Web ブラウザーを起動し、Web ブラウザーで管理コンソール (http://localhost:9990/console/App.html) に移動します。

    注記

    ポート 9990 は、管理コンソールソケットバインディングとして事前定義されています。
  2. 以前作成したアカウントのユーザー名とパスワードを入力し、管理コンソールのログイン画面にログインします。
    The login screen for the Management console.

    図3.1 管理コンソールのログイン画面

結果

ログインすると、以下のアドレスにリダイレクトされ、管理コンソールのランディングページが表示されます (http://localhost:9990/console/App.html#home)。

3.4.3. 管理コンソールの言語の変更

Web ベースの管理コンソールの言語設定では、デフォルトで英語が使用されます。英語の代わりに次のいずれかの言語を選択できます。

サポート言語

  • ドイツ語 (de)
  • 簡体中国語 (zh-Hans)
  • ブラジルポルトガル語 (pt-BR)
  • フランス語 (fr)
  • スペイン語 (es)
  • 日本語 (ja)

手順3.1 Web ベース管理コンソールの言語の変更

  1. 管理コンソールにログインします。

    Web ベースの管理コンソールにログインします。
  2. Settings ダイアログを開きます。

    画面の右下付近に Settings ラベルがあります。これをクリックして管理コンソールの設定を開きます。
  3. 必要な言語を選択します。

    Locale 選択ボックスから必要な言語を選択します。次に、Save を選択します。確認ボックスで、アプリケーションをリロードする必要があることが示されます。Confirm をクリックします。新しいロケールを使用するために Web ブラウザが自動的に更新されます。

3.4.4. EAP コンソールの分析

Google Analytics とは

Google Analytics は、Web サイトの包括的な使用統計を提供する無料の Web 分析サービスです。訪問数、ページビュー、訪問別ページ数、平均滞在時間など、Web サイトの訪問者に関する重要なデータを提供します。Google Analytics を使用すると、Web サイトの存在やそのユーザーの認知度が向上します。

EAP 管理コンソールでの Google Analytics

JBoss EAP 6 では、ユーザーは管理コンソールの Google Analytics を有効または無効にできます。Google Analytics の機能は、コンソールがどのように使用され、コンソールのどの部分が重要であるかを Red Hat EAP チームが理解することを目的としています。この情報は、ユーザーのニーズを満たすコンソールのデザイン、機能、およびコンテンツを導入するために使用されます。

3.4.5. EAP コンソールの Google Analytics の有効化/無効化

EAP 管理コンソールで Google Analytics を有効にするには、以下の手順に従います。
  • 管理コンソールにログインします。
  • コンソールの右下にある Settings をクリックします。
    Description

    図3.2 管理コンソールのログイン画面

  • Settings ウインドウの Enable Usage Data Collection チェックボックスを選択し、Save ボタンをクリックします。アプリケーションをリロードし、新しい設定を有効にすることを確認します。
    Description

    図3.3 Settings ウインドウ (使用率データの収集を有効化)

管理コンソールの Google Analytics を有効にした後に無効にするには、Settings ウインドウの Enable Usage Data Collection をクリックして選択を解除します。Save ボタンをクリックします。次に、アプリケーションをリロードし、新しい設定を有効にすることを確認します。
Description

図3.4 Settings ウインドウ (使用率データの収集を無効化)

注記

EAP 6 コンソールでは、Google Analytics はデフォルトで無効になっています。Google Analytics の使用は任意です。

3.4.6. 管理コンソールを使用したサーバーの設定

手順3.2 サーバーの設定

  1. コンソールの上部より Domain タブを選択します。利用可能なサーバーインスタンスの表が表示されます。
  2. Available Server Configurations テーブルよりサーバーインスタンスを選択します。
  3. 選択したサーバーの詳細の上にある Edit ボタンをクリックします。
  4. 設定属性を変更します。
  5. Save をクリックして終了します。
結果

サーバー設定が変更され、サーバーが次回再起動したときに変更が反映されます。

3.4.7. 管理コンソールでのデプロイメントの追加

  1. コンソールの上部より Runtime タブを選択します。
  2. スタンドアロンサーバーの場合は、Server メニューを展開し、Manage Deployments を選択します。管理対象ドメインの場合は、Domain メニューを展開し、Manage Deployments を選択します。Manage Deployments パネルが表示されます。
  3. Content Repository タブの Add を選択します。Create Deployment ダイアログボックスが表示されます。
  4. ダイアログボックスの Browse をクリックします。デプロイするファイルを選択し、アップロードします。Next をクリックして作業を続行します。
  5. Create Deployments ダイアログボックスに表示されるデプロイメント名とランタイム名を確認します。名前を確認したら、Save をクリックし、ファイルをアップロードします。
結果

選択したコンテンツがサーバーにアップロードされ、デプロイメント可能になります。

3.4.8. 管理コンソールでのサーバーの新規作成

手順3.3 サーバー設定の新規作成

  1. 管理コンソールの Server Configurations ページへの移動

    コンソールの上部にある Domain タブを選択します。
  2. 設定の新規作成

    1. Available Server Configuration の表の上にある Add ボタンを選択します。
    2. Create Server Configuration ダイアログで基本的なサーバー設定を入力します。
    3. Save ボタンを選択して、新しいサーバー設定を保存します。
結果

新しいサーバーが作成され、Server Configurations リストに表示されます。

3.4.9. 管理コンソールを使用したデフォルトログレベルの変更

手順3.4 ロギングレベルの編集

  1. 管理コンソールの Logging パネルへの移動

    1. 管理対象ドメインを使用している場合は、コンソールの上部にある Configuration タブを選択した後、コンソールの左側にあるドロップダウンリストから該当するプロファイルを選択します。
    2. 管理対象ドメインまたはスタンドアロンサーバーのどちらの場合でも、コンソールの左側にあるリストの Core メニューを展開し、Logging エントリーをクリックします。
    3. コンソール上部の Log Categories タグをクリックします。
  2. ロガー詳細の編集

    Log Categories テーブル内のエントリーの詳細を編集します。
    1. Log Categories の表のエントリーを選択し、下にある Details セクションの Edit をクリックします。
    2. Log Level ドロップダウンボックスでカテゴリーのログレベルを設定します。設定したら、Save ボタンをクリックします。
結果

該当するカテゴリーのログレベルが更新されます。

3.4.10. 管理コンソールでのサーバーグループの新規作成

手順3.5 サーバーグループの新規作成および追加

  1. Server Groups ビューへの移動

    コンソールの上部にある Domain タブを選択します。
  2. 左側の列にあるメニューの Server ラベルを展開します。Server Groups を選択します。
  3. サーバーグループの追加

    Add ボタンをクリックし新規サーバーグループを追加します。
  4. サーバーグループの設定

    1. サーバーグループ名を入力します。
    2. サーバーグループのプロファイルを選択します。
    3. サーバーグループのソケットバインディングを選択します。
    4. Save ボタンをクリックし、新たに作成したグループを保存します。
結果

新規サーバーグループが管理コンソールに表示されるようになります。

3.4.11. 管理コンソールのログの表示

JBoss EAP 6 管理コンソールではサーバーログおよびアプリケーションログを表示できるため、エラー、パフォーマンスの問題、およびその他の問題の診断が容易になりました。管理コンソールログビューアーでログを表示可能にするには、ログをサーバーの jboss.server.log.dir ディレクトリーに置く必要があります。JBoss EAP 6 ログビューアーはユーザーの RBAC ロール割り当てを考慮するため、管理コンソールにログインしたユーザーはアクセス権限のあるログのみを表示できます。

手順3.6 管理コンソールでの JBoss EAP 6 ログの表示

  1. 管理コンソールの最上部から Runtime タブを選択します。
    1. 管理対象ドメインを使用している場合は、左側のメニューにある Change Server ボタンを使用してログを表示する JBoss EAP 6 サーバーを選択します。
  2. 左側の Platform メニューを展開し、Log Viewer を選択します。
  3. リストからログファイルを選択し、View ボタンをクリックします。
    また、Download をクリックして、ログファイルをローカルマシンにダウンロードすることもできます。

    注記

    15MB よりも大きいログファイルを開こうとした場合は、管理コンソールログビューアーによって確認メッセージが表示されます。
    管理コンソールログビューアーは、非常に大きいログファイル (>100MB) を表示するテキストエディターを置き換えることを目的としません。管理コンソールログビューアーで非常に大きいログファイルを開くと、Web ブラウザーがクラッシュすることがあります。このような大きいログファイルは常に個別にダウンロードし、テキストエディターで開く必要があります。
  4. 選択されたログは、管理コンソール内で新しいタブとして開きます。複数のログファイルを他のタブで開くには、LOG FILES タブに戻り、前の手順を繰り返します。

3.4.12. 管理コンソールのカスタマーポータル統合

access.redhat.com インターフェースを使用すると、JBoss EAP インストールの管理コンソールを離れずに Red Hat カスタマーポータルのセクションを参照できます。
管理コンソールの上部にあるナビゲーションバーには、Red Hat Access というドロップダウンメニューが含まれています。このメニューをクリックすると、カスタマーポータルの 3 つのタスク固有リンクが表示されます。
  • Search Customer Portal
  • Open Case
  • Modify Case
これらの各リンクの機能については、以下で詳しく説明しています。

注記

これらいずれかのリンクをクリックしたときにまだカスタマーポータルにログインしていない場合は、ダイアログが表示され、ログインするよう求められます。管理コンソールにアクセスするために使用しているブラウザーセッションでカスタマーポータルにログインする必要があります。あるブラウザーでカスタマーポータルにログインし、別のブラウザーを使用して管理コンソールにアクセスした場合は、ログインするよう求められます。

Search Customer Portal

Search Customer Portal をクリックすると、検索ボックスを含むページが表示されます。検索用語またはフレーズを入力してナレッジベース記事を見つけることができます。
検索を実行したら、結果のリストからアイテムを選択し、別のペインに表示された記事全体を参照できます。

Open Case

Open Case ページでは、新しいサポートケースを開くことができます。
新しいサポートケースを開くために使用するフォームが表示されます。フォームの横に、推奨ナレッジベース記事のリストが表示されます。このリストはサポートケースに提供された詳細に基いて更新されます。

Modify Case

Modify Case ページでは、既存のサポートケースを参照および変更できます。
結果は、検索をグループケースまたは非グループケースに制限したり、ケースの状態 (オープン、クローズ、またはいずれか) を使用したりして絞り込むことができます。
特定のサポートケースを選択した後で、サポートケースの詳細を参照または更新し、コメントを追加できます。

3.5. 管理 CLI

3.5.1. 管理コマンドラインインターフェース (CLI)

管理コマンドラインインターフェース (CLI) は、JBoss EAP 6 のコマンドライン管理ツールです。
管理 CLI を使用して、サーバーの起動および停止、アプリケーションのデプロイおよびアンデプロイ、システムの設定、他の管理タスクの実行を行います。操作はバッチモードで実行でき、複数のタスクをグループとして実行できます。

3.5.2. 管理 CLI の起動

手順3.7 Linux または Microsoft Windows Server での CLI の起動

    • Linux での CLI の起動

      コマンドラインで以下のコマンドを入力して、EAP_HOME/bin/jboss-cli.sh ファイルを実行します。
      $ EAP_HOME/bin/jboss-cli.sh
    • Microsoft Windows Server での CLI の起動

      ダブルクリックするか、コマンドラインで以下のコマンドを入力して、EAP_HOME\bin\jboss-cli.bat ファイルを実行します。
      C:\>EAP_HOME\bin\jboss-cli.bat

3.5.3. 管理 CLI の終了

管理 CLI で、quit コマンドを入力します。
[domain@localhost:9999 /] quit

3.5.4. 管理 CLI を使用した管理対象サーバーインスタンスへの接続

手順3.8 管理対象サーバーインスタンスへの接続

  • connect コマンドの実行

    管理 CLI で、connect コマンドを入力します。
    [disconnected /] connect
    Connected to domain controller at localhost:9999
    • Linux システムで管理 CLI を起動するときに管理対象サーバーへ接続するには、--connect パラメーターを使用します。
      $ EAP_HOME/bin/jboss-cli.sh --connect
    • --connect パラメーターは、ホストとサーバーのポートを指定するために使用できます。ポートの値が 9999 であるアドレス 192.168.0.1 に接続するには、次のコマンドを使用します。
      $ EAP_HOME/bin/jboss-cli.sh --connect --controller=192.168.0.1:9999

3.5.5. 管理 CLI でのヘルプの取得

概要

CLI コマンドを学ぶ必要がある場合や何を行ったらいいかわからない場合に、ガイダンスが必要になることがあります。管理 CLI には、一般的なオプションと状況依存オプションから構成されるヘルプダイアログが組み込まれてます (処理状況に依存するヘルプコマンドでは、スタンドアロンまたはドメインコントローラーへの接続を確立する必要があります。接続が確立されない限り、これらのコマンドはリストに表示されません)。

  1. 一般的なヘルプの場合

    管理 CLI で、help コマンドを入力します。
    [standalone@localhost:9999 /] help
  2. 状況依存ヘルプの取得

    管理 CLI で、help -commands 拡張コマンドを入力します。
    [standalone@localhost:9999 /] help --commands
  3. 特定のコマンドの詳細な説明については、そのコマンドとその後に --help を入力してください。
    [standalone@localhost:9999 /] deploy --help
結果

CLI ヘルプ情報が表示されます。

3.5.6. バッチモードでの管理 CLI の使用

概要

バッチ処理により、複数の操作をシーケンスでグループ化し、ユニットとして一緒に実行できます。シーケンス内のいずれかの操作要求が失敗したら、操作のグループ全体がロールバックされます。

注記

バッチモードは条件付きステートメントをサポートしません。

手順3.9 バッチモードのコマンドおよび操作

  1. バッチモードの開始

    batch コマンドを使用してバッチモードを開始します。
    [standalone@localhost:9999 /] batch
    [standalone@localhost:9999 / #]
    バッチモードは、プロンプトでハッシュ記号 (#) で示されます。
  2. バッチへの操作要求の追加

    バッチモードが開始されたら、操作要求を通常どおり入力します。操作要求は、入力された順序でバッチに追加されます。
    操作要求のフォーマット化の詳細については、「管理 CLI での操作およびコマンドの使用」 を参照してください。
  3. バッチの実行

    操作要求のシーケンス全体が入力されたら、run-batch コマンドを使用してバッチを実行します。
    [standalone@localhost:9999 / #] run-batch
    The batch executed successfully.
    バッチの作業に使用できるコマンドの完全リストについては、「CLI のバッチモードコマンド」 を参照してください。
  4. 外部ファイルに保存されたバッチコマンド

    頻繁に実行するバッチコマンドは、外部のテキストファイルに保存できます。これらのバッチコマンドをロードするには、ファイルへのフルパスを引数として batch コマンドに渡すか、run-batch コマンドの引数として直接実行します。
    テキストエディターを使用してバッチコマンドファイルを作成できます。1 行に 1 つのコマンドのみがあるようにし、CLI がコマンドにアクセスできる必要があります。
    次のコマンドは、バッチモードで myscript.txt ファイルをロードします。このファイルのすべてのコマンドは編集または削除できます。新しいコマンドを挿入できます。このバッチセッションで変更された内容は myscript.txt ファイルへ保持されません。
    [standalone@localhost:9999 /] batch --file=myscript.txt
    次のコマンドは、myscript.txt ファイルに保存されたバッチコマンドを即時実行します。
    [standalone@localhost:9999 /] run-batch --file=myscript.txt
結果

操作要求の入力されたシーケンスはバッチとして完了します。

3.5.7. CLI のバッチモードコマンド

下表は JBoss EAP 6 の CLI で使用できる有効なバッチコマンドのリストになります。これらのコマンドはバッチの作業のみに使用できます。

表3.2 CLI のバッチモードコマンド

コマンド名 説明
list-batch 現在のバッチのコマンドおよび操作のリスト
edit-batch-line line-number edited-command 編集する行番号と edited コマンドを提供し、現在のバッチの行を編集します。例: edit-batch-line 2 data-source disable --name=ExampleDS
move-batch-line fromline toline 移動したい行の番号を最初の引数として指定し、移動先を 2 番目の引数として指定してバッチの行の順序を変更します。例: move-batch-line 3 1
remove-batch-line linenumber 特定の行でバッチコマンドを削除します。例: remove-batch-line 3
holdback-batch [batchname]
このコマンドを使用すると現在のバッチを延期または保存できます。バッチの外部にて急に CLI で実行するものがある場合にこのコマンドを使用します。保留したバッチへ戻るには、再度 CLI コマンドラインに batch を入力します。
holdback-batch コマンドの使用中にバッチ名を指定すると、バッチがその名前で保存されます。名前が付けられたバッチに戻るには、batch batchname コマンドを使用します。バッチ名を指定せずに batch コマンドを呼び出すと、新しい (名前のない) バッチが開始されます。名前のない保留バッチは 1 つのみ存在できます。
保留されたバッチをすべて一覧表示するには、batch -l コマンドを使用します。
discard-batch 現在アクティブなバッチを破棄します。

3.5.8. 管理 CLI での操作およびコマンドの使用

手順3.10 要求の作成、設定、および実行

  1. 操作要求の構築

    操作要求では、管理モデルとの低レベルの対話が可能です。この場合、サーバー設定を制御された方法で編集できます。操作要求は、以下の 3 つの部分から構成されます。
    • スラッシュ (/) で始まるアドレス
    • コロン (:) で始まる操作名
    • 丸かっこ「()」で囲まれたパラメーターのオプションセット。
    1. アドレスの決定

      設定はアドレス指定可能なリソースの階層ツリーとして表されます。各リソースノードは、異なる操作セットを提供します。アドレスは、操作を実行するリソースノードを指定します。アドレスでは以下の構文を使用します。
      /node-type=node-name
      • node-type は、リソースノードタイプです。これは、設定 XML の要素名に対してマッピングされます。
      • node-name はリソースノード名です。これは、設定 XML の要素の name 属性に対してマッピングされます。
      • スラッシュ (/) を使用してリソースツリーの各レベルを区切ります。
      設定 XML ファイルを参照して必要なアドレスを決定します。EAP_HOME/standalone/configuration/standalone.xml ファイルはスタンドアロンサーバーの設定を保持し、EAP_HOME/domain/configuration/domain.xml ファイルと EAP_HOME/domain/configuration/host.xml ファイルは管理対象ドメインの設定を保持します。

      注記

      ドメインモードで CLI コマンドを実行するには、ホストとサーバーを指定する必要があります (例: /host=master/server=server-one/subsystem=logging)。

      例3.3 操作アドレスの例

      ロギングサブシステムで操作を実行するには、操作要求に以下のアドレスを使用します。
      /subsystem=logging
      Java データソースに対して操作を実行するには、操作要求に以下のアドレスを使用します。
      /subsystem=datasources/data-source=java
    2. 操作の決定

      リソースノードのタイプによって操作は異なります。操作では以下の構文を使用します。
      :operation-name
      • operation-name は、要求する操作の名前です。
      利用可能な操作をリストするために、スタンドアロンサーバーの任意のリソースアドレスで read-operation-names 操作を使用します。

      例3.4 利用可能な操作

      ロギングサブシステムのすべての利用可能な操作をリストするために、スタンドアロンサーバーの以下の要求を入力します。
      [standalone@localhost:9999 /] /subsystem=logging:read-operation-names
      {
          "outcome" => "success",
          "result" => [
              "add",
              "read-attribute",
              "read-children-names",
              "read-children-resources",
              "read-children-types",
              "read-operation-description",
              "read-operation-names",
              "read-resource",
              "read-resource-description",
              "remove",
              "undefine-attribute",
              "whoami",
              "write-attribute"
          ]
      }
    3. パラメーターの決定

      各操作では異なるパラメーターが必要な場合があります。
      パラメーターは以下の構文を使用します。
      (parameter-name=parameter-value)
      • parameter-name は、パラメーターの名前です。
      • parameter-value は、パラメーターの値です。
      • 複数のパラメーターは、カンマ (,) で区切られます。
      必要なパラメーターを決定するには、リソースノードで操作名をパラメーターとして渡し、read-operation-description コマンドを実行します。詳細については、例3.5「操作パラメーターの決定」 を参照してください。

      例3.5 操作パラメーターの決定

      ロギングサブシステムで read-children-types 操作に必須のパラメーターを決定するには、以下のように read-operation-description コマンドを入力します。
      [standalone@localhost:9999 /] /subsystem=logging:read-operation-description(name=read-children-types)
      {
          "outcome" => "success",
          "result" => {
              "operation-name" => "read-children-types",
              "description" => "Gets the type names of all the children under the selected resource",
              "reply-properties" => {
                  "type" => LIST,
                  "description" => "The children types",
                  "value-type" => STRING
              },
              "read-only" => true
          }
      }
  2. 完全操作要求の入力

    アドレス、操作、およびパラメーターが決定されたら、完全操作要求を入力します。

    例3.6 操作要求の例

    [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(recursive=true)
結果

管理インターフェースは、サーバー設定の操作要求を実行します。

3.5.9. 管理 CLI 設定オプション

管理 CLI 設定ファイルである jboss-cli.xml は、CLI が起動するたびにロードされます。このファイルは、$EAP_HOME/bin ディレクトリーまたは jboss.cli.config システムプロパティーで指定されたディレクトリーに置く必要があります。
default-controller
connect コマンドがパラメーターなしで実行された場合に接続するコントローラーの設定。

default-controller パラメーター

host
コントローラーのホスト名。デフォルト値は localhost です。
port
コントローラーへ接続するポート番号。
validate-operation-requests
実行のため要求がコントローラーへ送信される前に操作要求のパラメーターリストが検証されるかどうかを示します。タイプはブール値で、デフォルト値は true です。
history
この要素には、コマンドおよび操作の履歴ログの設定が含まれます。

history パラメーター

enabled
history が有効であるかを示します。タイプはブール値で、デフォルト値は true です。
file-name
履歴が保存されるファイルの名前。デフォルト値は .jboss-cli-history です。
file-dir
履歴が保存されるディレクトリーの名前。デフォルト値は $USER_HOME です。
max-size
履歴ファイルの最大サイズ。デフォルト値は 500 です。
resolve-parameter-values
操作要求を送信する前にコマンド引数 (または操作パラメーター) として指定されたシステムプロパティーを解決するか、またはサーバー側で解決が発生するようにするか。タイプはブール値で、デフォルト値は false です。
connection-timeout
コントローラーと接続を確立するまでの許容時間。タイプは整数で、デフォルト値は 5000 秒です。
ssl
この要素には、SSL に使用されるキーストアとトラストストアの設定が含まれます。

警告

Red Hat では、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSL を明示的に無効化することを推奨しています。

ssl パラメーター

vault
タイプ: vaultType
key-store
タイプ: 文字列
key-store-password
タイプ: 文字列
alias
タイプ: 文字列
key-password
タイプ: 文字列
trust-store
タイプ: 文字列
trust-store-password
タイプ: 文字列
modify-trust-store
true に設定された場合、認識できない証明書を受信したときに CLI がユーザーに伝え、トラストストアへの保存を許可します。タイプはブール値で、デフォルト値は true です。

vaultType

codemodule の両方が指定されていない場合は、デフォルトの実装が使用されます。code が指定され、module が指定されていない場合は、Picketbox モジュールの指定されたクラスを探します。modulecode両方指定されている場合は、module によって指定されたモジュールで code によって指定されたクラスを探します。
code
タイプ: 文字列
module
タイプ: 文字列
silent
情報およびエラーメッセージをターミナルに出力するかを指定します。false に指定されても、設定が許可したり、> を使用して出力ターゲットがコマンドラインの一部であると指定された場合は、ロガーを使用してメッセージがログに記録されます。デフォルト値は False です。

3.5.10. 管理 CLI コマンドのリファレンス

概要

トピック「管理 CLI でのヘルプの取得」では、一般オプションおよび状況依存オプションとのヘルプダイアログを含む管理 CLI ヘルプ機能にアクセスする方法について説明しています。ヘルプコマンドは、操作コンテキストに依存し、スタンドアロンまたはドメインコントローラへの確立された接続を必要とします。接続が確立されない限り、これらのコマンドはリストに表示されません。

表3.3

コマンド 説明
batch 新しいバッチを作成してバッチモードを開始するか、既存の保留中のバッチに応じて、バッチを再びアクティベートします。保留中のバッチがない場合は、引数なしで呼び出されたこのコマンドによって新しいバッチが開始されます。名前がない保留中のバッチがある場合は、このコマンドによってそのバッチが再びアクティベートされます。名前がある保留中のバッチがある場合は、保留中のバッチの名前を引数にしてこのコマンドを実行することにより、これらのバッチをアクティベートできます。
cd 現在のノードパスを引数に変更します。現在のノードパスはアドレス部分を含まない操作要求のアドレスとして使用されます。操作要求にアドレスが含まれる場合、そのアドレスは現在のノードパスに対して相対的であると見なされます。現在のノードパスは node-type で終わることがあります。その場合は、logging:read-resource などの node-name を指定すれば操作を実行できます。
clear 画面を消去します。
command 新しいタイプコマンドを追加し、既存の汎用タイプコマンドを削除およびリストできます。汎用タイプコマンドは、特定のノードタイプに割り当てられたコマンドであり、そのタイプのインスタンス向けの操作を実行可能にします。また、既存インスタンスのタイプにより公開された任意のプロパティーを変更することもできます。
connect 指定されたホストおよびポートのコントローラに接続します。
connection-factory 接続ファクトリーを定義します。
data-source データソースサブシステムで JDBC データソース設定を管理します。
deploy ファイルパスで指定されたアプリケーションをデプロイするか、リポジトリーで無効になっている既存のアプリケーションを有効にします。引数なしで実行された場合、既存のデプロイメントすべてがリストされます。
echo
JBoss EAP 6.4 以降で利用可能になった echo コマンドは指定されたテキストをコンソールに出力します。このテキストはそのまま出力されるため、変数は使用できません。
例:
echo Phase one complete
help ヘルプメッセージを表示します。該当するコマンドの状況依存の結果を提供するには、--commands 引数とともに使用します。
history メモリー内の CLI コマンド履歴を表示し、履歴拡張が有効または無効であるかを表示します。必要に応じて履歴拡張をクリア、無効、および有効にするには、引数とともに使用します。
jms-queue メッセージングサブシステムで JMS キューを定義します。
jms-topic メッセージングサブシステムで JMS トピックを定義します。
ls ノードパスの内容をリストします。デフォルトでは、ターミナルの幅全体を使用して結果が列に出力されます。-l スイッチを使用すると、1 行ごとに 1 つの名前で結果が出力されます。
pwd 現在動作しているノードの完全ノードパスを出力します。
quit コマンドラインインターフェースを終了します。
read-attribute 値を出力し、引数によっては管理対象リソースの属性の説明も出力します。
read-operation 指定された操作の説明を表示します。指定された操作がない場合は利用可能なすべての操作をリストします。
undeploy 目的のアプリケーションの名前で実行された場合にアプリケーションをアンデプロイします。リポジトリーからアプリケーションを削除するには引数とともに使用します。アプリケーションを指定せずに実行すると、既存のデプロイメントすべてをリストします。
version アプリケーションサーバーのバージョンと環境情報を出力します。
xa-data-source データソースサブシステムで JDBC XA データソース設定を管理します。

3.5.11. 管理 CLI 操作のリファレンス

管理 CLI の操作の公開

管理 CLI の操作は、トピック「管理 CLI を使用した操作名の表示」で解説している read-operation-names を使用すると公開できます。また、操作の説明は、トピック「管理 CLI を使用した操作説明の表示」で解説している read-operation-descriptions 操作を使用すると表示できます。

表3.4 管理 CLI の操作

操作名 説明
add-namespace namespaces 属性のマップに名前空間接頭辞のマッピングを追加します。
add-schema-location schema-locations 属性のマップにスキーマロケーションマッピングを追加します。
delete-snapshot snapshots ディレクトリーからサーバー設定のスナップショットを削除します。
full-replace-deployment 以前にアップロードされたデプロイメントコンテンツを使用可能なコンテンツの一覧に追加して、ランタイムの同名の既存コンテンツを置き換え、その置き換えられたコンテンツを使用可能なコンテンツの一覧から削除します。詳細については、リンク先を参照してください。
list-snapshots snapshots ディレクトリーに保存されているサーバー設定のスナップショットを一覧表示します。
read-attribute 選択したリソースの属性値を表示します。
read-children-names 指定タイプの選択したリソース配下にあるすべての子リソースの名前を表示します。
read-children-resources 指定のタイプであるすべての子リソースに関する情報を表示します。
read-children-types 選択したリソースの配下にあるすべての子リソースのタイプ名を表示します。
read-config-as-xml 現在の設定を読み込み、XML 形式で表示します。
read-operation-description 特定のリソースに対する操作の詳細を表示します。
read-operation-names 特定のリソースに対する全操作の名前を表示します。
read-resource モデルリソースの属性値および任意の子リソースの基本情報もしくは詳細情報を表示します。
read-resource-description リソースの属性、子リソースのタイプ、および操作についての詳細を表示します。
reload 全サービスをシャットダウンして再起動することにより、サーバーを再ロードします。
remove-namespace namespaces 属性マップから名前空間接頭辞のマッピングを削除します。
remove-schema-location schema-locations 属性マップからスキーマロケーションマッピングを削除します。
replace-deployment ランタイムの既存コンテンツを新規コンテンツに置き換えます。新規コンテンツはデプロイメントコンテンツリポジトリに事前にアップロードしておく必要があります。
resolve-expression 式を、式へ解析可能な入力または文字列として許可し、ローカルのシステムプロパティーおよび環境変数に対して解決する操作です。
resolve-internet-address インターフェース解決基準のセットを取得し、基準に一致するローカルマシンで IP アドレスを見つけます。一致する IP アドレスがない場合は失敗します。
server-set-restart-required 再起動が必要なモードにサーバーを設定します。
shutdown System.exit(0) の呼び出しにより、サーバーをシャットダウンします。
start-servers 現在実行されていないすべての設定済みサーバーを管理対象ドメインで起動します。
stop-servers 管理対象ドメインで現在実行しているすべてのサーバーを停止します。
take-snapshot サーバー設定のスナップショットを作成し、snapshots ディレクトリーに保存します。
upload-deployment-bytes 含まれるバイト配列のデプロイメントコンテンツは、デプロイメントコンテンツリポジトリーに追加する必要があることを示します。この操作は、コンテンツをランタイムへデプロイする必要があるとは示さない点に注意してください。
upload-deployment-stream 含まれる入力ストリームインデックスで利用可能なデプロイメントコンテンツは、デプロイメントコンテンツリポジトリーに追加する必要があることを示します。この操作は、コンテンツをランタイムにデプロイする必要があるとは示さない点に注意してください。
upload-deployment-url 含まれる URL で利用可能なデプロイメントコンテンツはデプロイメントコンテンツリポジトリーに追加する必要があることを示します。この操作は、コンテンツをランタイムにデプロイする必要があるとは示さない点に注意してください。
validate-address 操作のアドレスを検証します。
write-attribute 選択したリソースの属性値を設定します。

3.5.12. 管理 CLI でのプロパティー置換

JBoss EAP 6 は、管理コマンドラインインターフェースで事前に設定された要素とプロパティー式の使用をサポートします。これらの式は、コマンドの実行中に、定義された値に解決されます。
以下のプロパティーは、式で置換できます。
  • 操作要求の操作アドレス部分 (ノードタイプまたはノード名、あるいはその両方)
  • 操作名
  • 操作パラメーター名
  • ヘッダー名および値
  • コマンド名
  • コマンド引数名
デフォルトでは、CLI は引数値またはパラメーター値を除く、各行のプロパティー置換を実行します。引数およびパラメーター値は、実行時にサーバーで解決されます。引数またはパラメーター値のプロパティー置換を管理 CLI クライアントで行い、解決された値をサーバーに送信する必要がある場合は、以下の手順を実行してください。

手順3.11 管理 CLI でのプロパティー置換の有効化

  1. ファイル EAP_HOME/bin/jboss-cli.xml を開きます。
  2. resolve-parameter-values パラメーターを探し、値を true に変更します (デフォルト値は false)。
    <!-- whether to resolve system properties specified as command argument or operation parameter values in the Management CLI VM before sending the operation requests to the controller -->
        <resolve-parameter-values>true</resolve-parameter-values>
    
この要素は、操作要求パラメーター値とコマンド引数値のみに影響を与えます。残りのコマンドラインには影響を与えません。つまり、コマンドラインにあるシステムプロパティーは、resolve-parameter-values 要素の値に関係なく行の解析中に解決されます (パラメーター/引数値でない限り)。
他の管理 CLI 設定オプションについては、「管理 CLI 設定オプション」を参照してください。
管理 CLI コマンドで使用されたシステム値はすでに定義されている必要があることに注意してください。管理 CLI インスタンスを起動するときは、--properties=/path/to/file.properties 引数あるいは 1 つまたは複数の -Dkey=VALUE パラメーターを含める必要があります。プロパティーファイルでは、標準的な key=value 構文を使用します。
プロパティーキーは、管理 CLI コマンドで構文 ${MY_VAR} を使用して表されます。

例3.7 例: 管理 CLI コマンドでのプロパティーの使用

/subsystem=datasources/data-source=${datasourcename}:add(connection-url=jdbc:oracle:thin:@server:1521:ora1, jndi-name=java:/jboss/${name}, driver-name=${drivername})

3.6. 管理 CLI の操作

3.6.1. 管理 CLI によるリソースの属性の表示

概要

read-attribute 操作は、選択した属性の現在のランタイム値を読み取るために使用されるグローバル操作です。この操作を使用すると、デフォルトの値や非定義の値を無視し、ユーザーが設定した値のみを表示できます。要求プロパティーには次のパラメーターが含まれます。

要求プロパティー

name
選択したリソース下で値を取得する属性の名前。
include-defaults
false を設定すると、デフォルト値を無視し、ユーザーが設定した属性のみを表示するよう操作結果を制限できるブール値パラメーター。

手順3.12 選択した属性の現在のランタイム値を表示

  • read-attribute 操作の実行

    管理 CLI より read-attribute を使用してリソース属性の値を表示します。操作要求の詳細については、「管理 CLI での操作およびコマンドの使用」を参照してください。
    [standalone@localhost:9999 /]:read-attribute(name=name-of-attribute)
read-attribute 操作の利点は、特定属性の現在のランタイム値を表示できることです。read-resource 操作でも同様の結果を得ることができますが、include-runtime 要求プロパティーを追加した場合のみ可能で、そのノードに対して使用できる全リソース一覧の一部のみを表示できます。次の例が示すように、read-attribute 操作は粒度の細かい属性クエリを対象としています。

例3.8 read-attribute 操作を実行したパブリックインターフェース IP の表示

表示したい属性の名前が分かる場合は、read-attribute を使用して現在のランタイムの厳密値を返します。
[standalone@localhost:9999 /] /interface=public:read-attribute(name=resolved-address)
{
    "outcome" => "success",
    "result" => "127.0.0.1"
}
resolved-address 属性はランタイム値であるため、標準的な read-resource 操作の結果には表示されません。
[standalone@localhost:9999 /] /interface=public:read-resource                        
{
    "outcome" => "success",
    "result" => {
        "any" => undefined,
        "any-address" => undefined,
        "any-ipv4-address" => undefined,
        "any-ipv6-address" => undefined,
        "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
        "link-local-address" => undefined,
        "loopback" => undefined,
        "loopback-address" => undefined,
        "multicast" => undefined,
        "name" => "public",
        "nic" => undefined,
        "nic-match" => undefined,
        "not" => undefined,
        "point-to-point" => undefined,
        "public-address" => undefined,
        "site-local-address" => undefined,
        "subnet-match" => undefined,
        "up" => undefined,
        "virtual" => undefined
    }
}
resolved-address や他のランタイム値を表示するには、include-runtime 要求プロパティーを使用する必要があります。
[standalone@localhost:9999 /] /interface=public:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "any" => undefined,
        "any-address" => undefined,
        "any-ipv4-address" => undefined,
        "any-ipv6-address" => undefined,
        "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
        "link-local-address" => undefined,
        "loopback" => undefined,
        "loopback-address" => undefined,
        "multicast" => undefined,
        "name" => "public",
        "nic" => undefined,
        "nic-match" => undefined,
        "not" => undefined,
        "point-to-point" => undefined,
        "public-address" => undefined,
        "resolved-address" => "127.0.0.1",
        "site-local-address" => undefined,
        "subnet-match" => undefined,
        "up" => undefined,
        "virtual" => undefined
    }
}
結果

現在のランタイム属性値が表示されます。

3.6.2. 管理 CLI でのアクティブユーザーの表示

概要

whoami の操作は、現在アクティブなユーザーの属性を識別するために使用されるグローバルな操作です。この操作はユーザー名の ID と割り当てられたレルムを表示します。whoami の操作は、管理者が複数のレルムで複数のユーザーを管理する場合や、複数のターミナルセッションやユーザーアカウントを持つドメインインスタンス全体でアクティブユーザーを追跡する場合に便利です。

手順3.13 whoami を使用した管理 CLI でのアクティブユーザーの表示

  • whoami の実行

    管理 CLI より whoami を使用し、アクティブなユーザーのアカウントを表示します。
    [standalone@localhost:9999 /] :whoami
    次の例はスタンドアロンサーバーで whoami を使用し、アクティブなユーザーは usernameManagementRealm レルムが割り当てられていることを表しています。

    例3.9 スタンドアロンインスタンスでの whoami の使用

    [standalone@localhost:9999 /]:whoami
    {
        "outcome" => "success",
        "result" => {"identity" => {
            "username" => "username",
            "realm" => "ManagementRealm"
        }}
    }
    
結果

現在アクティブなユーザーのアカウントが表示されます。

3.6.3. 管理 CLI でのシステムおよびサーバー情報の表示

手順3.14 管理 CLI でのシステムおよびサーバー情報の表示

  • version コマンドの実行

    管理 CLI で、version コマンドを入力します。
    [domain@localhost:9999 /] version
結果

アプリケーションサーバーのバージョンと環境情報が表示されます。

3.6.4. 管理 CLI を使用した操作説明の表示

手順3.15 管理 CLI でのコマンドの実行

  • read-operation-description 操作の実行

    管理 CLI で、read-operation-description を使用して、操作に関する情報を表示します。操作ではキーと値のペアの形式でパラメーターを追加して、表示する操作を示す必要があります。操作結果の詳細については、「管理 CLI での操作およびコマンドの使用」 を参照してください。
    [standalone@localhost:9999 /]:read-operation-description(name=name-of-operation)

例3.10 list-snapshots 操作の説明表示

次の例は、list-snapshots 操作を説明する方法を示しています。
[standalone@localhost:9999 /] :read-operation-description(name=list-snapshots)
{
    "outcome" => "success",
    "result" => {
        "operation-name" => "list-snapshots",
        "description" => "Lists the snapshots",
        "request-properties" => {},
        "reply-properties" => {
            "type" => OBJECT,
            "value-type" => {
                "directory" => {
                    "type" => STRING,
                    "description" => "The directory where the snapshots are stored",
                    "expressions-allowed" => false,
                    "required" => true,
                    "nillable" => false,
                    "min-length" => 1L,
                    "max-length" => 2147483647L
                },
                "names" => {
                    "type" => LIST,
                    "description" => "The names of the snapshots within the snapshots directory",
                    "expressions-allowed" => false,
                    "required" => true,
                    "nillable" => false,
                    "value-type" => STRING
                }
            }
        },
        "access-constraints" => {"sensitive" => {"snapshots" => {"type" => "core"}}},
        "read-only" => false
    }
}
結果

選択した操作に関する説明が表示されます。

3.6.5. 管理 CLI を使用した操作名の表示

手順3.16 管理 CLI でのコマンドの実行

  • read-operation-names の実行

    管理 CLI より read-operation-names 操作を使用して利用可能な操作の名前を表示します。操作要求の詳細については、トピック「管理 CLI での操作およびコマンドの使用」を参照してください。
    [standalone@localhost:9999 /]:read-operation-names

例3.11 管理 CLI を使用した操作名の表示

次の例は、read-operation-names 操作を説明する方法を示しています。
[standalone@localhost:9999 /]:read-operation-names
{
    "outcome" => "success",
    "result" => [
        "add-namespace",
        "add-schema-location",
        "delete-snapshot",
        "full-replace-deployment",
        "list-snapshots",
        "read-attribute",
        "read-children-names",
        "read-children-resources",
        "read-children-types",
        "read-config-as-xml",
        "read-operation-description",
        "read-operation-names",
        "read-resource",
        "read-resource-description",
        "reload",
        "remove-namespace",
        "remove-schema-location",
        "replace-deployment",
        "resolve-expression",
        "resolve-internet-address",
        "server-set-restart-required",
        "shutdown",
        "take-snapshot",
        "undefine-attribute",
        "upload-deployment-bytes",
        "upload-deployment-stream",
        "upload-deployment-url",
        "validate-address",
        "validate-operation",
        "whoami",
        "write-attribute"
    ]
}
結果

利用可能な操作名が表示されます。

3.6.6. 管理 CLI を使用した利用可能なリソースの表示

概要

read-resource 操作は、リソース値を読み取るために使用されるグローバル操作です。この操作を使用すると、現在のノードまたは子ノードのリソースに関する基本または詳細情報や、操作結果の範囲を拡大または制限するさまざまな要求プロパティーを表示できます。要求プロパティーには、以下のパラメーターが含まれます。

要求プロパティー

recursive
子リソースに関する詳細情報を再帰的に含めるかどうか。
recursive-depth
含まれる子リソースの情報の深さ。
proxies
再帰的なクエリにリモートリソースを含めるかどうか。たとえば、ドメインコントローラーのクエリにスレーブのホストコントローラーからのホストレベルのリソースを含めること。
include-runtime
応答に、永続的な設定ではない属性値などのランタイム属性を含めるかどうか。この要求プロパティーは、デフォルトで false に設定されます。
include-defaults
デフォルト属性の読み取りを有効または無効にするブール値の要求プロパティー。false に設定された場合は、ユーザーが設定した属性のみが返され、未定義のままの属性は無視されます。

手順3.17 管理 CLI でのコマンドの実行

  1. read-resource 操作の実行

    管理 CLI で、read-resource 操作を使用して利用可能なリソースを表示します。
    [standalone@localhost:9999 /]:read-resource
    以下の例は、スタンドアロンサーバーインスタンスで read-resource 操作を使用して一般的なリソース情報を表示する方法を示しています。結果は standalone.xml 設定ファイルに類似し、サーバーインスタンス向けにインストールまたは設定されたシステムリソース、拡張機能、インターフェース、およびサブシステムを表示します。これらの情報は、さらに直接クエリーできます。

    例3.12 ルートレベルでの read-resource 操作の使用

    [standalone@localhost:9999 /]:read-resource
    {
        "outcome" => "success",
        "result" => {
            "management-major-version" => 1,
            "management-micro-version" => 0,
            "management-minor-version" => 7,
            "name" => "localhost",
            "namespaces" => [],
            "product-name" => "EAP",
            "product-version" => "6.4.0.GA",
            "profile-name" => undefined,
            "release-codename" => "Janus",
            "release-version" => "7.5.0.Final-redhat-17",
            "schema-locations" => [],
            "core-service" => {
                "service-container" => undefined,
                "server-environment" => undefined,
                "module-loading" => undefined,
                "platform-mbean" => undefined,
                "management" => undefined,
                "patching" => undefined
            },
            "deployment" => undefined,
            "deployment-overlay" => undefined,
            "extension" => {
                "org.jboss.as.clustering.infinispan" => undefined,
                "org.jboss.as.connector" => undefined,
                "org.jboss.as.deployment-scanner" => undefined,
                "org.jboss.as.ee" => undefined,
                "org.jboss.as.ejb3" => undefined,
                "org.jboss.as.jaxrs" => undefined,
                "org.jboss.as.jdr" => undefined,
                "org.jboss.as.jmx" => undefined,
                "org.jboss.as.jpa" => undefined,
                "org.jboss.as.jsf" => undefined,
                "org.jboss.as.logging" => undefined,
                "org.jboss.as.mail" => undefined,
                "org.jboss.as.naming" => undefined,
                "org.jboss.as.pojo" => undefined,
                "org.jboss.as.remoting" => undefined,
                "org.jboss.as.sar" => undefined,
                "org.jboss.as.security" => undefined,
                "org.jboss.as.threads" => undefined,
                "org.jboss.as.transactions" => undefined,
                "org.jboss.as.web" => undefined,
                "org.jboss.as.webservices" => undefined,
                "org.jboss.as.weld" => undefined
            },
            "interface" => {
                "management" => undefined,
                "public" => undefined,
                "unsecure" => undefined
            },
            "path" => {
                "jboss.server.temp.dir" => undefined,
                "user.home" => undefined,
                "jboss.server.base.dir" => undefined,
                "java.home" => undefined,
                "user.dir" => undefined,
                "jboss.server.data.dir" => undefined,
                "jboss.home.dir" => undefined,
                "jboss.server.log.dir" => undefined,
                "jboss.server.config.dir" => undefined,
                "jboss.controller.temp.dir" => undefined
            },
            "socket-binding-group" => {"standard-sockets" => undefined},
            "subsystem" => {
                "jaxrs" => undefined,
                "jsf" => undefined,
                "jca" => undefined,
                "jmx" => undefined,
                "threads" => undefined,
                "webservices" => undefined,
                "sar" => undefined,
                "remoting" => undefined,
                "infinispan" => undefined,
                "weld" => undefined,
                "ejb3" => undefined,
                "transactions" => undefined,
                "datasources" => undefined,
                "deployment-scanner" => undefined,
                "logging" => undefined,
                "jdr" => undefined,
                "pojo" => undefined,
                "jpa" => undefined,
                "naming" => undefined,
                "ee" => undefined,
                "mail" => undefined,
                "web" => undefined,
                "resource-adapters" => undefined,
                "security" => undefined
            },
            "system-property" => undefined
        }
    }
    
  2. 子ノードに対する read-resource 操作の実行

    read-resource 操作は、ルートから子ノードを問い合わせるために実行できます。操作の構造は最初に公開するノードを定義し、ノードに対して実行する操作を追加します。
    [standalone@localhost:9999 /]/subsystem=web/connector=http:read-resource
    下例では、特定の Web サブシステムノードに対して read-resource 操作を行うと、Web サブシステムコンポーネントに関する特定のリソース情報を公開できます。

    例3.13 ルートノードからの子ノードリソースの公開

    [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource                      
    {
        "outcome" => "success",
        "result" => {
            "configuration" => undefined,
            "enable-lookups" => false,
            "enabled" => true,
            "executor" => undefined,
            "max-connections" => undefined,
            "max-post-size" => 2097152,
            "max-save-post-size" => 4096,
            "name" => "http",
            "protocol" => "HTTP/1.1",
            "proxy-name" => undefined,
            "proxy-port" => undefined,
            "redirect-port" => 443,
            "scheme" => "http",
            "secure" => false,
            "socket-binding" => "http",
            "ssl" => undefined,
            "virtual-server" => undefined
        }
    }
    
    cd コマンドを使用して子ノードに移動し、read-resource 操作を直接実行しても、同じ結果を得ることができます。

    例3.14 ディレクトリーの変更による子ノードリソースの公開

    [standalone@localhost:9999 /] cd subsystem=web
    [standalone@localhost:9999 subsystem=web] cd connector=http
    [standalone@localhost:9999 connector=http] :read-resource
    {
        "outcome" => "success",
        "result" => {
            "configuration" => undefined,
            "enable-lookups" => false,
            "enabled" => true,
            "executor" => undefined,
            "max-connections" => undefined,
            "max-post-size" => 2097152,
            "max-save-post-size" => 4096,
            "name" => "http",
            "protocol" => "HTTP/1.1",
            "proxy-name" => undefined,
            "proxy-port" => undefined,
            "redirect-port" => 443,
            "scheme" => "http",
            "secure" => false,
            "socket-binding" => "http",
            "ssl" => undefined,
            "virtual-server" => undefined
        }
    }
    
  3. 再帰的なパラメーターを使用して結果にアクティブな値を含める

    再帰的なパラメーターを使用すると、すべての属性の値 (永続的でない値、起動時に渡された値、ランタイムモデルでアクティブな他の属性など) を公開できます。
    [standalone@localhost:9999 /]/interface=public:read-resource(include-runtime=true)
    以前の例と比較すると、include-runtime 要求プロパティーを含めることにより、HTTP コネクターによって送受信されたバイトなどの追加のアクティブな属性が公開されます。

    例3.15 include-runtime パラメーターを使用して追加でアクティブな値を公開

    [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(include-runtime=true)
    {
        "outcome" => "success",
        "result" => {
            "any" => undefined,
            "any-address" => undefined,
            "any-ipv4-address" => undefined,
            "any-ipv6-address" => undefined,
            "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
            "link-local-address" => undefined,
            "loopback" => undefined,
            "loopback-address" => undefined,
            "multicast" => undefined,
            "name" => "public",
            "nic" => undefined,
            "nic-match" => undefined,
            "not" => undefined,
            "point-to-point" => undefined,
            "public-address" => undefined,
            "resolved-address" => "127.0.0.1",
            "site-local-address" => undefined,
            "subnet-match" => undefined,
            "up" => undefined,
            "virtual" => undefined
        }
    }
    

3.6.7. 管理 CLI を使用した利用可能なリソース説明の表示

手順3.18 管理 CLI でのコマンドの実行

  1. read-resource-description の実行

    管理 CLI で、read-resource-description 操作を使用して利用可能なリソースを読み取り、表示します。操作要求の詳細については、トピック「管理 CLI での操作およびコマンドの使用」を参照してください。
    [standalone@localhost:9999 /]:read-resource-description
  2. オプションパラメーターの使用

    read-resource-description 操作では、追加パラメーターを使用できます。
    1. リソースの操作の説明を表示するには、operations パラメーターを使用します。
      [standalone@localhost:9999 /]:read-resource-description(operations=true)
    2. リソースの継承された操作の説明を表示または非表示にするには、inherited パラメーターを使用します。デフォルトの状態は true です。
      [standalone@localhost:9999 /]:read-resource-description(inherited=false)
    3. 子リソースの操作の再帰的な説明を表示するには、recursive パラメーターを使用します。
      [standalone@localhost:9999 /]:read-resource-description(recursive=true)
    4. リソースの説明を表示するには、locale パラメーターを使用します。null の場合は、デフォルトのロケールが使用されます。
      [standalone@localhost:9999 /]:read-resource-description(locale=true)
結果

利用可能なリソースの説明が表示されます。

3.6.8. 管理 CLI を使用したアプリケーションサーバーのリロード

管理 CLI から reload 操作を使用して、すべてのサービスをシャットダウンし、ランタイムを再起動します。reload の完了後、管理 CLI は自動的に再接続します。
操作要求の詳細については、「管理 CLI での操作およびコマンドの使用」を参照してください。

例3.16 アプリケーションのリロード

[standalone@localhost:9999 /]:reload
{"outcome" => "success"}

3.6.9. 管理 CLI を使用したアプリケーションサーバーのシャットダウン

手順3.19 アプリケーションサーバーのシャットダウン

  • shutdown 操作の実行

    • 管理 CLI で、shutdown 操作を使用し System.exit(0) システムコールを介してサーバーをシャットダウンします。操作要求の詳細については、トピック「管理 CLI での操作およびコマンドの使用」を参照してください。
      • スタンドアロンモードでは、次のコマンドを使用します。
        [standalone@localhost:9999 /]:shutdown
      • ドメインモードでは、適切なホスト名を指定して次のコマンドを使用します。
        [domain@localhost:9999 /]/host=master:shutdown
    • デタッチした CLI インスタンスへ接続し、サーバーをシャットダウンするには、次のコマンドを実行します。
      jboss-cli.sh --connect command=:shutdown
      
    • リモート CLI インスタンスへ接続し、サーバーをシャットダウンするには、次のコマンドを実行します。
      [disconnected /] connect IP_ADDRESS
      [standalone@IP_ADDRESS:9999 /] :shutdown
      
      IP_ADDRESS をインスタンスの IP アドレスに置き換えます。

注記

(restart=true) 引数を :shutdown コマンドに追加すると (以下参照)、サーバーの再起動が促されます。
[standalone@localhost:9999 /]:shutdown(restart=true)
結果

アプリケーションサーバーがシャットダウンされます。ランタイムが利用できない場合に、管理 CLI が切断されます。

3.6.10. 管理 CLI での属性の設定

概要

write-attribute 操作は、選択されたリソース属性を記述または変更するために使用するグローバル操作です。この操作を使用して永続的な変更を行い、管理対象サーバーインスタンスの設定を変更できます。要求プロパティーには以下のパラメーターが含まれます。

要求プロパティー

name
選択されたリソース下で値を設定する属性の名前。
value
選択されたリソース下の属性の必要な値。基礎となるモデルが null 値をサポートする場合は、null になることがあります。

手順3.20 管理 CLI でのリソース属性の設定

  • write-attribute 操作の実行

    管理 CLI で、write-attribute 操作を使用してリソース属性の値を変更します。操作は、完全リソースパスが指定されたリソースの子ノードまたは管理 CLI のルートノードで実行できます。

例3.17 write-attribute 操作によるデプロイメントスキャナーの無効化

以下の例では、write-attribute 操作を使用してデプロイメントスキャナーを無効にします。操作は、ルートノードから実行されます (タブ補完を使用して正しいリソースパスを入力します)。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false)
{"outcome" => "success"}
操作の結果は、read-attribute 操作を直接使用して確認できます。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-attribute(name=scan-enabled)
{
    "outcome" => "success",
    "result" => false
}
また、read-resource 操作を使用し、すべてのノードの利用可能なリソース属性をリストして結果を確認することもできます。以下の例では、scan-enabled 属性が false に設定されていることが分かります。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-resource                                 
{
    "outcome" => "success",
    "result" => {
        "auto-deploy-exploded" => false,
        "auto-deploy-xml" => true,
        "auto-deploy-zipped" => true,
        "deployment-timeout" => 600,
        "path" => "deployments",
        "relative-to" => "jboss.server.base.dir",
        "scan-enabled" => false,
        "scan-interval" => 5000
    }
}
結果

リソース属性が更新されます。

3.6.11. 管理 CLI を使用したシステムプロパティーの設定

手順3.21 管理 CLI を使用したシステムプロパティーの設定

  1. JBoss EAP サーバーを起動します。
  2. ご使用のオペレーティングシステム向けのコマンドを使用して、管理 CLI を起動します。
    Linux の場合:
    EAP_HOME/bin/jboss-cli.sh --connect
    Windows の場合:
    EAP_HOME\bin\jboss-cli.bat --connect
  3. システムプロパティーを追加します。
    使用するコマンドは、スタンドアロンサーバーと管理対象ドメインのどちらを実行しているかによって異なります。管理対象ドメインを実行している場合、ドメインで稼働しているすべてのサーバーへシステムプロパティーを追加できます。
    • 以下の構文を使用して、スタンドアロンサーバーでシステムプロパティーを追加します。
      /system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

      例3.18 システムプロパティーをスタンドアロンサーバーへ追加

      [standalone@localhost:9999 /] /system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
      {"outcome" => "success"}
    • 以下の構文を使用して、管理対象ドメインのすべてのホストおよびサーバーへシステムプロパティーを追加します。
      /system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

      例3.19 管理対象ドメインのすべてのサーバーへシステムプロパティーを追加

      [domain@localhost:9999 /] /system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {"main-server-group" => {"host" => {"master" => {
              "server-one" => {"response" => {"outcome" => "success"}},
              "server-two" => {"response" => {"outcome" => "success"}}
          }}}}
      }
    • 以下の構文を使用して、管理対象ドメインのホストおよびそのサーバーインスタンスへシステムプロパティーを追加します。
      /host=master/system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

      例3.20 システムプロパティーをドメインのホストおよびそのサーバーへ追加

      [domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {"main-server-group" => {"host" => {"master" => {
              "server-one" => {"response" => {"outcome" => "success"}},
              "server-two" => {"response" => {"outcome" => "success"}}
          }}}}
      }
    • 以下の構文を使用して、管理対象ドメインのサーバーインスタンスにシステムプロパティーを追加します。
      /host=master/server-config=server-one/system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

      例3.21 システムプロパティーを管理対象ドメインのサーバーインスタンスへ追加

      [domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {"outcome" => "success"}}}}}}
      }
      
  4. システムプロパティーを読み取ります。
    使用するコマンドは、スタンドアロンサーバーと管理対象ドメインのどちらを実行しているかによって異なります。
    • 以下の構文を使用して、スタンドアロンサーバーからシステムプロパティーを読み取ります。
      /system-property=PROPERTY_NAME:read-resource

      例3.22 スタンドアロンサーバーからシステムプロパティーの読み取り

      [standalone@localhost:9999 /] /system-property=property.mybean.queue:read-resource
      {
          "outcome" => "success",
          "result" => {"value" => "java:/queue/MyBeanQueue"}
      }
      
    • 以下の構文を使用して、管理対象ドメインのすべてのホストおよびサーバーからシステムプロパティーを読み取ります。
      /system-property=PROPERTY_NAME:read-resource

      例3.23 管理対象ドメインのすべてのサーバーからシステムプロパティーを読み取り

      [domain@localhost:9999 /] /system-property=property.mybean.queue:read-resource
      {
          "outcome" => "success",
          "result" => {
              "boot-time" => true,
              "value" => "java:/queue/MyBeanQueue"
          }
      }
    • 以下の構文を使用して、管理対象ドメインのホストおよびそのサーバーインスタンスからシステムプロパティーを読み取ります。
      /host=master/system-property=PROPERTY_NAME:read-resource

      例3.24 ドメインのホストおよびそのサーバーからシステムプロパティーを読み取り

      [domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:read-resource
      {
          "outcome" => "success",
          "result" => {
              "boot-time" => true,
              "value" => "java:/queue/MyBeanQueue"
          }
      }
      
    • 以下の構文を使用して、管理対象ドメインのサーバーインスタンスからシステムプロパティーを読み取ります。
      /host=master/server-config=server-one/system-property=PROPERTY_NAME:read-resource

      例3.25 管理対象ドメインのサーバーインスタンスからシステムプロパティーを読み取り

      [domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:read-resource
      {
          "outcome" => "success",
          "result" => {
              "boot-time" => true,
              "value" => "java:/queue/MyBeanQueue"
          }
      }
  5. システムプロパティーを削除します。
    使用するコマンドは、スタンドアロンサーバーと管理対象ドメインのどちらを実行しているかによって異なります。
    • 以下の構文を使用して、スタンドアロンサーバーからシステムプロパティーを削除します。
      /system-property=PROPERTY_NAME:remove

      例3.26 スタンドアロンサーバーからシステムプロパティーを削除

      [standalone@localhost:9999 /] /system-property=property.mybean.queue:remove
      {"outcome" => "success"}
    • 以下の構文を使用して、管理対象ドメインのすべてのホストおよびサーバーからシステムプロパティーを削除します。
      /system-property=PROPERTY_NAME:remove

      例3.27 ドメインのホストおよびそのサーバーからシステムプロパティーを削除

      [domain@localhost:9999 /] /system-property=property.mybean.queue:remove
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {"main-server-group" => {"host" => {"master" => {
              "server-one" => {"response" => {"outcome" => "success"}},
              "server-two" => {"response" => {"outcome" => "success"}}
          }}}}
      }
      
    • 以下の構文を使用して、管理対象ドメインのホストおよびそのサーバーインスタンスからシステムプロパティーを削除します。
      /host=master/system-property=PROPERTY_NAME:remove

      例3.28 ドメインのホストおよびそのインスタンスからシステムプロパティーを削除

      [domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:remove
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {"main-server-group" => {"host" => {"master" => {
              "server-one" => {"response" => {"outcome" => "success"}},
              "server-two" => {"response" => {"outcome" => "success"}}
          }}}}
      }
      
    • 以下の構文を使用して、管理対象ドメインのサーバーインスタンスからシステムプロパティーを削除します。
      /host=master/server-config=server-one/system-property=PROPERTY_NAME:remove

      例3.29 管理対象ドメインのサーバーからシステムプロパティーを削除

      [domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:remove
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {"outcome" => "success"}}}}}}
      }
      

3.7. 管理 CLI コマンド履歴

3.7.1. 管理 CLI コマンド履歴の利用

管理 CLI にはコマンドの履歴機能があり、これはアプリケーションサーバーのインストール時にデフォルトで有効になっています。この履歴はアクティブな CLI セッションの揮発性メモリーでレコードとして保持されるか、ユーザーのホームディレクトリーに .jboss-cli-history として自動的に保存されるログファイルに追加されます。この履歴ファイルはデフォルトで、CLI コマンドを最大 500 件記録できるように設定されます。
history コマンド自体は、現在のセッションの履歴を返しますが、引数を追加すると、セッションメモリーの履歴を無効化、有効化、または消去できます。管理 CLI では、キーボードの矢印キーを使用してコマンドや操作の履歴を前後に移動できます。

3.7.2. 管理 CLI コマンド履歴の表示

手順3.22 管理 CLI コマンド履歴の表示

  • history コマンドの実行

    管理 CLI で、history コマンドを入力します。
    [standalone@localhost:9999 /] history
結果

CLI の起動後または履歴削除コマンドの実行後にメモリーに格納された CLI コマンドの履歴が表示されます。

3.7.3. 管理 CLI コマンド履歴の消去

手順3.23 管理 CLI コマンド履歴の消去

  • history --clear コマンドの実行

    管理 CLI で、history --clear コマンドを入力します。
    [standalone@localhost:9999 /] history --clear
結果

CLI の起動後に記録されたコマンドの履歴がセッションメモリーから削除されます。コマンド履歴は、ユーザーのホームディレクトリーに保存された .jboss-cli-history ファイルに保持されます。

3.7.4. 管理 CLI コマンド履歴の無効化

手順3.24 管理 CLI コマンド履歴の無効化

  • history --disable コマンドの実行

    管理 CLI で、history --disable コマンドを入力します。
    [standalone@localhost:9999 /] history --disable
結果

CLI で実行されたコマンドは、メモリー内およびユーザーのホームディレクトリーに保存された .jboss-cli-history ファイルには記録されません。

3.7.5. 管理 CLI コマンド履歴の有効化

手順3.25 管理 CLI コマンド履歴の有効化

  • history --enable コマンドの実行

    管理 CLI で、history --enable コマンドを入力します。
    [standalone@localhost:9999 /] history --enable
結果

CLI で実行されたコマンドは、メモリー内およびユーザーのホームディレクトリーに保存された .jboss-cli-history ファイルに記録されます。

3.8. 管理インターフェース監査ロギング

3.8.1. 管理インターフェース監査ロギング

監査ロギングが有効な場合は、管理コンソール、管理 CLI インターフェース、またはカスタム作成管理アプリケーションを使用して実行されたすべての操作が監査ロギングの対象になります。
監査ログエントリーは、JSON 形式で格納され、お使いの設定に基いて、ファイルに格納したり、syslog サーバーに送信したりできます。監査ロギングは、管理 CLI を使用してのみ設定でき、デフォルトで無効になります。
EAP には「認証されたセッション」がないため、ログインおよびログアウトイベントは監査できません。その代わりに、ユーザーから操作を受信すると監査メッセージがログに記録されます。

注記

デフォルトでは、監査ロギングはアクティブではありません。監査ロギングは、管理 CLI からのみ設定できます。
利用可能なすべての管理インターフェース監査ロギング設定オプションとその現在の値をリストするには、以下の管理 CLI コマンドを入力します。

注記

管理対象ドメインのコマンドに接頭辞 /host=HOST_NAME を追加します。
[... /] /core-service=management/access=audit:read-resource(recursive=true)

3.8.2. ファイルに対する管理インターフェース監査ロギングの有効化

ファイルに対する監査ロギング出力を有効にするには、次の管理 CLI コマンドを入力します。

注記

管理対象ドメインに変更を適用する場合は、接頭辞 /host=HOST_NAME を以下のコマンドに追加します。
/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
管理操作のログは、以下のようにファイルに記録されます。
  • スタンドアロンモード: EAP_HOME/standalone/data/audit-log.log
  • ドメインモード: EAP_HOME/domain/data/audit-log.log
すべてのファイルハンドラー属性の詳細については、「管理インターフェース監査ロギングリファレンス」を参照してください。

3.8.3. syslog サーバーへの管理インターフェース監査ロギングの有効化

有効な場合、デフォルトでは、監査ロギングはファイルに出力するよう事前設定されます。この手順では、syslog サーバーへの出力が設定され、ファイルへの監査ロギングが有効になります。すべての syslog ハンドラー属性の詳細については、「管理インターフェース監査ロギングリファレンス」を参照してください。

注記

管理対象ドメインに変更を適用する場合は、接頭辞 /host=HOST_NAME/core-service コマンドに追加します。

手順3.26 syslog サーバーへの監査ロギングの有効化

  1. 監査ロギングの有効化

    以下のコマンドを実行します。
    [.. /]/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
  2. syslog ハンドラーの作成

    この例では、 syslog サーバーが JBoss EAP インスタンスと同じサーバーでポート 514 において実行されています。host 属性の値をお使いの環境に適切な値に置き換えてください。

    例3.30 syslog ハンドラーの例

    [.. /]batch
    [.. / #]/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
    [.. / #]/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
    [.. /]run-batch
  3. syslog ハンドラーへの参照の追加

    以下のコマンドを実行します。
    [.. /]/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add
結果

管理インターフェースの監査ログエントリーが syslog サーバーに記録されます。

3.8.4. 管理インターフェース監査ログを読む

ファイルに出力される監査ログエントリーは、テキストビューアーで参照することをお勧めします。syslog サーバーに出力される監査ログエントリーは syslog ビューアーアプリケーションで参照することをお勧めします

注記

ログファイルを参照するのにテキストエディターを使用することは推奨されません。これは、追加のログエントリーがログファイルに書き込まれなくなることがあるためです。
管理インターフェース監査ログは JSON 形式で出力されます。各ログエントリーでは、最初にオプションのタイムスタンプ、次に「管理インターフェースの監査ログフィールド」の表にリストされたフィールドが示されます。

表3.5 管理インターフェースの監査ログフィールド

フィールド名 説明
type 管理操作であることを示す core、または JMX サブシステムからであることを示す jmx を値として指定できます (JMX サブシステムの監査ロギングの設定については JMX サブシステムを参照してください)。
r/o 操作によって管理モデルが変更されない場合は、値が true になります。変更される場合は false になります。
booting 起動プロセス中に操作が実行された場合は、値が true になります。サーバーの起動後に操作が実行された場合は false になります。
version JBoss EAP インスタンスのバージョン番号。
user 認証されたユーザーのユーザー名。稼働しているサーバーと同じマシンの管理 CLI から操作が実行された場合は、特別な $local ユーザーが使用されます。
domainUUID ドメインコントローラーからサーバー、スレーブホストコントローラー、およびスレーブホストコントローラーサーバーへ伝播されるすべての操作をリンクする ID。
access 以下のいずれかの値を使用できます。
  • NATIVE - 操作が管理 CLI などのネイティブ管理インターフェースから実行されます。
  • HTTP - 操作が管理コンソールなどのドメイン HTTP インターフェースから実行されます。
  • JMX - 操作が JMX サブシステムから実行されます。JMX 向けの監査ロギングの設定方法については、JMX を参照してください。
remote-address この操作を実行するクライアントのアドレス。
success 操作に成功した場合は値 true になります。ロールバックされた場合は false になります。
ops 実行される操作。JSON へシリアライズ化された操作のリストになります。起動時は、XML の解析で生じたすべての操作がリストされます。起動後は、通常 1 つのエントリーがリストされます。

第4章 ユーザー管理

4.1. ユーザー作成

4.1.1. 管理インターフェースのユーザーの追加

概要

最初に利用できるユーザーアカウントがないため、Boss EAP 6 の管理インスタンスは、デフォルトでセキュアになります (グラフィカルインストーラーを使用してプラットフォームがインストールされてない場合)。これは、単純な設定エラーが原因でセキュリティーが侵されることを防ぐための対策です。

JBoss EAP 6 との HTTP 通信は、トラフィックの送信元がローカルホストであってもリモートアクセスと見なされます。したがって、管理コンソールを使用するには、少なくとも 1 人のユーザーを作成する必要があります。ユーザーを追加する前に管理コンソールにアクセスしようとすると、ユーザーが作成されるまでデプロイされないため、エラーが発生します。
以下の手順に従って、最初の管理ユーザーを作成します。このユーザーは、Web ベースの管理コンソールおよび管理 CLI のリモートインスタンスを使用して、リモートシステムから JBoss EAP 6 を設定および管理できます。

手順4.1 リモート管理インターフェース用の最初の管理ユーザーを作成

  1. add-user.sh または add-user.bat スクリプトを実行します。

    EAP_HOME/bin/ ディレクトリーへ移動します。ご使用のオペレーティングシステムに対応するスクリプトを呼び出します。
    Red Hat Enterprise Linux
    [user@host bin]$ ./add-user.sh
    Microsoft Windows Server
    C:\bin>  add-user.bat
  2. 管理ユーザーの追加を選択します。

    ENTER を押して、デフォルトのオプション a を選択して管理ユーザーを追加します。
    このユーザーは ManagementRealm に追加され、Web ベース管理コンソールまたはコマンドラインベース管理 CLI を使用して監理操作を実行することを許可されます。他のオプション b を選択すると、ユーザーが ApplicationRealm に追加され、特定のパーミッションは提供されません。このレルムはアプリケーションで使用するために提供されます。
  3. ユーザー名とパスワードを入力します。

    ユーザー名とパスワードの入力を要求されたら入力します。入力後、パスワードを確認するよう指示されます。
  4. グループ情報を入力します。

    ユーザーが属するグループを追加します。ユーザーが複数のグループに属する場合は、カンマ区切りリストを入力します。ユーザーがどのグループにも属さない場合は空白のままにします。
  5. 情報を確認します。

    情報を確認するよう指示されます。情報が正しければ yes を入力します。
  6. ユーザーがリモート JBoss EAP 6 サーバーインスタンスを表すかどうかを選択します。

    管理者以外にも、場合によっては JBoss EAP 6 の別のインスタンスを表すユーザーを ManagementRealm で JBoss EAP 6 に追加する必要があることがあります。このユーザーは、メンバーとしてクラスターに参加することを認証できる必要があります。次のプロンプトでは、この目的のために追加されたユーザーを指定できます。yes を選択した場合は、ユーザーのパスワードを表すハッシュされた secret 値が提供されます。これは他の設定ファイルに追加する必要があります。このタスクでは、no を選択してください。
  7. 追加ユーザーを入力します。

    必要な場合は、この手順を繰り返すと追加のユーザーを入力できます。また、稼働中のシステムにいつでもユーザーを追加することが可能です。デフォルトのセキュリティーレルムを選択する代わりに他のレルムにユーザーを追加すると、承認を細かく調整できます。
  8. 非対話的にユーザーを作成します。

    コマンドラインで各パラメーターを渡すと非対話的にユーザーを作成できます。ログや履歴ファイルにパスワードが表示されるため、この方法は共有システムでは推奨されません。管理レルムを使用した、コマンドの構文は次のとおりです。
    [user@host bin]$ ./add-user.sh username password
    アプリケーションレルムを使用するには、-a パラメーターを使用します。
    [user@host bin]$ ./add-user.sh -a username password
  9. --silent パラメーターを渡すと add-user スクリプトの通常出力を無効にできます。これは、username および password の最低限のパラメーターが指定されている場合のみ適用されます。エラーメッセージは表示されます。
結果

追加したすべてのユーザーは、指定したセキュリティーレルム内でアクティベートされます。ManagementRealm レルム内でアクティブなユーザーは、リモートシステムから JBoss EAP 6 を管理できます。

4.1.2. ユーザー管理の add-user スクリプトへ引数を渡す

add-user.sh または add-user.bat コマンドを対話的に実行できますが、コマンドラインで引数を渡すこともできます。ここでは、コマンドライン引数を add-user スクリプトへ渡すときに使用可能なオプションについて説明します。
add-user.sh または add-user.bat コマンドで使用できるコマンドライン引数の一覧は、「add-user コマンド引数」 を参照してください。
代替のプロパティーファイルおよび場所を指定する方法については、「ユーザー管理情報の代替プロパティーファイルの指定」 を参照してください。
add-user.sh または add-user.bat コマンドで引数を渡す方法を実証する例は、「add-user スクリプトのコマンドラインの例」 を参照してください。

4.1.3. add-user コマンド引数

下表は、add-user.sh または add-user.bat コマンドで使用できる引数を表しています。

表4.1 add-user コマンド引数

コマンドライン引数 引数の値 説明
-a
該当なし
この引数は、アプリケーションレルムでユーザーを作成するよう指定します。省略した場合、デフォルトでは管理レルムでユーザーが作成されます。
-dc
DOMAIN_CONFIGURATION_DIRECTORY
この引数は、プロパティーファイルが含まれるドメイン設定ディレクトリーを指定します。省略した場合、デフォルトのディレクトリーは EAP_HOME/domain/configuration/ になります。
-sc
SERVER_CONFIGURATION_DIRECTORY
この引数は、プロパティーファイルが含まれる代替のスタンドアロンサーバー設定ディレクトリーを指定します。省略した場合、デフォルトのディレクトリーは EAP_HOME/standalone/configuration/ になります。
-up
--user-properties
USER_PROPERTIES_FILE
この引数は、代替のユーザープロパティーファイルの名前を指定します。絶対パスを使用でき、代替の設定ディレクトリーを指定する -sc または -dc 引数と共に使用されるファイル名を使用することもできます。
-g
--group
GROUP_LIST
このユーザーに割り当てるグループのコンマ区切りリスト。
-gp
--group-properties
GROUP_PROPERTIES_FILE
この引数は、代替のグループプロパティーファイルの名前を指定します。絶対パスを使用でき、代替の設定ディレクトリーを指定する -sc または -dc 引数と共に使用されるファイル名を使用することもできます。
-p
--password
PASSWORD
ユーザーのパスワード。パスワードは次の要件を満たしている必要があります。
  • 8 文字以上でなければなりません。
  • 1 文字以上のアルファベットが含まれなくてはなりません。
  • 1 文字以上の数字が含まれなければなりません。
  • 英数字以外の記号が 1 つ以上含まれなければなりません。
-u
--user
USER_NAME
ユーザーの名前。英数字と ,./=@\ の記号のみが有効です。
-r
--realm
REALM_NAME
管理インターフェースをセキュアにするために使用されるレルムの名前。省略した場合、デフォルト値は ManagementRealm です。
-s
--silent
該当なし
コンソールへ出力せずに add-user スクリプトを実行します。
-h
--help
該当なし
add-user スクリプトの使用情報を表示します。

4.1.4. ユーザー管理情報の代替プロパティーファイルの指定

概要

デフォルトでは、add-user.sh または add-user.bat スクリプトを使用して作成されたユーザーおよびロール情報は、サーバー設定ディレクトリーにあるプロパティーファイルに保存されます。サーバー設定情報は EAP_HOME/standalone/configuration/ ディレクトリーに保存され、ドメイン設定情報は EAP_HOME/domain/configuration/ ディレクトリーに保存されます。ここでは、デフォルトのファイル名および場所を上書きする方法について説明します。

手順4.2 代替プロパティーファイルの指定

    • サーバー設定の代替のディレクトリーを指定するには、-sc 引数を使用します。この引数は、サーバー設定プロパティーファイルが含まれる代替のディレクトリーを指定します。
    • ドメイン設定の代替のディレクトリーを指定するには、-dc 引数を使用します。この引数は、ドメイン設定プロパティーファイルが含まれる代替のディレクトリーを指定します。
    • 代替のユーザー設定プロパティーファイルを指定するには、-up または --user-properties 引数を使用します。絶対パスを使用でき、代替の設定ディレクトリーを指定する -sc または -dc 引数と共に使用されるファイル名を使用することもできます。
    • 代替のグループ設定プロパティーファイルを指定するには、-gp または --group-properties 引数を使用します。絶対パスを使用でき、代替の設定ディレクトリーを指定する -sc または -dc 引数と共に使用されるファイル名を使用することもできます。

注記

add-user コマンドは、既存のプロパティーファイルでの操作を目的とするコマンドです。コマンドライン引数に指定された代替のプロパティーファイルが存在しない場合は、次のエラーが表示されます。
JBAS015234: No appusers.properties files found
コマンド引数の詳細については、「add-user コマンド引数」 を参照してください。
add-user コマンドの例は、「add-user スクリプトのコマンドラインの例」 を参照してください。

4.1.5. add-user スクリプトのコマンドラインの例

以下の例は、add-user.sh または add-user.bat コマンドで引数を渡す方法を表しています。記載があるもの以外は、これらのコマンドはスタンドアローンサーバーの設定を前提としています。

例4.1 デフォルトのプロパティーファイルを使用した単一のグループに属するユーザーの作成

EAP_HOME/bin/add-user.sh -a -u 'appuser1' -p 'password1!' -g 'guest'
上記のコマンドを実行した結果は次のとおりです。
  • ユーザー appuser1 が、ユーザー情報が保存される以下のデフォルトプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/application-users.properties
    EAP_HOME/domain/configuration/application-users.properties
  • guest グループのユーザー appuser1 が、グループ情報が保存されるデフォルトのプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/application-roles.properties
    EAP_HOME/domain/configuration/application-roles.properties

例4.2 デフォルトのプロパティーファイルを使用した複数のグループに属するユーザーの作成

EAP_HOME/bin/add-user.sh -a -u 'appuser1' -p 'password1!' -g 'guest,app1group,app2group'
上記のコマンドを実行した結果は次のとおりです。
  • ユーザー appuser1 が、ユーザー情報が保存される以下のデフォルトプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/application-users.properties
    EAP_HOME/domain/configuration/application-users.properties
  • guestapp1group、および app2group グループに属するユーザー appuser1 が、グループ情報が保存されるデフォルトのプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/application-roles.properties
    EAP_HOME/domain/configuration/application-roles.properties

例4.3 デフォルトのプロパティーファイルを使用したデフォルトレルムの管理特権を持つユーザーの作成

EAP_HOME/bin/add-user.sh -u 'adminuser1' -p 'password1!' -g 'admin'
上記のコマンドを実行した結果は次のとおりです。
  • ユーザー adminuser1 が、ユーザー情報が保存される以下のデフォルトプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/mgmt-users.properties
    EAP_HOME/domain/configuration/mgmt-users.properties
  • admin グループのユーザー adminuser1 が、グループ情報が保存されるデフォルトのプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/mgmt-groups.properties
    EAP_HOME/domain/configuration/mgmt-groups.properties

例4.4 情報を保存する代替プロパティーファイルを使用した単一のグループに属するユーザーの作成

EAP_HOME/bin/add-user.sh -a -u appuser1 -p password1! -g app1group -sc /home/someusername/userconfigs/ -up appusers.properties -gp appgroups.properties 
上記のコマンドを実行した結果は次のとおりです。
  • ユーザー appuser1 が、以下のプロパティーファイルに追加され、このファイルがユーザー情報を保存するデフォルトファイルになります。
    /home/someusername/userconfigs/appusers.properties
  • app1group グループのユーザー appuser1 が、以下のプロパティーファイルに追加され、このファイルがグループ情報を保存するデフォルトファイルになります。
    /home/someusername/userconfigs/appgroups.properties

第5章 ネットワークおよびポート設定

5.1. インターフェース

5.1.1. インターフェース

アプリケーションサーバーは、設定全体で名前付きインターフェース参照を使用します。これにより、使用ごとにインターフェースの完全な詳細を使用するのではなく論理名を使用して個々のインターフェース宣言を参照できるようになります。また、論理名を使用することにより、管理対象ドメインのサーバーインスタンスに、複数のマシンのさまざまなインターフェース詳細が含まれることがある名前付きインターフェースへのグループ参照で整合性を取ることができます。この方法により、各サーバーインスタンスは、インターフェースグループ全体を簡単に管理できる論理名グループに対応できます。
ネットワークインターフェースは、物理インターフェースの論理名と選択基準を指定して宣言されます。アプリケーションサーバーは、管理およびパブリックインターフェース名のデフォルト設定で出荷されます。この設定では、パブリックインターフェースグループは、Web やメッセージングなどのアプリケーション関連ネットワーク通信で使用することを目的としています。管理インターフェースグループは、HTTP 管理エンドポイントを含む管理レイヤーで必要なすべてのコンポーネントとサービスに使用することを目的としています。インターフェース名自体は、推奨例としてのみ提供され、どのグループのどの名前でも必要に応じて置換または作成できます。
domain.xmlhost.xml、および standalone.xml 設定ファイルには、インターフェース宣言が含まれます。宣言基準はワイルドカードアドレスを参照したり、有効な一致となるためにインターフェースまたはアドレスで必要となる 1 つ以上の特徴を指定したりできます。次の例は、通常は standalone.xml 設定ファイルまたは host.xml 設定ファイルで定義される、インターフェース宣言の複数の設定を示しています。これにより、リモートホストグループが独自の固有インターフェース属性を維持できるようになる一方で、ドメインコントローラーの domain.xml 設定ファイルのインターフェースグループを引き続き参照できます。
最初の例は、management 相対名グループと public 相対名グループに対して指定された固有の inet-address 値を示します。

例5.1 inet-address 値で作成されたインターフェースグループ

<interfaces>
  <interface name="management">
   <inet-address value="127.0.0.1"/>
  </interface>
  <interface name="public">
   <inet-address value="127.0.0.1"/>
  </interface>
</interfaces>

次の例では、グローバルインターフェースグループが any-address 要素を使用してワイルドカードアドレスを宣言します。

例5.2 ワイルドカード宣言で作成されたグローバルグループ

<interface name="global">
   <!-- Use the wild-card address -->
   <any-address/>
</interface>

次の例では、相対グループ下のネットワークインターフェースカードを名前 external で宣言します。

例5.3 NIC 値で作成された外部グループ

        
<interface name="external">
   <nic name="eth0"/>
</interface>

次の例では、特定の要件に対して宣言がデフォルトグループとして作成されます。このインスタンスでは、追加要素の特徴によって、有効な一致となるインターフェースの条件が設定されます。これにより、特定のインターフェース宣言グループを作成でき、事前設定された方法でこれらを参照できるため、複数のサーバーインスタンス全体で設定および管理時間を短縮できます。

例5.4 特定の条件値で作成されたデフォルトグループ

<interface name="default">
   <!-- Match any interface/address on the right subnet if it's
        up, supports multicast, and isn't point-to-point -->
   <subnet-match value="192.168.0.0/16"/>
   <up/>
   <multicast/>
   <not>
      <point-to-point/>
   </not>
</interface>

インターフェース宣言はソース設定ファイルで記述および編集できますが、管理 CLI と管理コンソールでは、安全で制御された永続的な環境で設定を変更できます。

5.1.2. インターフェースの設定

standalone.xml 設定ファイルと host.xml 設定ファイルのデフォルトインターフェース設定は、それぞれの相対インターフェーストークンを持つ 3 つの名前付きインターフェースを提供します。管理コンソールまたは管理 CLI を使用して、下表にある追加の属性と値を設定します。また、必要に応じて、相対インターフェースバインディングを特定の値に置き換えることもできますが、-b スイッチは相対値のみを上書きできるため、サーバーの実行時にインターフェース値を渡すことはできません。

例5.5 デフォルトインターフェース設定

        
<interfaces>
  <interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
  </interface>
  <interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
  </interface>
  <interface name="unsecure">
    <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
  </interface>
</interfaces>

表5.1 インターフェース属性と値

インターフェース要素 説明
any 選択基準を制約するために使用されるアドレス除外タイプの空の要素。
any-address このインターフェースを使用するソケットをワイルドカードアドレスにバインドする必要があることを示す空の要素。java.net.preferIpV4Stack システムプロパティーが true に設定されていない限り、IPv6 ワイルドカードアドレス (::) が使用されます。true に設定された場合は、IPv4 ワイルドカードアドレス (0.0.0.0) が使用されます。ソケットがデュアルスタックマシンの IPv6 anylocal アドレスにバインドされた場合は、IPv6 および IPv4 トラフィックを受け取ることができます。IPv4 (IPv4 マッピング) anylocal アドレスにバインドされた場合は、IPv4 トラフィックのみを受け取ることができます。
any-ipv4-address このインターフェースを使用するソケットを IPv4 ワイルドカードアドレス (0.0.0.0) にバインドする必要があることを示す空の要素。
any-ipv6-address このインターフェースを使用するソケットを IPv6 ワイルドカードアドレス (::) にバインドする必要があることを示す空の要素。
inet-address IPv6 または IPv4 のドット区切り表記の IP アドレス、または IP アドレスに解決できるホスト名。
link-local-address インターフェースの選択基準の一部として、関連付けられたアドレスがリンクローカルであるかどうかを示す空の要素。
loopback インターフェースの選択基準の一部として、ループバックインターフェースであるかどうかを示す空の要素。
loopback-address マシンのループバックインターフェースで実際には設定できないループバックアドレス。IP アドレスが関連付けられた NIC が見つからない場合であっても該当する値が使用されるため、inet-addressType とは異なります。
multicast インターフェースの選択基準の一部として、マルチキャストをサポートするかどうかを示す空の要素。
nic ネットワークインターフェースの名前 (eth0、eth1、lo など)。
nic-match 使用できるインターフェースを見つけるために、マシンで利用可能なネットワークインターフェースの名前を検索する正規表現。
not 選択基準を制約するために使用されるアドレス除外タイプの空の要素。
point-to-point インターフェースの選択基準の一部として、ポイントツーポイントインターフェースであるかどうかを示す空の要素。
public-address インターフェースの選択基準の一部として、公開されたルーティング可能なアドレスを持つかどうかを示す空の要素。
site-local-address インターフェースの選択基準の一部として、関連付けられたアドレスがサイトローカルであるかどうかを示す空の要素。
subnet-match 「スラッシュ表記法」で記述されたネットワーク IP アドレスとアドレスのネットワーク接頭辞のビット数 (たとえば、192.168.0.0/16)。
up インターフェースの選択基準の一部として、現在稼動しているかどうかを示す空の要素。
virtual インターフェースの選択基準の一部として、仮想インターフェースであるかどうかを示す空の要素。
  • インターフェース属性の設定

    タブ補完を使用して、入力しながらコマンド文字列を補完したり、利用可能な属性を表示したりできます。
    • 管理 CLI でのインターフェース属性の設定

      管理 CLI を使用して、新しいインターフェースを追加し、インターフェース属性に新しい値を書き込みます。
      1. 新しいインターフェースの追加

        add 操作は必要に応じて新しいインターフェースを作成します。add コマンドは、管理 CLI セッションのルートから実行されます。次の例では、inet-address12.0.0.2 と宣言された、新しいインターフェース interfacename が作成されます。
        /interface=interfacename/:add(inet-address=12.0.0.2)
      2. インターフェース属性の編集

        write-attribute 操作は、新しい値を属性に書き込みます。以下の例では、inet-address の値を 12.0.0.8 に更新します。
        /interface=interfacename/:write-attribute(name=inet-address, value=12.0.0.8)
      3. インターフェース属性の検証

        属性の値が変更されたことを確認するため、include-runtime=true パラメーターを使用して read-resource 操作を実行し、サーバーモデルで有効な現在の値をすべて表示します。例は次のとおりです。
        [standalone@localhost:9999 interface=public] :read-resource(include-runtime=true)
    • 管理コンソールでのインターフェース属性の設定

      1. 管理コンソールへのログイン

        管理対象ドメインまたはスタンドアロンサーバーインスタンスの管理コンソールにログインします。
      2. インターフェース画面への移動

        1. Configuration タブへ移動します。

          画面の上部から Configuration タブを選択します。
        2. ドメインモードのみ

          画面の左上にある Profile ドロップダウンメニューからプロファイルを選択します。
      3. ナビゲーションメニューからの Interfaces の選択

        General Configuration メニューを展開します。ナビゲーションメニューから Interfaces メニューを選択します。
      4. 新しいインターフェースの追加

        1. Add をクリックします。
        2. NameInet Address、および Address Wildcard に必要な値を入力します。
        3. Save をクリックします。
      5. インターフェース属性の編集

        1. Available Interfaces リストから編集する必要があるインターフェースを選択し、Edit ボタンをクリックします。
        2. NameInet Address、および Address Wildcard に必要な値を入力します。
        3. Save をクリックします。

5.2. ソケットバインディンググループ

5.2.1. ソケットバインディンググループ

ソケットバインディングとソケットバインディンググループを使用することにより、ネットワークポートと、JBoss EAP 6 の設定で必要なネットワーキングインターフェースとの関係を定義できます。
ソケットバインディングは、ソケットの名前付き設定です。これらの名前付き設定の宣言は、domain.xml 設定ファイルと standalone.xml 設定ファイルの両方にあります。設定の他のセクションは、論理名でこれらのソケットを参照できます。ソケット設定の完全な詳細を含める必要はありません。これにより、マシンによって異なる場合がある相対ソケットを参照できます。
ソケットバインディングは、ソケットバインディンググループ下に収集されます。ソケットバインディンググループは、論理名でグループ化されたソケットバインディング宣言のコレクションです。名前付きグループは、設定全体で参照できます。スタンドアロンサーバーにはこのようなグループが 1 つだけ含まれ、管理対象ドメインインスタンスには複数のグループを含めることができます。管理対象ドメインの各サーバーグループに対してソケットバインディングを作成するか、複数のサーバーグループ間でソケットバインディンググループを共有できます。
名前付きグループを使用すると、管理対象ドメインの場合に、サーバーグループを設定するときにソケットバインディングの特定のグループに、単純化された参照を使用できます。また、一般的に、1 つのシステムでのスタンドアロンサーバーの複数のインスタンスの設定と管理にも使用できます。次の例は、スタンドアロンおよびドメインインスタンスの設定ファイルのデフォルトソケットバインディンググループを示しています。

例5.6 スタンドアロン設定のデフォルトソケットバインディング

standalone.xml 設定ファイルのデフォルトソケットバインディンググループは、standard-sockets 下でグループ化されます。このグループは、同じ論理参照方法を使用して public インターフェースでも参照されます。
   
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-native" interface="management" port="${jboss							.management.native.port:9999}"/>
        <socket-binding name="management-http" interface="management" port="${jboss								.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss							.management.https.port:9443}"/>
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
</socket-binding-group>

例5.7 ドメイン設定のデフォルトソケットバインディング

domain.xml 設定ファイルのデフォルトソケットバインディンググループには standard-socketsha-socketsfull-sockets、および full-ha-sockets の 4 つのグループが含まれます。これらのグループは public と呼ばれるインターフェースでも参照されます。
<socket-binding-groups>
        <socket-binding-group name="standard-sockets" default-interface="public">
            <!-- Needed for server groups using the 'default' profile  -->
            <socket-binding name="ajp" port="8009"/>
            <socket-binding name="http" port="8080"/>
            <socket-binding name="https" port="8443"/>
            <socket-binding name="remoting" port="4447"/>
            <socket-binding name="txn-recovery-environment" port="4712"/>
            <socket-binding name="txn-status-manager" port="4713"/>
            <outbound-socket-binding name="mail-smtp">
                <remote-destination host="localhost" port="25"/>
            </outbound-socket-binding>
        </socket-binding-group>
        <socket-binding-group name="ha-sockets" default-interface="public">
            <!-- Needed for server groups using the 'ha' profile  -->
            <socket-binding name="ajp" port="8009"/>
            <socket-binding name="http" port="8080"/>
            <socket-binding name="https" port="8443"/>
            <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss									.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
            <socket-binding name="jgroups-tcp" port="7600"/>
            <socket-binding name="jgroups-tcp-fd" port="57600"/>
            <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss								.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
            <socket-binding name="jgroups-udp-fd" port="54200"/>
            <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" 								multicast-port="23364"/>
            <socket-binding name="remoting" port="4447"/>
            <socket-binding name="txn-recovery-environment" port="4712"/>
            <socket-binding name="txn-status-manager" port="4713"/>
            <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
            </outbound-socket-binding>
        </socket-binding-group>
        <socket-binding-group name="full-sockets" default-interface="public">
            <!-- Needed for server groups using the 'full' profile  -->
            <socket-binding name="ajp" port="8009"/>
            <socket-binding name="http" port="8080"/>
            <socket-binding name="https" port="8443"/>
            <socket-binding name="jacorb" interface="unsecure" port="3528"/>
            <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
            <socket-binding name="messaging" port="5445"/>
            <socket-binding name="messaging-group" port="0" multicast-address="${jboss								.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
            <socket-binding name="messaging-throughput" port="5455"/>
            <socket-binding name="remoting" port="4447"/>
            <socket-binding name="txn-recovery-environment" port="4712"/>
            <socket-binding name="txn-status-manager" port="4713"/>
            <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
            </outbound-socket-binding>
        </socket-binding-group>
        <socket-binding-group name="full-ha-sockets" default-interface="public">
            <!-- Needed for server groups using the 'full-ha' profile  -->
            <socket-binding name="ajp" port="8009"/>
            <socket-binding name="http" port="8080"/>
            <socket-binding name="https" port="8443"/>
            <socket-binding name="jacorb" interface="unsecure" port="3528"/>
            <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
            <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss									.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
            <socket-binding name="jgroups-tcp" port="7600"/>
            <socket-binding name="jgroups-tcp-fd" port="57600"/>
            <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss								.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
            <socket-binding name="jgroups-udp-fd" port="54200"/>
            <socket-binding name="messaging" port="5445"/>
            <socket-binding name="messaging-group" port="0" multicast-address="${jboss								.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
            <socket-binding name="messaging-throughput" port="5455"/>
            <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" 								multicast-port="23364"/>
            <socket-binding name="remoting" port="4447"/>
            <socket-binding name="txn-recovery-environment" port="4712"/>
            <socket-binding name="txn-status-manager" port="4713"/>
            <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
            </outbound-socket-binding>
        </socket-binding-group>
    </socket-binding-groups>
ソケットバインディングインスタンスは、アプリケーションサーバーディレクトリーの standalone.xml ソースファイルと domain.xml ソースファイルで作成および編集できます。バインディングの管理には、管理コンソールまたは管理 CLI を使用することが推奨されます。管理コンソールを使用すると、General Configuration セクション下に専用の Socket Binding Group 画面があるグラフィカルユーザーインターフェースが使用できるなどの利点があります。管理 CLI は、アプリケーションサーバー設定の上位および下位レベル全体でバッチ処理やスクリプトの使用を可能にする、コマンドラインを基にした API およびワークフローを提供します。両方のインターフェースにより、変更を永続化したり、サーバー設定に保存したりできます。

5.2.2. ソケットバインディングの設定

ソケットバインディングは固有のソケットバインディンググループで定義できます。スタンドアロンサーバーにはこのようなグループの 1 つである standard-sockets が含まれ、その他のグループを作成できません。その他のグループを作成するには、別のスタンドアロンサーバー設定ファイルを作成します。管理対象ドメインでは複数のソケットバインディンググループを作成することが可能で、必要に応じて含まれるソケットバインディングを設定できます。下表は各ソケットバインディングに使用できる属性を表しています。

表5.2 ソケットバインディングの属性

属性 説明 ロール
name 設定の他の場所で使用する必要があるソケット設定の論理名。 必須
port この設定に基づいたソケットをバインドする必要がある基本ポート。すべてのポートの値をインクリメントまたはデクリメントすることにより、サーバーがこの基本値を上書きするよう設定できることに注意してください。 必須
interface この設定に基づいたソケットをバインドする必要があるインターフェースの論理名。定義されない場合は、囲んでいるソケットバインディンググループから default-interface 属性の値が使用されます。 任意
multicast-address マルチキャストにソケットが使用される場合は、使用するマルチキャストアドレス。 任意
multicast-port マルチキャストにソケットが使用される場合は、使用するマルチキャストポート。 任意
fixed-port true の場合、port の値が常に使用されなければならず、インクリメントまたはデクリメントを適用して上書きされてはならないことを宣言します。 任意
  • ソケットバインディンググループのソケットバインディングの設定

    管理 CLI または管理コンソールを選択して、必要に応じてソケットバインディングを設定します。
    • 管理 CLI を使用したソケットバインディングの設定

      管理 CLI を使用してソケットバインディングを設定します。
      1. 新しいソケットバインディングの追加

        add 操作を使用して、必要な場合に新しいアドレス設定を作成します。このコマンドは、管理 CLI セッションのルートから実行できます。この場合、以下の例では、newsocket という新しいソケットバインディングが作成され、port 属性が 1234 として宣言されます。以下の例は、standard-sockets ソケットバインディンググループ上で編集を行うスタンドアロンサーバーおよび管理対象ドメインの両方に適用されます。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:add(port=1234)
      2. パターン属性の編集

        write-attribute 操作を使用して新しい値を属性に書き込みます。タブ補完を使用して、入力するコマンド文字列を補完したり、利用可能な属性を表示したりできます。以下の例では、port 値を 2020 に更新します。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:write-attribute(name=port,value=2020)
      3. パターン属性の確認

        include-runtime=true パラメーターを用いて read-resource 操作を実行し、値の変更を確認します。サーバーモデルでアクティブな現在の値をすべて表示します。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:read-resource
    • 管理コンソールを使用したソケットバインディングの設定

      管理コンソールを使用してソケットバインディングを設定します。
      1. 管理コンソールへのログイン

        管理対象ドメインまたはスタンドアロンサーバーの管理コンソールにログインします。
      2. Configuration タブへ移動

        画面の上部にある Configuration タブを選択します。
      3. ナビゲーションメニューより Socket Binding を選択

        General Configuration メニューを展開し、Socket Binding を選択します。管理対象ドメインを使用している場合は、Socket Binding Groups リストで希望のグループを選択します。
      4. 新しいソケットバインディングの追加

        1. Add ボタンをクリックします。
        2. NamePort、および Binding Group に必要な値を入力します。
        3. Save をクリックして終了します。
      5. ソケットバインディングの編集

        1. リストからソケットバインディングを選択し、Edit をクリックします。
        2. 必要な値を入力します (NameInterfacePort など)。
        3. Save をクリックして終了します。

5.2.3. JBoss EAP 6 により使用されるネットワークポート

JBoss EAP 6 のデフォルト設定で使用されるポートは、次の複数の要因によって異なります。
  • サーバーグループがデフォルトのソケットバインディンググループのいずれかを使用するか、またはカスタムグループを使用するかどうか。
  • 個別デプロイメントの要件。

注記

数値ポートオフセットは、同じ物理サーバーで複数のサーバーを実行する場合にポートの競合を緩和するために設定できます。サーバーが数値のポートオフセットを使用する場合は、サーバーグループのソケットバインディンググループに対するデフォルトのポート番号にオフセットを追加します。たとえば、ソケットバインディンググループの HTTP ポートが 8080 で、サーバーは 100 のポートオフセットを使用する場合、その HTTP ポートは 8180 になります。
特に指定がない限り、ポートは TCP プロトコルを使用します。

デフォルトのソケットバインディンググループ

  • full-ha-sockets
  • full-sockets
  • ha-sockets
  • standard-sockets
これらのソケットバインディンググループは、domain.xml でのみ利用可能です。スタンドアロンサーバープロファイルには、標準的なソケットバインディンググループのみが含まれます。このグループは、standalone.xmlstandalone-ha.xmlha-socketsstandalone-full.xmlfull-sockets、および standalone-full-ha.xmlfull-ha-sockets の標準ソケットに対応します。スタンドアロンプロファイルには、さらに多くのソケットバインディング (management-{native,http,https} など) が含まれます。

表5.3 デフォルトのソケットバインディングの参照

名前 ポート マルチキャストポート 説明 full-ha-sockets full-sockets ha-socket standard-socket
ajp 8009 Apache JServ プロトコル。HTTP クラスタリングおよび負荷分散に使用します。
http 8080 デプロイされた Web アプリケーションのデフォルトポート。
https 8443 デプロイされた Web アプリケーションとクライアント間の SSL 暗号化接続。
jacorb 3528 JTS トランザクションおよび他の ORB 依存サービス用の CORBA サービス。
jacorb-ssl 3529 SSL 暗号化 CORBA サービス。
jgroups-diagnostics 7500 マルチキャスト。HA クラスターでのピアの検出に使用されます。管理インターフェースを使用しても設定できません。
jgroups-mping 45700 マルチキャスト。HA クラスターでの初期メンバーシップの検出に使用されます。
jgroups-tcp 7600 TCP を使用した、HA クラスター内でのユニキャストピア検出。
jgroups-tcp-fd 57600 TCP を介した HA 障害検出に使用されます。
jgroups-udp 55200 45688 UDP を使用した、HA クラスター内でのマルチキャストピア検出。
jgroups-udp-fd 54200 UDP を介した HA 障害検出に使用されます。
messaging 5445 JMS サービス。
messaging-group HornetQ JMS ブロードキャストと検出グループにより参照されます。
messaging-throughput 5455 JMS Remoting により使用されます。
mod_cluster 23364 JBoss EAP 6 と HTTP ロードバランサー間の通信に対するマルチキャストポート。
remoting 4447 リモート EJB の呼び出しに使用されます。
txn-recovery-environment 4712 JTA トランザクションリカバリーマネージャー。
txn-status-manager 4713 JTA / JTS トランザクションマネージャー。
管理ポート

ソケットバインディンググループの他に、各ホストコントローラーによって 2 つのポートが管理目的で開かれます。

  • 9990 - Web 管理コンソールポート
  • 9999 - 管理コンソールと管理 API によって使用されるポート
さらに、管理コンソールに対して HTTPS が有効になっている場合、9443 もデフォルトポートとして開かれます。

5.2.4. ソケットバインディンググループのポートオフセット

ポートオフセットは、該当するサーバーのソケットバインディンググループにより提供されるポート値に追加される数値オフセットです。これにより、単一のサーバーが属するサーバーグループのソケットバインディングを継承します (グループ内の他のサーバーと競合しないようオフセットを使用)。たとえば、ソケットバインディンググループの HTTP ポートが 8080 で、サーバーが 100 のポートオフセットを使用する場合、その HTTP ポートは 8180 になります。

5.2.5. ポートオフセットの設定

  • ポートオフセットの設定

    管理 CLI または管理コンソールを選択してポートオフセットを設定します。
    • 管理 CLI を使用したポートオフセットの設定

      管理 CLI を使用してポートオフセットを設定します。
      1. ポートオフセットの編集

        write-attribute 操作を使用して新しい値をポートオフセット属性に書き込みます。次の例は、server-twosocket-binding-port-offset 値を 250 に更新します。このサーバーはデフォルトローカルホストグループのメンバーです。変更を有効にするには再起動が必要となります。
        [domain@localhost:9999 /] /host=master/server-config=server-two/:write-attribute(name=socket-binding-port-offset,value=250)
      2. ポートオフセット属性の確認

        include-runtime=true パラメーターを用いて read-resource 操作を実行し、値の変更を確認します。サーバーモデルでアクティブな現在の値をすべて表示します。
        [domain@localhost:9999 /] /host=master/server-config=server-two/:read-resource(include-runtime=true)
    • 管理コンソールを使用したポートオフセットの設定

      管理コンソールを使用してポートオフセットを設定します。
      1. 管理コンソールにログインします。

        管理対象ドメインの管理コンソールにログインします。
      2. Domain タブの選択

        画面の上部にある Domain タブを選択します。
      3. ポートオフセット属性の編集

        1. Available Server Configurations リストのサーバーを選択し、属性リストの上にある Edit をクリックします。
        2. Port Offset フィールドで必要な値を入力します。
        3. Save をクリックして終了します。

5.2.6. リモーティングのメッセージサイズの設定

リモーティングサブシステムは、リモーティングプロトコル対してメッセージのサイズを制限するオプションを提供します。最大受信メッセージサイズ (MAX_INBOUND_MESSAGE_SIZE) および最大送信メッセージサイズ (MAX_OUTBOUND_MESSAGE_SIZE) を設定すると、メッセージが適切な制限内のサイズで送受信されます。
リモーティングプロトコルのメッセージサイズを設定すると、システムメモリーが効率的に使用され、重要な操作の実行中にメモリー不足が発生しないようになります。
送信側が最大許容限界 (MAX_OUTBOUND_MESSAGE_SIZE) を超えるメッセージを送信した場合、サーバーによって例外が発生し、データの送信がキャンセルされます。しかし、接続は開いたままになり、送信側は必要であればメッセージを閉じることができます。
受信したメッセージが最大許容限界 (MAX_INBOUND_MESSAGE_SIZE) を越えた場合、接続が開いたまま、メッセージは非同期に閉じられます。

5.3. IPv6

5.3.1. IPv6 ネットワーキング向け JVM スタック設定の指定

概要
このトピックでは、JBoss EAP 6 インストールでの IPv6 ネットワーキングの有効化について説明します。

手順5.1 IPv4 Stack Java プロパティーの無効化

  1. インストールに関連するファイルを開きます。
    • スタンドアロンサーバーの場合:

      EAP_HOME/bin/standalone.conf を開きます。
    • 管理対象ドメインの場合:

      EAP_HOME/bin/domain.conf を開きます。
  2. IPv4 Stack Java プロパティーを false に変更します。
    -Djava.net.preferIPv4Stack=false
    例:

    例5.8 JVM オプション

    # Specify options to pass to the Java VM.
    #
    if [ "x$JAVA_OPTS" = "x" ]; then
       JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
       -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
       -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
    fi
    

5.3.2. IPv6 ネットワークに対するインターフェース宣言の設定

概要

次の手順に従って、インターフェース inet アドレスを IPv6 のデフォルトに設定します。

手順5.2 IPv6 ネットワーキングのインターフェースの設定

  1. 画面の上部にある Configuration タブを選択します。
  2. General Configuration メニューを展開し、Interfaces を選択します。
  3. Available Interfaces リストからインターフェースを選択します。
  4. 詳細リストの Edit をクリックします。
  5. 下記の inet アドレスを設定します。
    ${jboss.bind.address.management:[ADDRESS]}
  6. Save をクリックして終了します。
  7. サーバーを再起動し、変更を実装します。

5.3.3. IPv6 アドレス用 JVM スタック設定の指定

概要
このトピックでは、JBoss EAP 6 インストールで IPv6 アドレスを優先するよう設定ファイルで設定する方法について説明します。

手順5.3 IPv6 アドレスを優先するよう JBoss EAP 6 インストールを設定する

  1. インストールに関連するファイルを開きます。
    • スタンドアロンサーバーの場合:

      EAP_HOME/bin/standalone.conf を開きます。
    • 管理対象ドメインの場合:

      EAP_HOME/bin/domain.conf を開きます。
  2. 以下の Java プロパティーを Java VM オプションに追加します。
    -Djava.net.preferIPv6Addresses=true
    例:

    例5.9 JVM オプション

    # Specify options to pass to the Java VM.
    #
    if [ "x$JAVA_OPTS" = "x" ]; then
       JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
       -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
       -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
    fi
    

第6章 データソース管理

6.1. はじめに

6.1.1. JDBC

JDBC API は、Java アプリケーションがデータベースにアクセスする方法を定義する基準です。アプリケーションは JDBC ドライバーを参照するデータソースを設定します。その後、データベースではなくドライバーに対してアプリケーションを記述できます。ドライバーはコードをデータベース言語に変換します。そのため、適切なドライバーがインストールされていればアプリケーションをサポートされるデータベースで使用できます。
JDBC 4.0 の仕様は、次のサイトで定義されています: http://jcp.org/en/jsr/detail?id=221
JDBC とデータソースの使用を開始するにあたっては、JBoss EAP 6 の管理設定ガイドの JDBC ドライバーのセクションを参照してください。

6.1.2. JBoss EAP 6 でサポートされるデータベース

JBoss EAP 6 でサポートされる JDBC 準拠のデーターベースの一覧は https://access.redhat.com/site/articles/111663 で参照できます。

6.1.3. データソースの型

一般的なリソースタイプには、datasourcesXA datasources の 2 つがあります。
非 XA データソースは、トランザクションを使用しないアプリケーション、または単一のデータベースでトランザクションを使用するアプリケーションに使用されます。
XA データソースは、トランザクションが複数のデータベースにわたって分散されるアプリケーションによって使用されます。
管理コンソールあるいは管理 CLI でデータソースを作成するときに、データソースの型を指定します。

6.1.4. データソースの例

JBoss EAP 6 には H2 データベースが含まれています。これは、軽量な関係データベース管理システムであり、開発者がアプリケーションを迅速に構築できるようにします。また、このプラットフォームのデータソースの例になります。

警告

本番稼働環境では使用しないでください。これは、アプリケーションをテストおよび構築するために必要なすべての標準をサポートする非常に小さい自己完結型のデータソースであり、本番稼働用として堅牢またはスケーラブルではありません。
サポートおよび認定済みのデータソースの一覧については、「JBoss EAP 6 でサポートされるデータベース」を参照してください。

6.1.5. -ds.xml ファイルのデプロイメント

JBoss EAP 6 では、データソースはサーバーサブシステムのリソースとして定義されます。以前のバージョンでは、サーバー設定のデプロイメントディレクトリーに *-ds.xml データソース設定ファイルが必要でした。*-ds.xml ファイルを JBoss EAP 6 にデプロイするには、http://www.ironjacamar.org/documentation.html の「Schemas」下にある Data sources の 1.1 に従います。

警告

この機能は開発目的でのみ使用するようにしてください。JBoss の管理ツールではサポートされないため、本番環境での使用は推奨されません。この機能は JBoss EAP 6.4 では非推奨となり、製品の次回のメジャーリリースではサポートされません。

重要

*-ds.xml ファイルをデプロイする場合、すでにデプロイまたは定義されている <driver> エントリーへの参照を使用しなければなりません。

6.2. JDBC ドライバー

6.2.1. 管理コンソールを用いた JDBC ドライバーのインストール

概要

アプリケーションが JDBC データソースに接続する前に、データソースベンダーの JDBC ドライバーを JBoss EAP 6 が使用できる場所にインストールする必要があります。JBoss EAP 6 では、これらのドライバーを他のデプロイメントと同じようにデプロイできます。そのため、管理対象ドメインを使用する場合は、サーバーグループ内の複数のサーバー全体でドライバーをデプロイできます。

前提条件

このタスクを実行する前に、以下の前提条件を満たしている必要があります。

  • データベースのベンダーから JDBC ドライバーをダウンロードする必要があります。

注記

JDBC 4 対応のドライバーは自動的に認識され、名前とバージョンによってシステムへインストールされます。JDBC JAR は、Java サービスプロバイダーのメカニズムを使用して識別されます。このような JAR には、JAR のドライバークラスの名前が含まれる META-INF/services/java.sql.Driver テキストが含まれています。

手順6.1 JDBC ドライバー JAR の編集

JDBC ドライバー JAR が JDBC 4 未対応である場合、以下の方法でデプロイ可能にすることができます。
  1. 空の一時ディレクトリーに移動するか、空の一時ディレクトリーを作成します。
  2. META-INF サブディレクトリーを作成します。
  3. META-INF/services サブディレクトリーを作成します。
  4. JDBC ドライバーの完全修飾クラス名を示す 1 行が含まれる、META-INF/services/java.sql.Driver ファイルを作成します。
  5. JAR コマンドラインツールを使用して、次のように JAR を更新します。
    jar \-uf jdbc-driver.jar META-INF/services/java.sql.Driver
  6. 管理対象ドメインを使用する場合は、JAR ファイルをサーバーグループにデプロイします。使用しない場合はサーバーにデプロイします。「管理コンソールを使用してデプロイされたアプリケーションを有効化」を参照してください。
結果

JDBC ドライバーがデプロイされ、アプリケーションが使用できるようになります。

6.2.2. コアモジュールとしての JDBC ドライバーのインストール

前提条件

このタスクを実行する前に、以下の前提条件を満たしている必要があります。

手順6.2 コアモジュールとしての JDBC ドライバーのインストール

  1. EAP_HOME/modules/ ディレクトリー下にファイルパス構造を作成します。たとえば、MySQL JDBC ドライバーの場合には、EAP_HOME/modules/com/mysql/main/ のようなディレクトリー構造を作成します。
  2. JDBC ドライバー JAR を main/ サブディレクトリーにコピーします。
  3. main/ サブディレクトリーで、「モジュール」の例に似た module.xml ファイルを作成します。module XSD は EAP_HOME/docs/schema/module-1_2.xsd ファイルに定義されます。
  4. サーバーを起動します。
  5. 管理 CLI を起動します。
  6. CLI コマンドを実行して JDBC ドライバーモジュールをサーバー設定に追加します。
    選択するコマンドは、JDBC ドライバー JAR にある /META-INF/services/java.sql.Driver ファイルにリストされたクラスの数によって異なります。たとえば、MySQL 5.1.20 JDBC JAR 内の /META-INF/services/java.sql.Driver ファイルは以下の 2 つのクラスをリストします。
    • com.mysql.jdbc.Driver
    • com.mysql.fabric.jdbc.FabricMySQLDriver
    複数のエントリーがある場合は、ドライバークラスの名前も指定する必要があります。これを行わないと、以下のようなエラーが発生します。

    例6.1 ドライバークラスエラー

    JBAS014749: Operation handler failed: Service jboss.jdbc-driver.mysql is already registered
    • 1 つのクラスエントリーを含む JDBC JAR に対して CLI コマンドを実行します。
      /subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME)

      例6.2 1 つのドライバークラスを持つ JDBC JAR に対するスタンドアロンモードの CLI コマンド

      /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)

      例6.3 1 つのドライバークラスを持つ JDBC JAR に対するドメインモードの CLI コマンド

      /profile=ha/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)
    • 複数のクラスエントリーを含む JDBC JAR に対して CLI コマンドを実行します。
      /subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME, driver-class-name=DRIVER_CLASS_NAME)

      例6.4 複数のドライバークラスエントリーを持つ JDBC JAR に対するスタンドアロンモードの CLI コマンド

      /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource, driver-class-name=com.mysql.jdbc.Driver)

      例6.5 複数のドライバークラスエントリーを持つ JDBC JAR に対するドメインモードの CLI コマンド

      /profile=ha/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource, driver-class-name=com.mysql.jdbc.Driver)
結果

JDBC ドライバーがインストールされ、コアモジュールとして設定されます。アプリケーションのデータソースが JDBC ドライバーを参照できる状態になります。

6.2.3. JDBC ドライバーをダウンロードできる場所

以下の表は、JBoss EAP 6 で使用する一般的なデータベースの JDBC ドライバーをダウンロードする場所を示しています。これらのリンク先は、Red Hat が管理および監視していない他社の Web サイトであります。データベースの最新のドライバーについては、データベースのベンダーのドキュメントや Web サイトを確認してください。

6.2.4. ベンダー固有クラスへのアクセス

概要

このトピックでは、JDBC 固有クラスを使用するのに必要な手順について説明します。これは、アプリケーションが JDBC API の一部でないベンダー固有の機能を使用する必要がある場合に必要です。

警告

これは、高度な手順であり、JDBC API に含まれない機能を必要とするアプリケーションのみこれを実装します。

重要

このプロセスは、再認証メカニズムを使用し、ベンダー固有のクラスにアクセスする場合に必要です。

重要

接続は IronJacamar コンテナーによって制御されるため、ベンダー固有の API ガイドラインに厳密に従ってください。

手順6.3 アプリケーションへの依存関係の追加

以下のいずれかの方法で依存関係をアプリケーションに追加できます。お好きな方法を選択してください。
    • MANIFEST.MF ファイルの設定

      1. テキストエディターでアプリケーションの META-INF/MANIFEST.MF ファイルを開きます。
      2. JDBC モジュールの依存関係を追加し、ファイルを保存します。
        依存関係: MODULE_NAME

        例6.6 com.mysql が依存関係として宣言された MANIFEST.MF ファイル

        依存関係: com.mysql
      1. jboss-deployment-structure.xml ファイルの作成

        アプリケーションの META-INF/ または WEB-INF フォルダーで jboss-deployment-structure.xml という名前のファイルを作成します。

        例6.7 com.mysql が依存関係として宣言された jboss-deployment-structure.xml ファイル

        <jboss-deployment-structure>
          <deployment>
            <dependencies>
              <module name="com.mysql" />
            </dependencies>
          </deployment>
        </jboss-deployment-structure>

例6.8 ベンダー固有 API へのアクセス

以下のサンプルは MySQL API にアクセスします。
import java.sql.Connection;
import org.jboss.jca.adapters.jdbc.WrappedConnection;

  Connection c = ds.getConnection();
  WrappedConnection wc = (WrappedConnection)c;
  com.mysql.jdbc.Connection mc = wc.getUnderlyingConnection();

6.3. 非 XA データソース

6.3.1. 管理インターフェースによる非 XA データソースの作成

概要

ここでは、管理コンソールまたは管理 CLI のいずれかを使用して非 XA データソースを作成する手順について取り上げます。

前提条件

  • JBoss EAP 6 サーバーが稼働している必要があります。

注記

バージョン 10.2 以前の Oracle データソースでは非トランザクション接続とトランザクション接続が混在するとエラーが発生したため、<no-tx-separate-pools/> パラメーターが必要でした。一部のアプリケーションでは、このパラメーターが不要になりました。

手順6.4 管理 CLI または管理コンソールのいずれかを使用したデータソースの作成

    • 管理 CLI

      1. CLI ツールを起動し、サーバーに接続します。
      2. 以下の管理 CLI コマンドを実行して非 XA データソースを作成し、適切に変数を設定します。

        注記

        DRIVER_NAME の値は、JDBC ドライバー JAR にある /META-INF/services/java.sql.Driver ファイルにリストされたクラスの数によって異なります。クラスが 1 つしかない場合、この値は JAR の名前になります。クラスが複数ある場合、この値は JAR + driverClassName + "_" + majorVersion +"_" + minorVersion の名前になります。失敗した場合は、以下のエラーがログに記録されます。
        JBAS014775:    New missing/unsatisfied dependencies
        たとえば、MySQL 5.1.31 ドライバーで必要な DRIVER_NAME 値は mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1 です。
        data-source add --name=DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME  --connection-url=CONNECTION_URL
      3. データソースを有効にします。
        data-source enable --name=DATASOURCE_NAME
    • 管理コンソール

      1. 管理コンソールへログインします。
      2. 管理コンソールの Datasources パネルに移動します。

        1. コンソールの上部から Configuration タブを選択します。
        2. ドメインモードの場合は、左上のドロップダウンボックスからプロファイルを選択します。
        3. コンソールの左側にある Subsystems メニューを展開し、Connector メニューを展開します。
        4. コンソールの左側にあるメニューより Datasources を選択します。
      3. 新しいデータソースを作成します。

        1. Datasources パネルの上部にある Add を選択します。
        2. Create Datasource ウィザードで新しいデータソースの属性を入力し、Next ボタンを押します。
        3. Create Datasource ウィザードで JDBC ドライバーの詳細を入力し、Next をクリックします。
        4. Create Datasource ウィザードで接続設定を入力します。
        5. Test Connection ボタンをクリックしてデータソースへの接続をテストし、設定が正しいことを確認します。
        6. Done をクリックして終了します。
結果

非 XA データソースがサーバーに追加されます。standalone.xml または domain.xml ファイル、および管理インターフェースで追加を確認できます。

6.3.2. 管理インターフェースによる非 XA データソースの編集

概要

ここでは、管理コンソールまたは管理 CLI のいずれかを使用して非 XA データソースを編集する手順について取り上げます。

注記

非 XA データソースは JTA トランザクションと統合できます。データソースを JTA と統合する場合、必ず jta パラメーターを true に設定してください。

手順6.5 非 XA データソースの編集

    • 管理 CLI

      1. write-attribute コマンドを使用してデータソース属性を設定します。
        /subsystem=datasources/data-source=DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)
      2. サーバーを再ロードして変更を確認します。
        :reload
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

        1. コンソールの上部から Configuration タブを選択します。
        2. ドメインモードの場合は、左上のドロップダウンボックスからプロファイルを選択します。
        3. コンソールの左側にある Subsystems メニューを展開し、Connector メニューを展開します。
        4. 展開されたメニューから Datasources を選択します。
      2. データソースを編集します。

        1. Available Datasources リストからデータソースを選択します。データソース属性は下に表示されます。
        2. Edit をクリックし、データソース属性を編集します。
        3. Save をクリックして終了します。
結果

非 XA データソースが設定されます。変更は standalone.xml または domain.xml ファイルのどちらかと、管理インターフェースで確認できます。

6.3.3. 管理インターフェースによる非 XA データソースの削除

概要

ここでは、管理コンソールまたは管理 CLI を使用して、JBoss EAP 6 より非 XA データソースを削除するために必要な手順について説明します。

手順6.6 非 XA データソースの削除

    • 管理 CLI

      1. 次のコマンドを実行して非 XA データソースを削除します。
        data-source remove --name=DATASOURCE_NAME
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

        1. コンソールの上部から Configuration タブを選択します。
        2. ドメインモードの場合は、左上のドロップダウンボックスからプロファイルを選択します。
        3. コンソールの左側にある Subsystems メニューを展開し、Connector メニューを展開します。
        4. Datasources を選択します。
      2. 削除するデータソースを選択し、Remove をクリックします。
結果

非 XA データソースがサーバーより削除されます。

6.4. XA データソース

6.4.1. 管理インターフェースによる XA データソースの作成

必読トピック:

概要

ここでは、管理コンソールまたは管理 CLI のいずれかを使用して XA データソースを作成する手順について取り上げます。

注記

バージョン 10.2 以前の Oracle データソースでは非トランザクション接続とトランザクション接続が混在するとエラーが発生したため、<no-tx-separate-pools/> パラメーターが必要でした。一部のアプリケーションでは、このパラメーターが不要になりました。

手順6.7 管理 CLI または管理コンソールのいずれかを使用した XA データソースの作成

    • 管理 CLI

      1. 以下の管理 CLI コマンドを実行して XA データソースを作成し、適切に変数を設定します。

        注記

        DRIVER_NAME の値は、JDBC ドライバー JAR にある /META-INF/services/java.sql.Driver ファイルにリストされたクラスの数によって異なります。クラスが 1 つしかない場合、この値は JAR の名前になります。クラスが複数ある場合、この値は JAR + driverClassName + "_" + majorVersion +"_" + minorVersion の名前になります。失敗した場合は、以下のエラーがログに記録されます。
        JBAS014775:    New missing/unsatisfied dependencies
        たとえば、MySQL 5.1.31 ドライバーで必要な DRIVER_NAME 値は mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1 です。
        xa-data-source add --name=XA_DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME --xa-datasource-class=XA_DATASOURCE_CLASS
      2. XA データソースプロパティーの設定

        1. サーバー名の設定

          次のコマンドを実行し、ホストのサーバー名を設定します。
          /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=ServerName:add(value=HOSTNAME)
        2. データベース名の設定

          次のコマンドを実行し、データベース名を設定します。
          /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=DatabaseName:add(value=DATABASE_NAME)
      3. データソースを有効にします。
        xa-data-source enable --name=XA_DATASOURCE_NAME
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

        1. コンソールの上部から Configuration タブを選択します。
        2. ドメインモードの場合は、左上のドロップダウンボックスからプロファイルを選択します。
        3. コンソールの左側にある Subsystems メニューを展開し、Connector メニューを展開します。
        4. Datasources を選択します。
      2. XA Datasource タブを選択します。
      3. 新しい XA データソースを作成します。

        1. 追加 をクリックします。
        2. Create XA Datasource ウィザードに新しい XA データソースの属性を入力し、Next をクリックします。
        3. Create XA Datasource ウィザードに JDBC ドライバーの詳細を入力し、Next をクリックします。
        4. XA プロパティーを入力し、Next をクリックします。
        5. Create XA Datasource ウィザードで接続設定を入力します。
        6. Test Connection ボタンをクリックして XA データソースへの接続をテストし、設定が正しいことを確認します。
        7. Done をクリックして終了します。
結果

XA データソースがサーバーに追加されます。追加内容は standalone.xml または domain.xml ファイルのどちらかと、管理インターフェースで確認することができます。

6.4.2. 管理インターフェースによる XA データソースの編集

概要

ここでは、管理コンソールまたは管理 CLI のいずれかを使用して XA データソースを編集する手順について取り上げます。

手順6.8 管理 CLI または管理コンソールのいずれかを使用した XA データソースの編集

    • 管理 CLI

      1. XA データソース属性の設定

        write-attribute コマンドを使用してデータソース属性を設定します。
        /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)
      2. XA データソースプロパティーの設定

        次のコマンドを実行して XA データソースサブリソースを設定します。
        /subsystem=datasources/xa-data-source=DATASOURCE_NAME/xa-datasource-properties=PROPERTY_NAME:add(value=PROPERTY_VALUE)
      3. サーバーを再ロードして変更を確認します。
        :reload
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

        1. コンソールの上部から Configuration タブを選択します。
        2. ドメインモードの場合は、左上のドロップダウンボックスからプロファイルを選択します。
        3. コンソールの左側にある Subsystems メニューを展開し、Connector メニューを展開します。
        4. Datasources を選択します。
      2. XA Datasource タブを選択します。
      3. データソースを編集します。

        1. Available XA Datasources リストより関連する XA データソースを選択します。下にある Attributes パネルに XA データソースの属性が表示されます。
        2. Edit ボタンを選択してデータソース属性を編集します。
        3. XA データソースの属性を編集し、作業が終了したら Save ボタンを選択します。
結果

XA データソースが設定されます。変更は standalone.xml または domain.xml ファイルのどちらかと、管理インターフェースで確認できます。

6.4.3. 管理インターフェースによる XA データソースの削除

概要

ここでは、管理コンソールまたは管理 CLI を使用して、JBoss EAP 6 から XA データソースを削除するために必要な手順について説明します。

手順6.9 管理 CLI または管理コンソールのいずれかを使用した XA データソースの削除

    • 管理 CLI

      1. 次のコマンドを実行して XA データソースを削除します。
        xa-data-source remove --name=XA_DATASOURCE_NAME
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

        1. コンソールの上部から Configuration タブを選択します。
        2. ドメインモードの場合は、左上のドロップダウンボックスからプロファイルを選択します。
        3. コンソールの左側にある Subsystems メニューを展開し、Connector メニューを展開します。
        4. Datasources を選択します。
      2. XA Datasource タブを選択します。
      3. 削除する登録済みの XA データソースを選択し、Remove をクリックして XA データソースを永久的に削除します。
結果

XA データソースがサーバーより削除されます。

6.4.4. XA リカバリー

6.4.4.1. XA リカバリーモジュール

各 XA リソースは、設定が関連付けられたリカバリーモジュールを必要とします。リカバリーモジュールはクラス com.arjuna.ats.jta.recovery.XAResourceRecovery を拡張する必要があります。
JBoss EAP 6 は、JDBC および JMS XA リソースのリカバリーモジュールを提供します。このようなタイプのリソースでは、リカバリーモジュールは自動的に登録されます。カスタムモジュールを使用する必要がある場合は、データベースに登録できます。

6.4.4.2. XA リカバリーモジュールの設定

ほとんどの JDBC および JMS リソースでは、リカバリーモジュールがリソースに自動的に関連付けられます。この場合は、リカバリーモジュールがリソースに接続してリカバリーを実行することを許可するオプションのみを設定する必要があります。
JDBC または JMS でないカスタムリソースの場合は、サポートされる設定について Red Hat グローバルサポートサービスにお問い合わせください。
これらの各設定属性は、データソースの作成時または作成後に設定できます。設定属性は、Web ベースの管理コンソールまたはコマンドライン管理 CLI を使用して設定できます。XA データソースの設定の一般情報については、「管理インターフェースによる XA データソースの作成」「管理インターフェースによる XA データソースの編集」を参照してください。
一般的なデータソース設定属性と、特定のデータベースベンダーに関連する設定詳細については、以下の表を参照してください。

表6.2 一般的な設定属性

属性 説明
recovery-username
リソースに接続してリカバリー行うためにリカバリーモジュールが使用する必要があるユーザー名。
recovery-password
リソースに接続してリカバリーを行うためにリカバリーモジュールが使用する必要があるパスワード。
recovery-security-domain
リカバリーを行う目的でリカバリーモジュールがリソースに接続するために使用するセキュリティードメイン。
recovery-plugin-class-name
カスタムのリカバリーモジュールを使用する必要がある場合は、この属性をモジュールの完全修飾クラス名に設定します。モジュールはクラス com.arjuna.ats.jta.recovery.XAResourceRecovery を拡張する必要があります。
recovery-plugin-properties
プロパティーを設定する必要があるカスタムのリカバリーモジュールを使用する場合は、この属性をプロパティーに対するコンマ区切りの key=value ペアのリストに設定します。

ベンダー固有の設定情報

Oracle
Oracle データソースが不適切に設定された場合は、ログ出力に次のようなエラーが示されることがあります。

例6.9 不適切な設定エラー

WARN  [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException, XAException.XAER_RMERR
このエラーを解決するには、recovery-username で設定された Oracle ユーザーがリカバリーに必要なテーブルにアクセスできる必要があります。以下の SQL ステートメントは、Oracle バグ 5945463 用のパッチが適用された Oracle 11g または Oracle 10g R2 インスタンスに対する適切なステートメントです。

例6.10 許可設定

GRANT SELECT ON sys.dba_pending_transactions TO recovery-username;
GRANT SELECT ON sys.pending_trans$ TO recovery-username;
GRANT SELECT ON sys.dba_2pc_pending TO recovery-username;
GRANT EXECUTE ON sys.dbms_xa TO recovery-username;
11g よりも前の Oracle 11 バージョンを使用する場合は、最後の EXECUTE ステートメントを以下のように変更します。
	GRANT EXECUTE ON sys.dbms_system TO recovery-username;
PostgreSQL
準備済みトランザクション (XA など) を有効にする手順については、PostgreSQL ドキュメンテーションを参照してください。PostgreSQL の JDBC ドライバーのバージョン 8.4-701 では、org.postgresql.xa.PGXAConnection にバグがあり、特定の状況でリカバリーが中断されます。このバグは新しいバージョンでは修正されています。
MySQL
http://bugs.mysql.com/bug.php?id=12161 に基づき、XA トランザクションリカバリーは一部の MySQL 5 バージョンでは動作しませんでした。この問題は MySQL 6.1 で修正されました。詳細については、バグの URL または MySQL ドキュメンテーションを参照してください。
IBM DB2
IBM DB2 では、クラッシュまたは障害の発生後にアプリケーションサーバーが再起動されたときの指定の再同期ステージの間でのみ XAResource.recover メソッドが呼び出されることを想定します。これは、DB2 実装の設計に関する決まりであり、本書の範囲外となります。
Sybase
Sybase は、XA トランザクションがデータベース上で有効になることを想定します。XA トランザクションはデータベース設定が正しくないと動作しません。enable xact coordination は、Adaptive Server トランザクションコーディネーションサービスを有効または無効にします。このパラメーターを有効にすると、リモート Adaptive Server データのアップデートが、確実に元のトラザクションでコミットまたはロールバックされるようになります。トラザクションコーディネーションを有効にするには、以下を使用します。
sp_configure 'enable xact coordination', 1
.

6.5. データソースセキュリティー

6.5.1. データソースセキュリティー

データソースセキュリティーは、データソース接続のパスワードを暗号化したり分かりにくくすることを言います。これらのパスワードはプレーンテキストで設定ファイルに保存できますが、セキュリティーリスクが高くなります。
データソースセキュリティーの推奨されるソリューションは、セキュリティードメインまたはパスワードボールトのいずれかを使用することです。以下にそれぞれの例を示します。詳細については、 『Security Architecture』と他の JBoss EAP セキュリティードキュメンテーションを参照してください。

例6.11 セキュリティードメインの例

 <security-domain name="DsRealm" cache-type="default">  
  <authentication>  
    <login-module code="ConfiguredIdentity" flag="required">  
      <module-option name="userName" value="sa"/>  
      <module-option name="principal" value="sa"/>  
      <module-option name="password" value="sa"/>  
    </login-module>  
  </authentication>  
</security-domain>
DsRealm ドメインはデータソースによって参照されます。
<datasources>
  <datasource jndi-name="java:jboss/datasources/securityDs"
    pool-name="securityDs">
    <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
      <driver>h2</driver>
      <new-connection-sql>select current_user()</new-connection-sql>
      <security>
        <security-domain>DsRealm</security-domain>
      </security>
    </datasource>
</datasources>

例6.12 パスワードボールトの例

<security>
  <user-name>admin</user-name>
  <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>

6.6. データベース接続の検証

6.6.1. データベース接続検証設定の指定

概要

データベースメンテナンス、ネットワーク問題、または他の停止イベントにより、JBoss EAP 6 がデータベースへの接続を失うことがあります。データベース接続の検証は、サーバー設定ファイルの <datasource> セクション内の <validation> 要素を使用して有効にします。以下の手順に従い、JBoss EAP 6 でデータベース接続検証を有効にするデータソース設定を指定してください。

手順6.10 データベース接続検証設定の指定

  1. 検証方法の選択

    以下のいずれかの検証方法を選択します。
    • <validate-on-match>true</validate-on-match>

      <validate-on-match> オプションが true に設定されている場合は、データ接続が、次の手順で指定された検証メカニズムを使用して接続プールからチェックアウトされるたびに検証されます。
      接続が有効でない場合は、警告がログに書き込まれ、プール内の次の接続が取得されます。このプロセスは、有効な接続が見つかるまで続行します。プール内の各接続を繰り返し処理しない場合は、<use-fast-fail> オプションを使用できます。有効な接続がプールにない場合は、新しい接続が作成されます。接続の作成に失敗すると、例外が要求元アプリケーションに返されます。
      この設定により、最も早いリカバリーが実現されますが、データベースへの負荷が最も大きくなります。ただし、これは、パフォーマンスを気にする必要がない場合は最も安全な方法です。
    • <background-validation>true</background-validation>

      <background-validation> オプションが true に設定されている場合は、<background-validation-millis> 値とともに使用され、バックグラウンド検証実行の頻度を決定します。<background-validation-millis> パラメーターのデフォルト値は 0 ミリ秒であり、デフォルトで無効になります。この値は <idle-timeout-minutes> 設定と同じ値に設定しないでください。
      特定のシステムの <background-validation-millis> 値を決定するには注意が必要です。値が小さいと、プールの検証頻度が多くなり、無効な接続がプールからすぐに削除されます。 ただし、値が小さいと、より多くのデータベースリソースが使用されます。値が大きい場合は、接続検証チェックの頻度が少なくなり、より少ないデータベースリソースが使用されますが、デッド接続は長時間検出されません。

    注記

    <validate-on-match> オプションが true に設定されている場合は、<background-validation> オプションを false に設定する必要があります。それとは逆に、<background-validation> オプションが true に設定されている場合は、<validate-on-match> オプションを false に設定する必要があります。
  2. 検証メカニズムの選択

    以下のいずれかの検証メカニズムを選択します。
    • <valid-connection-checker> クラス名の指定

      これは、使用中の特定の RDBMS に対して最適化されるため、推奨されるメカニズムです。JBoss EAP 6 は、以下の接続チェッカーを提供します。
      • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker
    • <check-valid-connection-sql> 用 SQL の指定

      接続を検証するために使用する SQL ステートメントを提供します。
      以下は、Oracle 用接続を検証するために SQL ステートメントをどのように指定するかの例です。
      <check-valid-connection-sql>select 1 from dual</check-valid-connection-sql>
      MySQL または PostgreSQL の場合は、以下の SQL ステートメントを指定する必要があります。
      <check-valid-connection-sql>select 1</check-valid-connection-sql>
  3. <exception-sorter> クラス名の設定

    例外が致命的とマークされた場合、接続はトランザクションに参加していてもすぐに閉じられます。致命的な接続例外を適切に検出およびクリーンアップするには、例外ソータークラスオプションを使用します。JBoss EAP 6 は、以下の例外ソーターを提供します。
    • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.informix.InformixExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter

6.7. データソース設定

6.7.1. データソースのパラメーター

表6.3 非 XA および XA データソースに共通のデータソースパラメーター

パラメーター 説明
jndi-name データソースの一意の JNDI 名。
pool-name データソースの管理プール名。
enabled データソースが有効かどうかを指定します。
use-java-context
データソースをグローバルの JNDI にバインドするかどうかを指定します。
spy
JDBC レイヤーで spy 機能を有効にします。この機能は、データソースへの JDBC トラフィックをすべてログに記録します。ロギングカテゴリーの jboss.jdbc.spy もロギングサブシステムのログレベルである DEBUG に設定する必要があることに注意してください。
use-ccm キャッシュ接続マネージャーを有効にします。
new-connection-sql 接続プールに接続が追加された時に実行する SQL ステートメント。
transaction-isolation
次のいずれかになります。
  • TRANSACTION_READ_UNCOMMITTED
  • TRANSACTION_READ_COMMITTED
  • TRANSACTION_REPEATABLE_READ
  • TRANSACTION_SERIALIZABLE
  • TRANSACTION_NONE
url-selector-strategy-class-name インターフェース org.jboss.jca.adapters.jdbc.URLSelectorStrategy を実装するクラス。
security
セキュリティー設定である子要素が含まれます。表6.8「セキュリティーパラメーター」を参照してください。
validation
検証設定である子要素が含まれます。表6.9「検証パラメーター」を参照してください。
timeout
タイムアウト設定である子要素が含まれます。表6.10「タイムアウトパラメーター」を参照してください。
statement
ステートメント設定である子要素が含まれます。表6.11「ステートメントのパラメーター」を参照してください。

表6.4 非 XA データソースのパラメーター

パラメーター 説明
jta 非 XA データソースの JTA 統合を有効にします。XA データソースには適用されません。
connection-url JDBC ドライバーの接続 URL。
driver-class JDBC ドライバークラスの完全修飾名。
connection-property
Driver.connect(url,props) メソッドに渡される任意の接続プロパティー。各 connection-property は、文字列名と値のペアを指定します。プロパティー名は名前、値は要素の内容に基づいています。
pool
プーリング設定である子要素が含まれます。表6.6「非 XA および XA データソースに共通のプールパラメーター」を参照してください。
url-delimiter
高可用性 (HA) クラスター化されたデータベースの connection-url にある URL の区切り文字。 

表6.5 XA データソースのパラメーター

パラメーター 説明
xa-datasource-property
実装クラス XADataSource に割り当てるプロパティー。name=value で指定されます。 setName という形式で setter メソッドが存在する場合、プロパティーは setName(value) という形式の setter メソッドを呼び出すことで設定されます。
xa-datasource-class
実装クラス javax.sql.XADataSource の完全修飾名。
driver
JDBC ドライバーが含まれるクラスローダーモジュールへの一意参照。driverName#majorVersion.minorVersion の形式にのみ対応しています。
xa-pool
プーリング設定である子要素が含まれます。表6.6「非 XA および XA データソースに共通のプールパラメーター」および表6.7「XA プールパラメーター」を参照してください。
recovery
リカバリー設定である子要素が含まれます。表6.12「リカバリーパラメーター」を参照してください。

表6.6 非 XA および XA データソースに共通のプールパラメーター

パラメーター 説明
min-pool-size プールが保持する最小接続数
max-pool-size プールが保持可能な最大接続数
prefill 接続プールのプレフィルを試行するかどうかを指定します。要素が空の場合は true を示します。デフォルト値は、false です。
use-strict-min pool-size が厳密かどうかを指定します。デフォルト値は false に設定されています。
flush-strategy
エラーの場合にプールをフラッシュするかどうかを指定します。有効な値は次の通りです。
  • FailingConnectionOnly
  • IdleConnections
  • EntirePool
デフォルト値は FailingConnectionOnly です。
allow-multiple-users 複数のユーザーが getConnection(user, password) メソッドを使いデータソースへアクセスするかどうか、および内部プールタイプがこの動作に対応するかを指定します。

表6.7 XA プールパラメーター

パラメーター 説明
is-same-rm-override javax.transaction.xa.XAResource.isSameRM(XAResource) クラスが true あるいは false のどちらを返すかを指定します。
interleaving XA 接続ファクトリーのインターリービングを有効にするかどうかを指定します。
no-tx-separate-pools
コンテキスト毎に sub-pool を作成するかどうか。これには Oracle のデータソースが必要ですが、JTA トランザクションの内部と外部の両方で XA 接続が使用できなくなります。
このオプションを使用することにより、2 つの実際のファイルが作成されるため、プールサイズの合計が max-pool-size の 2 倍になります。
pad-xid Xid のパディングを行うかどうかを指定します。
wrap-xa-resource
XAResource を org.jboss.tm.XAResourceWrapper インスタンスでラップするかどうかを指定します。

表6.8 セキュリティーパラメーター

パラメーター 説明
user-name 新規接続の作成に使うユーザー名
password 新規接続の作成に使うパスワード
security-domain 認証処理を行う JAAS security-manager 名が含まれます。この名前は、JAAS ログイン設定の application-policy/name 属性に相関します。
reauth-plugin 物理接続の再認証に使う再認証プラグインを定義します。

表6.9 検証パラメーター

パラメーター 説明
valid-connection-checker
SQLException.isValidConnection(Connection e) メソッドを提供し接続を検証するインターフェース org.jboss.jca.adaptors.jdbc.ValidConnectionChecker の実装。例外が発生すると接続が破棄されます。存在する場合、check-valid-connection-sql パラメーターが上書きされます。
check-valid-connection-sql プール接続の妥当性を確認する SQL ステートメント。これは、管理接続をプールから取得し利用する場合に呼び出される場合があります。
validate-on-match
接続ファクトリーが指定のセットに対して管理された接続に一致させようとした時に接続レベルの検証を実行するかどうかを示します。
通常、validate-on-match に「true」を指定した時に background-validation を「true」に指定することはありません。クライアントが使用前に接続を検証する必要がある場合に Validate-on-match が必要になります。このパラメーターはデフォルトでは false になっています。
background-validation
接続がバックグラウンドスレッドで検証されることを指定します。validate-on-match を使用しない場合、バックグラウンドの検証はパフォーマンスを最適化します。validate-on-match が true の時に background-validation を使用すると、チェックが冗長になることがあります。バックグラウンド検証では、不良の接続がクライアントに提供される可能性があります (検証スキャンと接続がクライアントに提供されるまでの間に接続が悪くなります)。そのため、クライアントアプリケーションはこの接続不良の可能性に対応する必要があります。
background-validation-millis バックグラウンド検証を実行する期間 (ミリ秒単位)。
use-fast-fail
true の場合、接続が無効であれば最初に接続を割り当てしようとした時点で失敗します。デフォルト値は false です。
stale-connection-checker
ブール値の isStaleConnection(SQLException e) メソッドを提供する org.jboss.jca.adapters.jdbc.StaleConnectionChecker のインスタンス。このメソッドが true を返すと、SQLException のサブクラスである org.jboss.jca.adapters.jdbc.StaleConnectionException に例外がラップされます。
exception-sorter
ブール値である isExceptionFatal(SQLException e) メソッドを提供する org.jboss.jca.adapters.jdbc.ExceptionSorter のインスタンス。このメソッドは、例外が connectionErrorOccurred メッセージとして javax.resource.spi.ConnectionEventListener のすべてのインスタンスへブロードキャストされるかどうかを検証します。

表6.10 タイムアウトパラメーター

パラメーター 説明
use-try-lock lock() の代わりに tryLock() を使用します。これは、ロックが使用できない場合に即座に失敗するのではなく、設定された秒数間ロックの取得を試みます。デフォルト値は 60 秒です。たとえば、タイムアウトを 5 分に設定するには、<use-try-lock>300</use-try-lock> を設定します。
blocking-timeout-millis 接続待機中にブロックする最大時間 (ミリ秒)。この時間を超過すると、例外が発生します。これは、接続許可の待機中のみブロックし、新規接続の作成に長時間要している場合は例外が発生しません。デフォルト値は 30000 (30 秒) です。
idle-timeout-minutes
アイドル接続が切断されるまでの最大時間 (分単位)。実際の最大時間は idleRemover のスキャン時間によって異なります。idleRemover のスキャン時間はプールの最小 idle-timeout-minutes の半分になります。
set-tx-query-timeout
トランザクションがタイムアウトするまでの残り時間を基にクエリーのタイムアウトを設定するかどうかを指定します。トランザクションが存在しない場合は設定済みのクエリーのタイムアウトが使用されます。デフォルト値は false です。
query-timeout クエリーのタイムアウト (秒)。デフォルト値はタイムアウトなしです。
allocation-retry 例外を発生させる前に接続の割り当てを再試行する回数。デフォルト値は 0 で、初回の割り当て失敗で例外が発生します。
allocation-retry-wait-millis
接続の割り当てを再試行するまで待機する期間 (ミリ秒単位)。デフォルト値は 5000 (5 秒) です。
xa-resource-timeout
ゼロでない場合、この値は XAResource.setTransactionTimeout メソッドへ渡されます。

表6.11 ステートメントのパラメーター

パラメーター 説明
track-statements
接続がプールへ返され、ステートメントが準備済みステートメントキャッシュへ返された時に、閉じられていないステートメントをチェックするかどうかを指定します。false の場合、ステートメントは追跡されません。

有効な値

  • true: ステートメントと結果セットが追跡され、ステートメントが閉じられていない場合は警告が出力されます。
  • false: ステートメントと結果セットのいずれも追跡されません。
  • nowarn: ステートメントは追跡されますが、警告は出力されません。これがデフォルト設定となっています。
prepared-statement-cache-size LRU (Least Recently Used) キャッシュにある接続毎の準備済みステートメントの数。
share-prepared-statements
閉じずに同じステートメントを 2 回要求した場合に、同じ基盤の準備済みステートメントを使用するかどうかを指定します。デフォルト値は false です。

表6.12 リカバリーパラメーター

パラメーター 説明
recover-credential リカバリーに使用するユーザー名とパスワードのペア、あるいはセキュリティドメイン。
recover-plugin
リカバリーに使用される org.jboss.jca.core.spi.recoveryRecoveryPlugin クラスの実装。

6.7.2. データソース接続 URL

表6.13 データソース接続 URL

データソース 接続 URL
PostgreSQL jdbc:postgresql://SERVER_NAME:PORT/DATABASE_NAME
MySQL jdbc:mysql://SERVER_NAME:PORT/DATABASE_NAME
Oracle jdbc:oracle:thin:@ORACLE_HOST:PORT:ORACLE_SID
IBM DB2 jdbc:db2://SERVER_NAME:PORT/DATABASE_NAME
Microsoft SQLServer jdbc:sqlserver://SERVER_NAME:PORT;DatabaseName=DATABASE_NAME

注記

jdbc:microsoft:sqlserver://SERVER_NAME:PORT;DatabaseName=DATABASE_NAME テンプレートは、新しいデータベースで動作しません。

6.7.3. データソースの拡張

データソースのデプロイメントは、JDBC リソースアダプターにある複数の拡張を使用して接続の検証を改善でき、例外が接続を再確立するべきかどうかを確認できます。これらの拡張は次のとおりです。

表6.14 データソースの拡張

データソースの拡張 設定パラメーター 説明
org.jboss.jca.adapters.jdbc.spi.ExceptionSorter <exception-sorter> SQLException が発生した接続にとってこの例外は致命的かどうかを確認します。
org.jboss.jca.adapters.jdbc.spi.StaleConnection <stale-connection-checker> org.jboss.jca.adapters.jdbc.StaleConnectionException の古い SQLExceptions をラップします。
org.jboss.jca.adapters.jdbc.spi.ValidConnection <valid-connection-checker> アプリケーションによる接続の使用が有効であるかどうかを確認します。
JBoss EAP 6 は、これらの拡張の実装を、サポートされるいくつかのデータベース用に提供します。

拡張の実装

汎用
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullStaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
PostgreSQL
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
MySQL
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
IBM DB2
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
Sybase
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker
Microsoft SQLServer
  • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
Oracle
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker

6.7.4. データソース統計の表示

以下のコマンドを適切に編集すると、jdbc および pool の定義済みデータソースより統計を表示できます。

例6.13 データソース統計の取得

/subsystem=datasources/data-source=ExampleDS/statistics=jdbc:read-resource(include-runtime=true)
または
/subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)

注記

統計はすべてランタイムのみの情報で、デフォルト値は false であるため、必ず include-runtime=true 引数を指定するようにしてください。

6.7.5. データソースの統計

主要統計

サポートされるデータソースの主要統計は下表のとおりです。

表6.15 主要統計

名前 説明
ActiveCount
アクティブな接続の数。各接続はアプリケーションによって使用されているか、プールで使用可能な状態であるかのいずれかになります。
AvailableCount
プールの使用可能な接続の数。
AverageBlockingTime
プールの排他ロックの取得をブロックするために費やされた平均時間。値はミリ秒単位です。
AverageCreationTime
接続の作成に費やされた平均時間。値はミリ秒単位です。
CreatedCount
作成された接続の数。
DestroyedCount
破棄された接続の数。
InUseCount
現在使用中の接続の数。
MaxCreationTime
接続の作成にかかった最大時間。値はミリ秒単位です。
MaxUsedCount
使用される接続の最大数。
MaxWaitCount
同時に接続を待機する要求の最大数。
MaxWaitTime
プールの排他ロックの待機に費やされた最大時間。
TimedOut
タイムアウトした接続の数。
TotalBlockingTime
プールの排他ロックの待機に費やされた合計時間。値はミリ秒単位です。
TotalCreationTime
接続の作成に費やされた合計時間。値はミリ秒単位です。
WaitCount
接続を待機する必要がある要求の数。
JDBC の統計

サポートされるデータソースの JDBC 統計は下表のとおりです。

表6.16 JDBC の統計

名前 説明
PreparedStatementCacheAccessCount
ステートメントキャッシュがアクセスされた回数。
PreparedStatementCacheAddCount
ステートメントキャッシュに追加されたステートメントの数。
PreparedStatementCacheCurrentSize
ステートメントキャッシュに現在キャッシュされた準備済みおよび呼び出し可能ステートメントの数。
PreparedStatementCacheDeleteCount
キャッシュから破棄されたステートメントの数。
PreparedStatementCacheHitCount
キャッシュからのステートメントが使用された回数。
PreparedStatementCacheMissCount
ステートメント要求がキャッシュのステートメントと一致しなかった回数。
以下のコマンドの適切に変更されたバージョンを使用すると、CoreJDBC の統計を有効にできます。
  • /subsystem=datasources/data-source=ExampleDS/statistics=pool:write-attribute(name=statistics-enabled,value=true)
    
    /subsystem=datasources/data-source=ExampleDS/statistics=jdbc:write-attribute(name=statistics-enabled,value=true)
    

6.8. データソース例

6.8.1. PostgreSQL のデータソースの例

PostgreSQL のデータソースの設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。

例6.14 PostSQL データソース設定

<datasources>
  <datasource jndi-name="java:jboss/PostgresDS" pool-name="PostgresDS">
    <connection-url>jdbc:postgresql://localhost:5432/postgresdb</connection-url>
    <driver>postgresql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 PostgreSQL データソースの module.xml ファイルの例は次のとおりです。

例6.15 module.xml

<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.2. PostgreSQL XA のデータソースの例

PostgreSQL XA のデータソースの設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。

例6.16 PostSQL XA データソース

<datasources>
  <xa-datasource jndi-name="java:jboss/PostgresXADS" pool-name="PostgresXADS">
    <driver>postgresql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">postgresdb</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker">
      </valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter">
      </exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 PostgreSQL XA データソースの module.xml ファイルの例は次のとおりです。

例6.17 module.xml

<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.3. MySQL のデータソースの例

MySQL のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。

例6.18 MySQL データソース設定

<datasources>
  <datasource jndi-name="java:jboss/MySqlDS" pool-name="MySqlDS">
    <connection-url>jdbc:mysql://mysql-localhost:3306/jbossdb</connection-url>
    <driver>mysql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 MySQL データソースの module.xml ファイルの例は次のとおりです。

例6.19 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.4. MySQL XA のデータソースの例

MySQL XA のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。

例6.20 MySQL XA データソース

<datasources>
  <xa-datasource jndi-name="java:jboss/MysqlXADS" pool-name="MysqlXADS">
  <driver>mysql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mysqldb</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 MySQL XA データソースの module.xml ファイルの例は次のとおりです。

例6.21 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.5. Oracle のデータソースの例

注記

バージョン 10.2 以前の Oracle データソースでは非トランザクション接続とトランザクション接続が混在するとエラーが発生したため、<no-tx-separate-pools/> パラメーターが必要でした。一部のアプリケーションでは、このパラメーターが不要になりました。
Oracle のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。

例6.22 Oracle データソース設定

<datasources>
  <datasource jndi-name="java:/OracleDS" pool-name="OracleDS">
    <connection-url>jdbc:oracle:thin:@localhost:1521:XE</connection-url>
    <driver>oracle</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記の Oracle データソースの module.xml ファイルの例は次のとおりです。

例6.23 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.6. Oracle XA データソースの例

注記

バージョン 10.2 以前の Oracle データソースでは非トランザクション接続とトランザクション接続が混在するとエラーが発生したため、<no-tx-separate-pools/> パラメーターが必要でした。一部のアプリケーションでは、このパラメーターが不要になりました。

重要

Oracle XA データソースにアクセスするユーザーは、以下の設定を適用しないと XA リカバリーが適切に操作しません。値 user は、JBoss から Oracle に接続するために定義されたユーザーです。
  • GRANT SELECT ON sys.dba_pending_transactions TO user;
  • GRANT SELECT ON sys.pending_trans$ TO user;
  • GRANT SELECT ON sys.dba_2pc_pending TO user;
  • GRANT EXECUTE ON sys.dbms_xa TO user; (パッチ済みの Oracle 10g R2、または Oracle 11g を使用する場合)
    または、
    GRANT EXECUTE ON sys.dbms_system TO user; (パッチされていない 11g 以前のバージョンの Oracle を使用する場合)
Oracle XA のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。

例6.24 Oracle XA データソース

<datasources>
  <xa-datasource jndi-name="java:/XAOracleDS" pool-name="XAOracleDS">
    <driver>oracle</driver>
    <xa-datasource-property name="URL">jdbc:oracle:oci8:@tc</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
      <no-tx-separate-pools />
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 Oracle XA データソースの module.xml ファイルの例は次のとおりです。

例6.25 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.7. Microsoft SQLServer のデータソースの例

Microsoft SQLServer のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。

例6.26 SQLserver データソース設定

<datasources>
  <datasource jndi-name="java:/MSSQLDS" pool-name="MSSQLDS">
    <connection-url>jdbc:sqlserver://localhost:1433;DatabaseName=MyDatabase</connection-url>
    <driver>sqlserver</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
</datasources>
上記 Microsoft SQLServer データソースの module.xml ファイルの例は次のとおりです。

例6.27 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.8. Microsoft SQLServer XA のデータソースの例

Microsoft SQLServer XA のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。

例6.28 SQLserver XA データソース

<datasources>
  <xa-datasource jndi-name="java:/MSSQLXADS" pool-name="MSSQLXADS">
    <driver>sqlserver</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mssqldb</xa-datasource-property>
    <xa-datasource-property name="SelectMethod">cursor</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記の Microsoft SQLServer XA データソースの module.xml ファイルの例は次のとおりです。

例6.29 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.9. IBM DB2 のデータソースの例

IBM DB2 のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。

例6.30 IBM DB2 データソース設定

<datasources>
  <datasource jndi-name="java:/DB2DS" pool-name="DB2DS">
    <connection-url>jdbc:db2:ibmdb2db</connection-url>
    <driver>ibmdb2</driver>
    <pool>
      <min-pool-size>0</min-pool-size>
      <max-pool-size>50</max-pool-size>
    </pool>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
      <xa-datasource-class>com.ibm.db2.jdbc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 IBM DB2 データソースの module.xml ファイルの例は次のとおりです。

例6.31 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.10. IBM DB2 XA のデータソースの例

IBM DB2 XA のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。

例6.32 IBM DB2 XA データソース設定

<datasources>
  <xa-datasource jndi-name="java:/DB2XADS" pool-name="DB2XADS">
    <driver>ibmdb2</driver>
    <xa-datasource-property name="DatabaseName">ibmdb2db</xa-datasource-property>
    <xa-datasource-property name="ServerName">hostname</xa-datasource-property>
    <xa-datasource-property name="PortNumber">port</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
    <recovery>
      <recover-plugin class-name="org.jboss.jca.core.recovery.ConfigurableRecoveryPlugin">
        <config-property name="EnableIsValid">false</config-property>
        <config-property name="IsValidOverride">false</config-property>
        <config-property name="EnableClose">false</config-property>
      </recover-plugin>
    </recovery>
  </xa-datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
      <xa-datasource-class>com.ibm.db2.jcc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 IBM DB2 XA データソースの module.xml ファイルの例は次のとおりです。

例6.33 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc4.jar"/>
    <resource-root path="db2jcc_license_cisuz.jar"/>
    <resource-root path="db2jcc_license_cu.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.11. Sybase データソースの例

Sybase データソースの設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。

例6.34 Sybase データソース設定

<datasources>
  <datasource jndi-name="java:jboss/SybaseDB" pool-name="SybaseDB" enabled="true">
    <connection-url>jdbc:sybase:Tds:localhost:5000/DATABASE?JCONNECT_VERSION=6</connection-url>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc4.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc4.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 Sybase データソースの module.xml ファイルの例は次のとおりです。

例6.35 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.sybase">
  <resources>
    <resource-root path="jconn2.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.12. Sybase XA データソースの例

Sybase XA データソースの設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。

例6.36 Sybase XA データソース設定

<datasources>
  <xa-datasource jndi-name="java:jboss/SybaseXADS" pool-name="SybaseXADS" enabled="true">
    <xa-datasource-property name="NetworkProtocol">Tds</xa-datasource-property>
    <xa-datasource-property name="ServerName">myserver</xa-datasource-property>
    <xa-datasource-property name="PortNumber">4100</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mydatabase</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc4.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc4.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 Sybase XA データソースの module.xml ファイルの例は次のとおりです。

例6.37 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.sybase">
  <resources>
    <resource-root path="jconn2.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

第7章 モジュールの設定

7.1. はじめに

7.1.1. モジュール

モジュールは、クラスローディングおよび依存関係管理に使用されるクラスの論理グループです。JBoss EAP 6 は、静的および動的モジュールと呼ばれる 2 つのタイプのモジュールを識別します。この 2 つのタイプのモジュールは、パッケージ化された方法のみが異なります。
静的モジュール
静的モジュールは、アプリケーションサーバーの EAP_HOME/modules/ ディレクトリーに事前定義されます。各サブディレクトリーは 1 つのモジュールを表し、設定ファイル (module.xml) および必要な JAR ファイルが含まれる main/ サブディレクトリーを定義します。モジュールの名前は、module.xml ファイルで定義されます。アプリケーションサーバーによって提供されるすべての API (Java EE API や、JBoss Logging などのその他の API を含む) は、静的モジュールとして提供されます。

例7.1 module.xml ファイルの例

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.1.15.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
main/ サブディレクトリー名以外のモジュール名 com.mysql はそのモジュールのディレクトリー構造と一致する必要があります。
JBoss EAP ディストリビューションで提供されるモジュールは、JBOSS_HOME/modules ディレクトリー内の system ディレクトリーにあります。そのため、サードパーティーによって提供されるモジュールから分離されます。
JBoss EAP 6.1 またはそれ以降のバージョンの上部レイヤーにある Red Hat 提供のレイヤー製品も、モジュールを system ディレクトリー内にインストールします。
カスタム静的モジュールの作成は、同じサードパーティーライブラリーを使用する同じサーバー上に多くのアプリケーションがデプロイされる場合に役立ちます。これらのライブラリーを各アプリケーションとバンドルする代わりに、JBoss 管理者はこれらのライブラリーが含まれるモジュールを作成およびインストールできます。アプリケーションは、カスタム静的モジュールで明示的な依存関係を宣言できます。
モジュール毎のディレクトリーになるよう、カスタムモジュールが JBOSS_HOME/modules ディレクトリーにインストールされるようにする必要があります。こうすると、同梱されたバージョンではなく、system ディレクトリーに存在するカスタムバージョンのモジュールがロードされるようになります。これにより、ユーザー提供のモジュールがシステムモジュールよりも優先されます。
JBOSS_MODULEPATH 環境変数を使用して JBoss EAP がモジュールを検索する場所を変更する場合、指定された場所の 1 つで system サブディレクトリー構造を探します。system 構造は、JBOSS_MODULEPATH で指定された場所のどこかに存在する必要があります。
動的モジュール
動的モジュールは、各 JAR または WAR デプロイメント (または、EAR 内のサブデプロイメント) に対してアプリケーションサーバーによって作成およびロードされます。動的モジュールの名前は、デプロイされたアーカイブの名前から派生されます。デプロイメントはモジュールとしてロードされるため、依存関係を設定でき、他のデプロイメントは依存関係として使用することが可能です。
モジュールは必要なときのみロードされます。通常、明示的または暗黙的な依存関係があるアプリケーションがデプロイされるときのみ、モジュールがロードされます。

7.1.2. グローバルモジュール

グローバルモジュールは、JBoss EAP 6 がすべてのアプリケーションへの依存関係として提供するモジュールです。このモジュールをアプリケーションサーバーのグローバルモジュールリストへ追加すると、どのモジュールもグローバルモジュールになります。モジュールへの変更は必要ありません。

7.1.3. モジュールの依存性

モジュール依存関係とは、あるモジュールが機能するには別のモジュールのクラスが必要になるという宣言です。モジュールはいくつでも他のモジュールの依存関係を宣言することができます。アプリケーションサーバーがモジュールをロードするとき、モジュールクラスローダーがモジュールの依存関係を解析し、各依存関係のクラスをクラスパスに追加します。指定の依存関係が見つからない場合、モジュールはロードできません。
デプロイされたアプリケーション (JAR または WAR) は動的モジュールとしてロードされ、依存関係を利用して JBoss EAP 6 によって提供される API にアクセスします。
依存関係には明示的と暗黙的の 2 つのタイプがあります。
明示的な依存関係は開発者が設定に宣言します。静的モジュールでは、依存関係を modules.xml ファイルに宣言できます。動的モジュールでは、デプロイメントの MANIFEST.MF または jboss-deployment-structure.xml デプロイメント記述子に依存関係を宣言できます。
明示的な依存関係は、任意の依存関係として指定できます。任意の依存関係をロードできなくても、モジュールによるロードは失敗しません。しかし、依存関係が後で使用できるようになっても、モジュールのクラスパスには追加されません。モジュールがロードされるときに依存関係が使用できなければなりません。
暗黙的な依存関係は、デプロイメントで特定の状態やメタデータが見つかったときに、アプリケーションサーバーによって自動的に追加されます。JBoss EAP 6 に同梱される Java EE 6 API は、デプロイメントで暗黙的な依存関係が検出されたときに追加されるモジュールの例になります。
デプロイメントを設定して特定の暗黙的な依存関係を除外することも可能です。この設定は jboss-deployment-structure.xml デプロイメント記述子ファイルで行います。これは、アプリケーションサーバーが暗黙的な依存関係として追加しようとする特定バージョンのライブラリーを、アプリケーションがバンドルする場合に一般的に行われます。
モジュールのクラスパスには独自のクラスとその直接の依存関係のみが含まれます。モジュールは 1 つの依存関係の依存関係クラスにはアクセスできませんが、暗黙的な依存関係のエクスポートを指定できます。エクスポートされた依存関係は、エクスポートするモジュールに依存するモジュールへ提供されます。

例7.2 モジュールの依存関係

モジュール A はモジュール B に依存し、モジュール B はモジュール C に依存します。モジュール A はモジュール B のクラスにアクセスでき、モジュール B はモジュール C のクラスにアクセスできます。以下の場合を除き、モジュール A はモジュール C のクラスにはアクセスできません。
  • モジュール A がモジュール C への明示的な依存関係を宣言する場合。
  • または、モジュール B がモジュール B の依存関係をモジュール C でエクスポートする場合。

7.1.4. サブデプロイメントクラスローダーの分離

エンタープライズアーカイブ (EAR) の各サブデプロイメントは独自のクラスローダーを持つ動的モジュールです。デフォルトでは、サブデプロイメントは他のサブデプロイメントのリソースにアクセスできます。
サブデプロイメントが他のサブデプロイメントのリソースにアクセスすべきでない場合 (厳格なサブデプロイメントの分離が必要な場合) は、この挙動を有効にできます。

7.2. すべてのデプロイメントを対象とするサブデプロイメントモジュール分離の無効化

このタスクでは、サーバー管理者がアプリケーションサーバーでサブデプロイメントモジュールの分離を無効化する方法を説明します。このタスクは、すべてのデプロイメントに影響します。

警告

このタスクでは、サーバーの XML 設定ファイルを編集する必要があります。この作業を行う前に、サーバーを停止する必要があります。最終リリースの管理ツールでは、このような設定がサポートされるようになるため、これは一時的な措置になります。
  1. サーバーの停止

    JBoss EAP 6 サーバーを停止します。
  2. サーバー設定ファイルを開く

    サーバー設定ファイルをテキストエディターで開きます。
    このファイルは、管理対象ドメインまたはスタンドアロンサーバーによって異なります。また、デフォルト以外の場所とファイル名が使用されることがあります。デフォルトの設定ファイルは、 domain/configuration/domain.xml (管理対象ドメインの場合) と standalone/configuration/standalone.xml (スタンドアロンサーバー) です。
  3. EE サブシステム設定の特定

    設定ファイルの EE サブシステム設定要素を特定します。設定ファイルの <profile> 要素には、複数のサブシステム要素が含まれます。EE サブシステム要素には urn:jboss:domain:ee:1.2 のネームスペースがあります。
    <profile>
    
       ...
    
       <subsystem xmlns="urn:jboss:domain:ee:1.2" />
    
       ...
    デフォルト設定には単一の自己終了タグがありますが、カスタム設定は、以下のような個別の開始タグと終了タグを持つことがあります (タグ間に別の要素が含まれることがあります)。
    <subsystem xmlns="urn:jboss:domain:ee:1.2" ></subsystem>
  4. 自己終了タグの置き換え (必要な場合)

    EE サブシステム要素が単一の自己終了タグである場合は、以下のように適切な開始タグと終了タグで置き換えます。
    <subsystem xmlns="urn:jboss:domain:ee:1.2" ></subsystem>
  5. ear-subdeployments-isolated 要素の追加

    以下のように、ear-subdeployments-isolated 要素を EE サブシステム要素の子として追加し、false の内容を追加します。
    <subsystem xmlns="urn:jboss:domain:ee:1.2" ><ear-subdeployments-isolated>false</ear-subdeployments-isolated></subsystem>
  6. サーバーの起動

    新しい設定で実行されるよう JBoss EAP 6 サーバーを再起動します。
結果

すべてのデプロイメントに対してサブデプロイメントモジュール分離が無効化された状態で、サーバーが実行されます。

7.3. すべてのデプロイメントへのモジュールの追加

このタスクは JBoss 管理者によるグローバルモジュールリストの定義方法を実証します。

前提条件

  1. グローバルモジュールとして設定されるモジュールの名前を知っている必要があります。JBoss EAP 6 に含まれる静的モジュールの一覧は、「含まれるモジュール」を参照してください。モジュールが他のデプロイメントにある場合は、「動的モジュールの名前付け」を参照してモジュール名を判断してください。

手順7.1 グローバルモジュールリストへのモジュールの追加

  1. 「管理コンソールへのログイン」に従って、管理コンソールへログインします。
  2. EE Subsystem パネルへ移動します。
    1. コンソールの上部から Configuration タブを選択します。
    2. ドメインモードの場合

      1. 左上のドロップダウンボックスより該当するプロファイルを選択します。
    3. コンソールの左側にある Subsystems メニューを展開します。
    4. コンソールの左側にあるメニューより ContainerEE の順で選択します。
  3. Subsystem Defaults セクションの Add をクリックします。Create Module ダイアログが表示されます。
  4. モジュールの名前と任意でモジュールスロットを入力します。
  5. Save をクリックして新しいグローバルモジュールを追加するか、 Cancel をクリックしてキャンセルします。
    • Save をクリックすると、ダイアログが閉じられ指定のモジュールがグローバルモジュールのリストに追加されます。
    • Cancel をクリックするとダイアログが閉じられ、何も変更されません。
結果

グローバルモジュールのリストに追加されたモジュールは各デプロイメントへの依存関係に追加されます。

7.4. カスタムモジュールの作成

次の手順では、JBoss EAP サーバー上で実行されているすべてのアプリケーションがプロパティーファイルやその他のリソースを使用できるようにするために、カスタムモジュールを作成する方法について説明します。

手順7.2 カスタムモジュールの作成

  1. module/ ディレクトリー構造を作成し、ファイルを追加します。
    1. EAP_HOME/module ディレクトリー下にディレクトリー構造を作成し、ファイルや JAR が含まれるようにします。例は次のとおりです。
      $ cd EAP_HOME/modules/ 
      $ mkdir -p myorg-conf/main/properties
    2. 作成した EAP_HOME/modules/myorg-conf/main/properties/ ディレクトリーにプロパティーファイルを移動します。
    3. 次の XML が含まれる module.xml ファイルを EAP_HOME/modules/myorg-conf/main/ ディレクトリーに作成します。
      <module xmlns="urn:jboss:module:1.1" name="myorg-conf">
          <resources>
              <resource-root path="properties"/>
          </resources>
      </module>
  2. サーバー設定ファイルの ee サブシステムを編集します。JBoss CLI を使用するか、手作業でファイルを編集します。
    • 次の手順に従って JBoss CLI を使用し、サーバー設定ファイルを編集します。
      1. サーバーを起動し、管理 CLI へ接続します。
        • Linux の場合は、コマンドラインで以下を入力します。
           EAP_HOME/bin/jboss-cli.sh --connect
        • Windows の場合は、コマンドラインで以下を入力します。
          C:\>EAP_HOME\bin\jboss-cli.bat --connect
        次の応答が表示されるはずです。
        Connected to standalone controller at localhost:9999
      2. ee サブシステムに myorg-conf <global-modules> 要素を作成するには、コマンドラインで以下を入力します。
        /subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])
        次の結果が表示されるはずです。
        {"outcome" => "success"}
    • サーバー設定ファイルを手作業で編集する場合は、次の手順に従ってください。
      1. サーバーを停止し、テキストエディターでサーバー設定ファイルを開きます。スタンドアロンサーバーを実行している場合は、EAP_HOME/standalone/configuration/standalone.xml ファイルになります。管理対象ドメインを実行している場合は、EAP_HOME/domain/configuration/domain.xml ファイルになります。
      2. ee サブシステムを見つけ、myorg-conf のグローバルモジュールを追加します。以下は、myorg-conf 要素が含まれるように編集された ee サブシステム要素の例になります。

        例7.3 myorg-conf element

        <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
            <global-modules>
                <module name="myorg-conf" slot="main" />            
            </global-modules>
        </subsystem>
  3. my.properties という名前のファイルを正しいモジュールの場所にコピーした場合は、以下のようなコードを使用してプロパティーファイルをロードできるようになります。

    例7.4 プロパティーファイルのロード

    Thread.currentThread().getContextClassLoader().getResource("my.properties");

7.5. 外部 JBoss モジュールディレクトリーの定義

概要

デフォルトでは、JBoss EAP は EAP_HOME/modules/ ディレクトリーのモジュールを探します。JBoss EAP が 1 つまたは複数の外部ディレクトリーを検索するようにするには、JBOSS_MODULEPATH 環境変数を定義するか、起動設定ファイルに変数を設定します。本トピックでは両方の方法について説明します。

手順7.3 JBOSS_MODULEPATH 環境変数の設定

  • 1 つ以上の外部モジュールディレクトリーを指定するには、JBOSS_MODULEPATH 環境変数を定義します。
    Linux では、以下のようにディレクトリーのリストをコロンで区別します。

    例7.5 JBOSS_MODULEPATH 環境変数

    export JBOSS_MODULEPATH=EAP_HOME/modules/:/home/username/external/modules/directory/
    Windows では、以下のようにディレクトリーのリストをセミコロンで区別します。

    例7.6 JBOSS_MODULEPATH 環境変数

    SET JBOSS_MODULEPATH=EAP_HOME\modules\;D:\JBoss-Modules\

手順7.4 起動設定ファイルでの JBOSS_MODULEPATH 変数の設定

  • グローバル環境変数を設定したくない場合は、JBoss EAP 起動設定ファイルで JBOSS_MODULEPATH 変数を設定できます。スタンドアロンサーバーを実行している場合は、EAP_HOME/bin/standalone.conf ファイルになります。サーバーが管理対象ドメインで実行されている場合は、EAP_HOME/bin/domain.conf ファイルになります。
    以下は、standalone.conf ファイルで JBOSS_MODULEPATH 変数を設定するコマンドの例です。

    例7.7 standalone.conf エントリー

    JBOSS_MODULEPATH="EAP_HOME/modules/:/home/username/external/modules/directory/"

7.6. リファレンス

7.6.1. 含まれるモジュール

JBoss EAP 6 に含まれるモジュールや、それらのモジュールがサポートされるかどうかを表すリストについては、カスタマーポータルの https://access.redhat.com/articles/1122333 を参照してください。

7.6.2. 動的モジュールの名前付け

すべてのデプロイメントは JBoss EAP 6 によってモジュールとしてロードされ、以下の慣例に従って名前が付けられます。
  1. WAR および JAR ファイルのデプロイメントは次の形式で名前が付けられます。
     deployment.DEPLOYMENT_NAME 
    たとえば、inventory.war のモジュール名は deployment.inventory.war となり、store.jar のモジュール名は deployment.store.jar となります。
  2. エンタープライズアーカイブ内のサブデプロイメントは次の形式で名前が付けられます。
     deployment.EAR_NAME.SUBDEPLOYMENT_NAME 
    たとえば、エンタープライズアーカイブ accounts.ear 内にある reports.war のサブデプロイメントのモジュール名は deployment.accounts.ear.reports.war になります。

第8章 Jsvc

8.1. はじめに

8.1.1. Jsvc

Jsvc は、Java アプリケーションをバックグラウンドサービスとして UNIX および UNIX 系プラットフォーム上で実行できるようにするライブラリーとアプリケーションのセットです。これにより、アプリケーションは特権ユーザーとして操作を実行でき、実行後に非特権ユーザーに切り替えできます。
Jsvc はランチャープロセス、コントローラープロセス、および制御されたプロセスの 3 つのプロセスを使用します。制御されたプロセスはメインの Java スレッドでもあります。JVM がクラッシュすると、コントローラープロセスが 60 秒以内に JVM を再起動します。Jsvc はデーモンプロセスで、JBoss EAP 6 では特権ユーザーによって起動される必要があります。

注記

Jsvc は Red Hat Enterprise Linux、Solaris および HP-UX のみで使用できます。Microsoft Windows で同様の機能を使用する場合は、Red Hat カスタマーポータルからダウンロード可能な Native Utilities for Windows Server 用ファイルに含まれる prunsrv.exe を参照してください。

8.1.2. Jsvc を使用した JBoss EAP の起動および停止

Jsvc を使用して JBoss EAP を起動および停止する方法は、スタンドアロンとドメインのどちらのモードが実行されているかによって異なります。JBoss EAP がドメインモードで実行されている場合は、Jsvc はドメインコントローラーのプロセスのみを処理することに注意してください。Jsvc を使用して JBoss EAP を起動する場合、使用するコマンドに関係なく、特権ユーザーで実行する必要があります。

前提条件

  • Zip を使用して JBoss EAP がインストールされた場合、以下の条件を満たしている必要があります。
    • Red Hat カスタマーポータルからダウンロードできる、ご使用のオペレーティングシステム用の「Native Utilities」パッケージをインストールします。『インストールガイド』の「ネイティブコンポーネントおよびネイティブユーティリティーのインストール (Zip、インストーラー)」を参照してください。
    • JBoss EAP 6 インスタンスが実行されるユーザーアカウントを作成します。サーバーを起動および停止するために使用されるアカウントには、JBoss EAP がインストールされたディレクトリーの読み書き権限が必要です。
  • RPM を使用して JBoss EAP がインストールされた場合は、「apache-commons-daemon-jsvc-eap6」パッケージをインストールします。『インストールガイド』の「ネイティブコンポーネントおよびネイティブユーティリティーのインストール (RPM インストール)」を参照してください。
以下のコマンドは、スタンドアロンまたはドメインモードのいずれかで JBoss EAP を起動および停止します。ファイルの場所は、JBoss EAP 6 に Jsvc をインストールした方法によって異なることに注意してください。コマンドの変数は、以下の表を参照して使用するファイルを判断してください。
スタンドアロンモード

以下は、スタンドアロンモードで JBoss EAP を起動または停止する手順です。

表8.1 Zip インストールの Jsvc ファイルの場所 - スタンドアロンモード

手順のファイル参照 ファイルの場所
EAP-HOME
${eap-installation-location}/jboss-eap-${version}
JSVC-BIN
EAP_HOME/modules/system/layers/base/native/sbin/jsvc
JSVC-JAR
EAP_HOME/modules/system/layers/base/native/sbin/commons-daemon.jar
CONF-DIR
EAP_HOME/standalone/configuration
LOG-DIR
EAP_HOME/standalone/log

表8.2 RPM インストールの Jsvc ファイルの場所 - スタンドアロンモード

手順のファイル参照 ファイルの場所
EAP-HOME
/usr/share/jbossas
JSVC-BIN
/usr/bin/jsvc-eap6/jsvc
JSVC-JAR
EAP_HOME/modules/system/layers/base/native/sbin/commons-daemon.jar
CONF-DIR
/etc/jbossas/standalone
LOG-DIR
/var/log/jbossas/standalone

スタンドモードでの JBoss EAP の起動

  • JSVC_BIN \
     -outfile LOG_DIR/jsvc.out.log   \
     -errfile LOG_DIR/jsvc.err.log   \
     -pidfile LOG_DIR/jsvc.pid  \
     -user jboss \
     -D[Standalone] -XX:+UseCompressedOops -Xms1303m \
     -Xmx1303m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true 
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true \
     -Dorg.jboss.boot.log.file=LOG_DIR/server.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -cp EAP_HOME/jboss-modules.jar:JSVC_JAR \
     -Djboss.home.dir=EAP_HOME \
     -Djboss.server.base.dir=EAP_HOME/standalone   \
     @org.jboss.modules.Main -start-method main \
     -mp EAP_HOME/modules \
     -jaxpmodule javax.xml.jaxp-provider \
     org.jboss.as.standalone

スタンドアロンモードでの JBoss EAP の停止

  • JSVC_BIN \
     -stop \
     -outfile LOG_DIR/jsvc.out.log   \
     -errfile LOG_DIR/jsvc.err.log   \
     -pidfile LOG_DIR/jsvc.pid  \
     -user jboss \
     -D[Standalone] -XX:+UseCompressedOops -Xms1303m \
     -Xmx1303m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true \
     -Dorg.jboss.boot.log.file=LOG_DIR/server.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -cp EAP_HOME/jboss-modules.jar:JSVC_JAR \
     -Djboss.home.dir=EAP_HOME \
     -Djboss.server.base.dir=EAP_HOME/standalone   \
     @org.jboss.modules.Main -start-method main \
     -mp EAP_HOME/modules \
     -jaxpmodule javax.xml.jaxp-provider \
     org.jboss.as.standalone
ドメインモード

以下は、ドメインモードで JBoss EAP を起動または停止する手順です。ドメインモードでは、JAVA_HOME 変数を Java ホームディレクトリーに置き換える必要があることに注意してください。

表8.3 Zip インストールの Jsvc ファイルの場所 - ドメインモード

手順のファイル参照 ファイルの場所
EAP-HOME
${eap-installation-location}/jboss-eap-${version}
JSVC-BIN
EAP_HOME/modules/system/layers/base/native/sbin/jsvc
JSVC-JAR
EAP_HOME/modules/system/layers/base/native/sbin/commons-daemon.jar
CONF-DIR
EAP_HOME/domain/configuration
LOG-DIR
EAP_HOME/domain/log

表8.4 RPM インストールの Jsvc ファイルの場所 - ドメインモード

手順のファイル参照 ファイルの場所
EAP-HOME
/usr/share/jbossas
JSVC-BIN
/usr/bin/jsvc-eap6/jsvc
JSVC-JAR
EAP_HOME/modules/system/layers/base/native/sbin/commons-daemon.jar
CONF-DIR
/etc/jbossas/domain
LOG-DIR
/var/log/jbossas/domain

ドメインモードでの JBoss EAP の起動

  • JSVC_BIN \
     -outfile LOG_DIR/jsvc.out.log   \
     -errfile LOG_DIR/jsvc.err.log   \
     -pidfile LOG_DIR/jsvc.pid  \
     -user jboss \
     -nodetach -D"[Process Controller]" -server -Xms64m \
     -Xmx512m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true  \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true  \
     -Dorg.jboss.boot.log.file=LOG_DIR/process-controller.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -cp "EAP_HOME/jboss-modules.jar:JSVC_JAR" \
     org.apache.commons.daemon.support.DaemonWrapper \
     -start org.jboss.modules.Main -start-method main \
     -mp EAP_HOME/modules org.jboss.as.process-controller \
     -jboss-home EAP_HOME -jvm $JAVA_HOME/bin/java \
     -mp EAP_HOME/modules -- \
     -Dorg.jboss.boot.log.file=LOG_DIR/host-controller.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -server -Xms64m -Xmx512m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true -- -default-jvm $JAVA_HOME/bin/java

ドメインモードでの JBoss EAP の停止

  • JSVC_BIN \
     -stop \
     -outfile LOG_DIR/jsvc.out.log   \
     -errfile LOG_DIR/jsvc.err.log   \
     -pidfile LOG_DIR/jsvc.pid  \
     -user jboss \
     -nodetach -D"[Process Controller]" -server -Xms64m \
     -Xmx512m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true  \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true  \
     -Dorg.jboss.boot.log.file=LOG_DIR/process-controller.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -cp "EAP_HOME/jboss-modules.jar:JSVC_JAR" \
     org.apache.commons.daemon.support.DaemonWrapper \
     -start org.jboss.modules.Main -start-method main \
     -mp EAP_HOME/modules org.jboss.as.process-controller \
     -jboss-home EAP_HOME -jvm $JAVA_HOME/bin/java \
     -mp EAP_HOME/modules -- \
     -Dorg.jboss.boot.log.file=LOG_DIR/host-controller.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -server -Xms64m -Xmx512m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true -- -default-jvm $JAVA_HOME/bin/java

注記

JVM のクラッシュなど、JBoss EAP が正常に終了されなかった場合、Jsvc は JBoss EAP 6 を自動的に再起動します。JBoss EAP 6 が正常に終了されると、Jsvc も停止します。

第9章 グローバル値

9.1. バルブ

バルブは、アプリケーションのパイプラインを処理する要求に挿入される Java クラスです。バルブはサーブレットフィルターの前にパイプラインへ挿入されます。バルブは要求を渡す前に変更を加えたり、認証や要求のキャンセルなどの他の処理を実行したりできます。
バルブは、サーバーレベルまたはアプリケーションレベルで設定でき、設定とパッケージ化の方法のみが異なります。
  • グローバルバルブはサーバーレベルで設定され、サーバーにデプロイされたすべてのアプリケーションに適用されます。グローバルバルブの設定手順については、JBoss EAP の『管理および設定ガイド』を参照してください。
  • アプリケーションレベルで設定されたバルブはアプリケーションデプロイメントとパッケージ化され、特定のアプリケーションのみが影響します。アプリケーションレベルでバルブを設定する方法の手順については、JBoss EAP の『開発ガイド』を参照してください。
6.1.0 およびそれ以降のバージョンはグローバルバルブをサポートします。

9.2. グローバルバルブ

グローバルバルブは、デプロイされたすべてのアプリケーションのパイプラインを処理する要求へ挿入されるバルブです。バルブは、JBoss EAP 6 で静的モジュールとしてパッケージ化およびインストールされ、グローバルバルブとなります。グローバルバルブは Web サブシステムで設定されます。
6.1.0 およびそれ以降のバージョンのみがグローバルバルブをサポートします。
グローバルバルブの設定方法については、 「グローバルバルブの設定」を参照してください。

9.3. オーセンティケーターバルブ

オーセンティケーターバルブは、要求の証明情報を認証するバルブです。オーセンティケーターバルブは org.apache.catalina.authenticator.AuthenticatorBase のサブクラスで、authenticate(Request request, Response response, LoginConfig config) メソッドを上書きします。
このバルブを使用して追加の認証スキームを実装できます。

9.4. グローバルバルブのインストール

グローバルバルブは、JBoss EAP 6 で静的モジュールとしてパッケージ化およびインストールされる必要があります。このタスクでは、モジュールのインストール方法について説明します。

前提条件:

  • バルブを作成し、JAR ファイルにパッケージ化する必要があります。
  • モジュールに対して module.xml ファイルを作成する必要があります。
    module.xml ファイルの例は、「モジュール」を参照してください。

手順9.1 グローバルモジュールのインストール

  1. モジュールインストールディレクトリーの作成

    インストールするモジュールのディレクトリーはアプリケーションサーバーの modules ディレクトリーに作成する必要があります。
    EAP_HOME/modules/system/layers/base/MODULENAME/main
    $ mkdir -P EAP_HOME/modules/system/layers/base/MODULENAME/main
  2. ファイルのコピー

    JAR および module.xml ファイルを 1. で作成したディレクトリーにコピーします。
    $ cp MyValves.jar module.xml EAP_HOME/modules/system/layers/base/MODULENAME/main
モジュールで宣言したバルブクラスを Web サブシステムで設定できるようになります。

9.5. グローバルバルブの設定

グローバルバルブは Web サブシステムで有効化および設定されます。これには JBoss CLI ツールを使用します。

手順9.2 グローバルバルブの設定

  1. バルブの有効化

    add 操作を使用して新しいバルブエントリーを追加します。
    /subsystem=web/valve=VALVENAME:add(module="MODULENAME",class-name="CLASSNAME")
    次の値を指定する必要があります。
    • VALVENAME (アプリケーション設定でこのバルブの参照に使用される名前)
    • MODULENAME (設定される値が含まれるモジュール)
    • CLASSNAME (モジュールの特定バルブのクラス名)
    例:
    /subsystem=web/valve=clientlimiter:add(module="clientlimitermodule",class-name="org.jboss.samplevalves.RestrictedUserAgentsValve")
  2. オプション: パラメーターの指定

    バルブに設定パラメーターがある場合は、add-param 操作で指定します。
    /subsystem=web/valve=VALVENAME:add-param(param-name="PARAMNAME", param-value="PARAMVALUE")
    次の値を指定する必要があります。
    • VALVENAME (アプリケーション設定でこのバルブの参照に使用される名前)
    • PARAMNAME (特定の値に設定されるパラメーターの名前)
    • PARAMVALUE (指定されたパラメーターの値)
    例:

    例9.1 バルブ設定

    /subsystem=web/valve=clientlimiter:add-param(
       param-name="restrictedUserAgents", 
       param-value="^.*MS Web Services Client Protocol.*$"
    )
バルブがデプロイされたすべてのアプリケーションに対して有効になり、設定されます。
カスタム値の作成方法については、『開発ガイド』の項「カスタムバルブの作成」を参照してください。

第10章 アプリケーションデプロイメント

10.1. アプリケーションデプロイメント

JBoss EAP 6 は、管理環境と開発環境の両方に対応するよう、さまざまなアプリケーションデプロイメントおよび設定オプションを提供します。管理者向けには、管理コンソールと管理 CLI によって、本番環境でアプリケーションデプロイメントを管理できる理想的なグラフィカルおよびコマンドラインインターフェースが提供されます。開発者用には、アプリケーションデプロイメントのテストオプションとして、設定可能なファイルシステムデプロイメントスキャナー、JBoss Developer Studio などの IDE の使用、Maven を介したデプロイメントおよびアンデプロイメントなどが提供されます。

10.2. 管理コンソールでのデプロイ

10.2.1. 管理コンソースでのアプリケーションデプロイメント管理

管理コンソールよりアプリケーションをデプロイすると、使いやすさが利点のグラフィカルインターフェースを使用できます。ご使用のサーバーもしくはサーバーグループにデプロイされているアプリケーションを一目で確認できるほか、必要に応じてアプリケーションを無効にしたり、コンテンツリポジトリーから削除したりできます。

10.2.2. 管理コンソールを使用してデプロイされたアプリケーションを有効化

手順10.1 管理コンソールを使用してデプロイされたアプリケーションを有効化

  1. コンソールの上部より Runtime タブを選択します。
    • 管理対象ドメインの場合は、Domain メニューを展開します。
    • スタンドアロンサーバーの場合は、Server メニューを展開します。
  2. Manage Deployments を選択します。
  3. アプリケーションのデプロイメントの方法は、スタンドアロンサーバーインスタンスと管理対象ドメインのどちらにデプロイするかによって異なります。
    • スタンドアロンサーバーインスタンスでのアプリケーションの有効化

      Available Deployments の表には、利用可能なすべてのアプリケーションデプロイメントとそれらの状態が表示されます。
      1. スタンドアロンサーバーインスタンスでアプリケーションを有効にするには、アプリケーションを選択した後に En/Disable をクリックします。
      2. confirm をクリックし、サーバーインスタンスでアプリケーションを有効にすることを確定します。
    • 管理対象ドメインでのアプリケーションの有効化

      Content Repository タブには、利用可能なすべてのアプリケーションデプロイメントと、それらの状態を表す Available Deployment Content の表が含まれます。
      1. 管理対象ドメインでアプリケーションを有効にするには、デプロイするアプリケーションを選択します。Available Deployment Content の表の上にある Assign をクリックします。
      2. アプリケーションを追加したい各サーバーグループのボックスにチェックマークを付け、Save をクリックして終了します。
      3. Server Groups タブをクリックし Server Groups の表を表示します。アプリケーションが選択したサーバーグループにデプロイされます。
結果

該当のサーバーあるいはサーバーグループにアプリケーションがデプロイされます。

10.2.3. 管理コンソールを使用してデプロイされたアプリケーションを無効化

手順10.2 管理コンソールを使用してデプロイされたアプリケーションを無効化

    1. コンソールの上部より Runtime タブを選択します。
      • 管理対象ドメインの場合は、Domain メニューを展開します。
      • スタンドアロンサーバーの場合は、Server メニューを展開します。
    2. Manage Deployments を選択します。
  1. アプリケーションを無効化する方法は、スタンドアロンサーバーインスタンスと管理対象ドメインのどちらにデプロイするかどうかによって異なります。
    • スタンドアロンサーバーインスタンスにデプロイされたアプリケーションを無効化

      Available Deployments の表には、利用可能なすべてのアプリケーションデプロイメントとそれらの状態が表示されます。
      1. 無効にするアプリケーションを選択します。En/Disable をクリックし、選択したアプリケーションを無効にします。
      2. Confirm をクリックし、サーバーインスタンスでアプリケーションを無効にすることを確定します。
    • 管理対象ドメインでのデプロイされたアプリケーションの無効化

      Manage Deployments Content 画面には Content Repository タブが含まれます。Available Deployment Content の表には、利用可能なすべてのアプリケーションデプロイメントとそれらの状態が表示されます。
      1. Server Groups タブを選択して、サーバーグループとデプロイされたアプリケーションの状態を表示します。
      2. アプリケーションをアンデプロイするサーバーの名前を Server Group の表から選択します。View をクリックしてアプリケーションを確認します。
      3. アプリケーションを選択し、En/Disable をクリックして選択したサーバーのアプリケーションを無効にします。
      4. Confirm をクリックし、サーバーインスタンスでアプリケーションを無効にすることを確定します。
      5. 必要に応じて、他のサーバーグループにも同じ手順を繰り返します。Group Deployments の表の各サーバーグループに対してアプリケーションの状態が確定されます。
結果

該当のサーバーあるいはサーバーグループからアプリケーションがアンデプロイされます。

10.2.4. 管理コンソールを使用したアプリケーションのアンデプロイ

手順10.3 管理コンソールを使用したアプリケーションのアンデプロイ

    1. コンソールの上部より Runtime タブを選択します。
      • 管理対象ドメインの場合は、Domain メニューを展開します。
      • スタンドアロンサーバーの場合は、Server メニューを展開します。
    2. Manage Deployments を選択します。
  1. アプリケーションをアンデプロイする方法は、スタンドアロンサーバーインスタンスと管理対象ドメインのどちらからアンデプロイするかどうかによって異なります。
    • デプロイされたアプリケーションをスタンドアロンサーバーインスタンスからアンデプロイ

      Available Deployments の表には、利用可能なすべてのアプリケーションデプロイメントとそれらの状態が表示されます。
      1. アンデプロイするアプリケーションを選択します。Remove をクリックして、選択されたアプリケーションをアンデプロイします。
      2. Confirm をクリックし、サーバーインスタンスでアプリケーションをアンデプロイすることを確定します。
    • デプロイされたアプリケーションを管理対象ドメインからアンデプロイ

      Manage Deployments Content 画面には Content Repository タブが含まれます。Available Deployment Content の表には、利用可能なすべてのアプリケーションデプロイメントとそれらの状態が表示されます。
      1. Server Groups タブを選択して、サーバーグループとデプロイされたアプリケーションの状態を表示します。
      2. アプリケーションをアンデプロイするサーバーの名前を Server Group の表から選択します。View をクリックしてアプリケーションを確認します。
      3. アプリケーションを選択し、Remove をクリックして、選択されたサーバーのアプリケーションをアンデプロイします。
      4. Confirm をクリックし、サーバーインスタンスでアプリケーションをアンデプロイすることを確定します。
      5. 必要に応じて、他のサーバーグループにも同じ手順を繰り返します。Group Deployments の表の各サーバーグループに対してアプリケーションの状態が確定されます。
結果

該当のサーバーあるいはサーバーグループからアプリケーションがアンデプロイされます。スタンドアロンインスタンスでは、デプロイメントコンテンツも削除されます。管理対象ドメインでは、デプロイメントコンテンツはコンテンツリポジトリーに残り、サーバーグループからのみアンデプロイされます。

10.3. 管理 CLI でのデプロイ

10.3.1. 管理 CLI でのアプリケーションデプロイメントの管理

管理 CLI を使用してアプリケーションをデプロイすると、単一のコマンドラインインターフェースでデプロイメントスクリプトを作成および実行できます。このスクリプト機能を使用して、特定のアプリケーションデプロイメントおよび管理シナリオを設定できます。スタンドアロンインスタンスの場合は単一サーバーのデプロイメント状態を管理でき、管理対象ドメインの場合はサーバーのネットワーク全体を管理できます。

10.3.2. 管理 CLI を使用したスタンドアロンサーバーでのアプリケーションのデプロイ

手順10.4 スタンドアロンサーバーでのアプリケーションのデプロイ

  • deploy コマンドの実行

    管理 CLI で、アプリケーションデプロイメントへのパスを指定して deploy コマンドを入力します。

    例10.1 deploy コマンド

    [standalone@localhost:9999 /] deploy /path/to/test-application.war
    デプロイメントに成功しても CLI には何も出力されないことに注意してください。
結果

指定のアプリケーションが、スタンドアロンサーバーにデプロイされます。

10.3.3. 管理 CLI を使用したスタンドアロンサーバーでのアプリケーションのアンデプロイ

手順10.5 スタンドアロンサーバーでのアプリケーションのアンデプロイ

デフォルトでは、undeploy コマンドはアンデプロイし、 JBoss EAP のスタンドアロンインスタンスからデプロイメントコンテンツを削除します。デプロイメントコンテンツを保持するには、パラメーター --keep-content を追加します。
  • undeploy コマンドの実行

    アプリケーションをアンデプロイし、デプロイメントコンテンツを削除するには、アプリケーションデプロイメントのファイル名とともに、管理 CLI undeploy コマンドを入力します。
    [standalone@localhost:9999 /] undeploy test-application.war
    アプリケーションをアンデプロイし、デプロイメントコンテンツを保持するには、アプリケーションデプロイメントのファイル名とパラメーター --keep-content ともに、管理 CLI undeploy コマンドを入力します。
    [standalone@localhost:9999 /] undeploy test-application.war --keep-content
結果

指定されたアプリケーションはアンデプロイされます。undeploy コマンドは、成功した場合に管理 CLI に出力を表示しません。

10.3.4. 管理 CLI を使用した管理対象ドメインでのアプリケーションのデプロイ

手順10.6 管理対象ドメインでのアプリケーションのデプロイ

  • deploy コマンドの実行

    管理 CLI で、アプリケーションデプロイメントへのパスを指定して deploy コマンドを入力します。すべてのサーバーグループをデプロイするために --all-server-groups パラメーターを追加します。
    [domain@localhost:9999 /] deploy /path/to/test-application.war --all-server-groups
    • または、--server-groups パラメーターを追加して、デプロイメントに固有なサーバーグループを定義します。
      [domain@localhost:9999 /] deploy /path/to/test-application.war --server-groups=server_group_1,server_group_2
    デプロイメントに成功しても CLI には何も出力されないことに注意してください。
結果

指定のアプリケーションが、管理対象ドメインのサーバーグループにデプロイされます。

10.3.5. 管理 CLI を使用した管理対象ドメインでのアプリケーションのアンデプロイ

手順10.7 管理対象ドメインでのアプリケーションのアンデプロイ

  • undeploy コマンドの実行

    管理 CLI で、アプリケーションデプロイメントのファイル名を指定して undeploy コマンドを入力します。--all-relevant-server-groups パラメーターを追加すると、アプリケーションがデプロイされたすべてのサーバーグループからアプリケーションをアンデプロイできます。
    [domain@localhost:9999 /] undeploy test-application.war --all-relevant-server-groups
    アンデプロイに成功しても CLI には何も出力されないことに注意してください。
結果

指定のアプリケーションがアンデプロイされます。

10.4. HTTP API を用いたデプロイ

10.4.1. HTTP API を使用したアプリケーションのデプロイ

概要

以下の手順に従って、HTTP API よりアプリケーションをデプロイできます。

手順10.8 DeployDmrToJson.java を使用したアプリケーションのデプロイ

  1. DeployDmrToJson.java を使用して JSON への要求を生成し、アプリケーションをデプロイします。

    例10.2 DeployDmrToJson.java クラス

    import org.jboss.dmr.ModelNode;
    import java.net.URL;
    
    public class DeployDmrToJson
    {
      public static void main(String[] args) throws Exception
      {
        if(args.length < 1)
          throw new IllegalArgumentException("The first argument must be a URL");
    
        URL url = new URL(args[0]);
        String[] pathElements = url.getFile().split("/");
        String name = pathElements[pathElements.length-1];
    
        ModelNode deploy = getDeploy(url.toExternalForm(), name);
        ModelNode undeploy = getUndeploy(name);
    
        System.out.println("Deploy\n------------------------------\n");
        System.out.println("Formatted:\n" + deploy.toJSONString(false));
        System.out.println("Unformatted:\n" + deploy.toJSONString(true));
        System.out.println("\nUndeploy\n------------------------------\n");
        System.out.println("Formatted:\n" + undeploy.toJSONString(false));
        System.out.println("Unformatted:\n" + undeploy.toJSONString(true));
      }
    
      public static ModelNode getUndeploy(String name)
      {
        ModelNode undeployRequest = new ModelNode();
        undeployRequest.get("operation").set("undeploy");
        undeployRequest.get("address", "deployment").set(name);
    
        ModelNode removeRequest = new ModelNode();
        removeRequest.get("operation").set("remove");
        removeRequest.get("address", "deployment").set(name);
    
        ModelNode composite = new ModelNode();
        composite.get("operation").set("composite");
        composite.get("address").setEmptyList();
        final ModelNode steps = composite.get("steps");
        steps.add(undeployRequest);
        steps.add(removeRequest);
        return composite;
      }
    
      public static ModelNode getDeploy(String url, String name)
      {
        ModelNode deployRequest = new ModelNode();
        deployRequest.get("operation").set("deploy");
        deployRequest.get("address", "deployment").set(name);
    
        ModelNode addRequest = new ModelNode();
        addRequest.get("operation").set("add");
        addRequest.get("address", "deployment").set(name);
        addRequest.get("content").get(0).get("url").set(url);
    
        ModelNode composite = new ModelNode();
        composite.get("operation").set("composite");
        composite.get("address").setEmptyList();
        final ModelNode steps = composite.get("steps");
        steps.add(addRequest);
        steps.add(deployRequest);
        return composite;
      }
    }
  2. 以下のように、コマンドを使用してクラスを実行します。

    例10.3 コマンドの実行

    java -cp .:$JBOSS_HOME/modules/org/jboss/dmr/main/jboss-dmr-1.1.1.Final-redhat-1.jar DeployDmrToJson \
    file:///Users/username/support/helloWorld.war/dist/helloWorld.war
  3. クラスが実行されると、以下のコマンド形式が表示されます。必要に応じて、deploy または undeploy コマンドを使用します。

    例10.4 デプロイおよびアンデプロイコマンド

    Deploy
    ------------------------------
    
    Formatted:
    {
        "operation" : "composite",
        "address" : [],
        "steps" : [
            {
                "operation" : "add",
                "address" : {"deployment" : "helloWorld.war"},
                "content" : [{"url" : "file:/Users/username/support/helloWorld.war/dist/helloWorld.war"}]
            },
            {
                "operation" : "deploy",
                "address" : {"deployment" : "helloWorld.war"}
            }
        ]
    }
    Unformatted:
    {"operation" : "composite", "address" : [], "steps" : [{"operation" : "add", "address" : {"deployment" : "helloWorld.war"}, "content" : [{"url" : "file:/Users/username/support/helloWorld.war/dist/helloWorld.war"}]},{"operation" : "deploy", "address" : {"deployment" : "helloWorld.war"}}]}
    
    Undeploy
    ------------------------------
    
    Formatted:
    {
        "operation" : "composite",
        "address" : [],
        "steps" : [
            {
                "operation" : "undeploy",
                "address" : {"deployment" : "helloWorld.war"}
            },
            {
                "operation" : "remove",
                "address" : {"deployment" : "helloWorld.war"}
            }
        ]
    }
    Unformatted:
    {"operation" : "composite", "address" : [], "steps" : [{"operation" : "undeploy", "address" : {"deployment" : "helloWorld.war"}},{"operation" : "remove", "address" : {"deployment" : "helloWorld.war"}}]}
    
  4. 以下のコマンドを使用して、アプリケーションをデプロイまたはアンデプロイします。json request を上記の要求に置き換えます。

    例10.5 コマンドの実行

    curl -f --digest -u "<user>:<pass>" -H Content-Type:\ application/json -d '<json request>' "http://localhost:9990/management"

10.5. デプロイメントスキャナーでのデプロイ

10.5.1. デプロイメントスキャナーでのアプリケーションデプロイメント管理

デプロイメントスキャナーを介してスタンドアロンサーバーインスタンスにアプリケーションをデプロイすることにより、迅速な開発サイクルに適した方法でアプリケーションのテストと構築を行うことができます。デプロイメントスキャナーは、デプロイメントの頻度やさまざまなアプリケーションタイプの動作などのニーズに合わせて設定することができます。

10.5.2. デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスにアプリケーションをデプロイ

概要

このタスクでは、デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスにアプリケーションをデプロイする方法を説明します。「アプリケーションデプロイメント 」で説明されたように、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には、管理コンソールと管理 CLI の方法が推奨されます。

手順10.9 デプロイメントスキャナーを使用したアプリケーションのデプロイ

  1. デプロイメントフォルダーへのコンテンツのコピー

    アプリケーションファイルを、EAP_HOME/standalone/deployments/ にあるデプロイメントフォルダーにコピーします。
  2. デプロイメントスキャンモード

    アプリケーションのデプロイ方法は 2 つあります。自動または手動のデプロイメントスキャナーモードを選択できます。「管理 CLI でのデプロイメントスキャナーの設定」を読んでからいずれかのデプロイ方法を使用してください。
    • 自動デプロイメント

      デプロイメントスキャナーは、フォルダー状態の変更を検出し、「管理 CLI でのデプロイメントスキャナーの設定」で定義されたようにマーカーファイルを作成します。
    • 手動デプロイメント

      デプロイメントスキャナーでは、デプロイメントプロセスをトリガーするマーカーファイルが必要です。以下の例では、Unix の touch コマンドを使用して新しい .dodeploy ファイルを作成します。

      例10.6 touch コマンドを使用したデプロイ

      [user@host bin]$ touch $EAP_HOME/standalone/deployments/example.war.dodeploy
結果

アプリケーションファイルがアプリケーションサーバーにデプロイされます。マーカーファイルがデプロイメントフォルダーで作成され、デプロイメントが正常に終了したことを示します。アプリケーションは、管理コンソールで、Enabled と示されます。

例10.7 デプロイメント後のデプロイメントフォルダーコンテンツ

example.war
example.war.deployed

10.5.3. デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスからアプリケーションをアンデプロイ

概要

このタスクでは、デプロイメントスキャナーを使用してデプロイされたスタンドアロンサーバーインスタンスからアプリケーションをアンデプロイする方法を説明します。「アプリケーションデプロイメント 」で説明されたように、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には管理コンソールと管理 CLI の方法が推奨されます。

注記

デプロイメントスキャナーは、アプリケーション管理の他のデプロイメント方法とともに使用しないでください。管理コンソールによってアプリケーションサーバーから削除されたアプリケーションは、デプロイメントディレクトリーに含まれるマーカーファイルまたはアプリケーションに影響を与えずにランタイムから削除されます。意図しない再デプロイメントや、他のエラーの可能性を最低限にするには、本番稼働環境での管理に管理 CLI および管理コンソールを使用します。

手順10.10 以下の方法の 1 つを用いたアプリケーションのアンデプロイ

  • アプリケーションのアンデプロイ

    アプリケーションをデプロイする方法は 2 つありますが、アプリケーションをデプロイメントフォルダーから削除する場合と、デプロイメントの状態のみを変更する場合によって、使用する方法が異なります。
    • マーカーファイルの削除によるアンデプロイ

      デプロイされたアプリケーションの example.war.deployed マーカーファイルを削除して、ランタイムからアプリケーションのアンデプロイを開始するためにデプロイメントスキャナーをトリガーします。
      結果
      デプロイメントスキャナーは、アプリケーションをアンデプロイし、example.war.undeployed マーカーファイルを作成します。アプリケーションは、デプロイメントフォルダーに維持されます。
    • アプリケーションの削除によるアンデプロイ

      注記

      展開された WAR ファイルをこの方法でアンデプロイすることはできません。アンデプロイは、マーカーファイルを削除することによってのみ可能です。展開された WAR ファイルをアンデプロイしようとすると、以下のようなメッセージがログに記録されます。
      WARN  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) JBAS015006: The deployment scanner found that the content for exploded deployment EXAMPLE.war has been deleted, but auto-deploy/undeploy for exploded deployments is not enabled and the EXAMPLE.war.deployed marker file for this deployment has not been removed. As a result, the deployment is not being undeployed, but resources needed by the deployment may have been deleted and application errors may occur. Deleting the EXAMPLE.war.deployed marker file to trigger undeploy is recommended.
      デプロイメントディレクトリーからアプリケーションを削除して、ランタイムからアプリケーションのアンデプロイを開始するためにデプロイメントスキャナーをトリガーします。
      結果
      デプロイメントスキャナーは、アプリケーションをアンデプロイし、filename.filetype.undeployed マーカーファイルを作成します。アプリケーションはデプロイメントフォルダーに存在しません。
結果

アプリケーションファイルは、アプリケーションサーバーからアンデプロイされ、管理コンソールの Deployments 画面に表示されません。

10.5.4. デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスにアプリケーションを再デプロイ

概要

このタスクでは、デプロイメントスキャナーを使用してデプロイされたスタンドアロンサーバーインスタンスへアプリケーションを再デプロイする方法を説明します。「アプリケーションデプロイメント 」で説明されたように、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には管理コンソールと管理 CLI の方法が推奨されます。

手順10.11 アプリケーションをスタンドアロンサーバーへ再デプロイ

  • アプリケーションの再デプロイ

    デプロイメントスキャナーでデプロイされたアプリケーションを再デプロイするには、3 つの方法があります。これらの方法はデプロイメントサイクルを開始するためにデプロイメントスキャナーをトリガーし、個々の設定に応じて選択できます。
結果

アプリケーションファイルが再デプロイされます。

10.5.5. デプロイメントスキャナーマーカーファイルのリファレンス

マーカーファイル

マーカーファイルは、デプロイメントスキャナーサブシステムの一部です。これらのファイルは、スタンドアロンサーバーインスタンスのデプロイメントディレクトリー内にあるアプリケーションの状態をマークします。マーカーファイルは、アプリケーションと同じ名前を持ち、ファイル接尾辞はアプリケーションのデプロイメントの状態を示します。以下の表に、各マーカーファイルのタイプおよび応答の定義を示します。

例10.9 マーカーファイル例

以下の例は、testapplication.war という名前のアプリケーションの正常にデプロイされたインスタンスのマーカーファイルを示します。
testapplication.war.deployed

表10.1 マーカーファイルタイプ定義

ファイル名接尾辞 生成元 説明
.dodeploy ユーザー生成 コンテンツをランタイムにデプロイまたは再デプロイする必要があることを示します。
.skipdeploy ユーザー生成 アプリケーションの自動デプロイを無効にします。展開されたコンテンツの自動デプロイメントを一時的にブロックする方法として役に立ち、不完全なコンテンツ編集がライブでプッシュされることを防ぎます。スキャナーは zip 形式のコンテンツに対する処理中の変更を検出し、完了するまで待機しますが、zip 形式のコンテンツとともに使用できます。
.isdeploying システム生成 デプロイメントの開始を示します。デプロイメントプロセスが完了すると、マーカーファイルが削除されます。
.deployed システム生成 コンテンツがデプロイされたことを示します。このファイルが削除された場合、コンテンツはアンデプロイされます。
.failed システム生成 デプロイメントの失敗を示します。マーカーファイルには、失敗の原因に関する情報が含まれます。マーカーファイルが削除された場合、コンテンツは自動デプロイメントで再び可視状態になります。
.isundeploying システム生成 .deployed ファイルの削除に対する応答を示します。コンテンツはアンデプロイされ、完了時にマーカーは自動的に削除されます。
.undeployed システム生成 コンテンツがアンデプロイされたことを示します。マーカーファイルを削除しても、コンテンツの再デプロイメントには影響ありません。
.pending システム生成 デプロイメントの指示が、検出された問題の解決を待っているサーバーに送信されます。このマーカーは、グローバルデプロイメントロードブロックとして機能します。この状態が存在する場合、スキャナーは他のコンテンツをデプロイまたはアンデプロイするようサーバーに指示しません。

10.5.6. デプロイメントスキャナー属性のリファレンス

デプロイメントスキャナーには、管理 CLI に公開された以下の属性が含まれ、これらの属性は write-attribute 操作を使用して設定できます。設定オプションの詳細については、トピック「管理 CLI でのデプロイメントスキャナーの設定」を参照してください。

表10.2 デプロイメントスキャナー属性

名前 説明 タイプ デフォルト値
auto-deploy-exploded .dodeploy マーカーファイルなしで、展開されたコンテンツの自動デプロイメントを許可します。基本的な開発シナリオに対してのみ推奨され、開発者またはオペレーティングシステムによる変更中に、展開されたアプリケーションデプロイメントが行われないようにします。 ブール値 False
auto-deploy-xml .dodeploy マーカーファイルなしでの XML コンテンツの自動デプロイメントを許可します。 ブール値 True
auto-deploy-zipped .dodeploy マーカーファイルなしでの zip 形式のコンテンツの自動デプロイメントを許可します。 ブール値 True
deployment-timeout デプロイメントスキャナーでデプロイメントをキャンセルするまでのデプロイメント試行許可時間 (秒単位)。 Long 600
path スキャンする実際のファイルシステムパスを定義します。relative-to 属性が指定された場合は、path 値が、そのディレクトリーまたはパスに対する相対追加分として機能します。 文字列 deployments
relative-to サーバー設定 XML ファイルの paths セクションで定義されたファイルシステムパスの参照。 文字列 jboss.server.base.dir
scan-enabled scan-interval により起動時にアプリケーションの自動スキャンを許可します。 ブール値 True
scan-interval リポジトリーのスキャン間の時間 (ミリ秒単位)。値が 1 未満の場合は、スキャナーが起動時にのみ動作します。 Int 5000

10.5.7. デプロイメントスキャナーの設定

デプロイメントスキャナーは、管理コンソールまたは管理 CLI を使用して設定できます。新しいデプロイメントスキャナーを作成したり、既存のスキャナー属性を管理したりできます。これらには、スキャン間隔、デプロイメントフォルダーの場所、およびデプロイメントをトリガーするアプリケーションファイルタイプが含まれます。

10.5.8. 管理 CLI でのデプロイメントスキャナーの設定

概要

デプロイメントスキャナーを設定する方法は複数ありますが、バッチスクリプトの使用やリアルタイムによる属性の公開および変更には、管理 CLI を使用できます。read-attribute および write-attribute グローバルコマンドライン操作を使用すると、デプロイメントスキャナーの挙動を変更できます。デプロイメントスキャナー属性の詳細については、「デプロイメントスキャナー属性のリファレンス」の説明を参照してください。

デプロイメントスキャナーは JBoss EAP 6 のサブシステムで、standalone.xml で確認できます。

例10.10 standalone.xml の一部

<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">
    <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000"/>
</subsystem>

手順10.12 デプロイメントスキャナーの設定

  1. 設定するデプロイメントスキャナー属性の決定

    管理 CLI を使用してデプロイメントスキャナーを設定するには、最初に正しい属性名を公開する必要があります。これには、ルートノードで read-resources 操作を使用するか、cd コマンドを使用してサブシステムの子ノードに移動して行います。また、このレベルで ls コマンドを使用して属性を表示することもできます。
    • read-resource 操作を使用したデプロイメントスキャナー属性の表示

      read-resource 操作を使用して、デフォルトのデプロイメントスキャナーリソースで定義された属性を公開します。

      例10.11 read-resource の出力例

      [standalone@localhost:9999 /]/subsystem=deployment-scanner/scanner=default:read-resource
      {
          "outcome" => "success",
          "result" => {
              "auto-deploy-exploded" => false,
              "auto-deploy-xml" => true,
              "auto-deploy-zipped" => true,
              "deployment-timeout" => 600,
              "path" => "deployments",
              "relative-to" => "jboss.server.base.dir",
              "scan-enabled" => true,
              "scan-interval" => 5000
          }
      }
    • ls コマンドを使用したデプロイメントスキャナー属性の表示

      ls コマンドにオプションの -l 引数を指定して、サブシステムノード属性、値、およびタイプを含む結果の表を表示します。ls コマンドとその引数の詳細を確認するには、ls --help と入力して CLI ヘルプエントリーを表示します。管理 CLI のヘルプメニューの詳細については、トピック「管理 CLI でのヘルプの取得」を参照してください。

      例10.12 ls -l の出力例

      [standalone@localhost:9999 /] ls -l /subsystem=deployment-scanner/scanner=default
      ATTRIBUTE            VALUE                 TYPE    
      auto-deploy-exploded false                 BOOLEAN 
      auto-deploy-xml      true                  BOOLEAN 
      auto-deploy-zipped   true                  BOOLEAN 
      deployment-timeout   600                   LONG    
      path                 deployments           STRING  
      relative-to          jboss.server.base.dir STRING  
      scan-enabled         true                  BOOLEAN 
      scan-interval        5000                  INT
  2. write-attribute 操作を使用したデプロイメントスキャナーの設定

    変更する属性の名前を決定したら、write-attribute を使用して、書き込む属性名と新しい値を指定します。以下の例は、すべて子ノードレベルで実行されます。この例を使用するには、cd コマンドとタブ補完を使用してデフォルトスキャナーノードを表示し、移動します。
    [standalone@localhost:9999 /] cd subsystem=deployment-scanner/scanner=default
    1. 展開されたコンテンツの自動デプロイメントの有効化

      write-attribute 操作を使用して、展開されたアプリケーションコンテンツの自動デプロイメントを有効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-exploded,value=true)
      {"outcome" => "success"}
    2. XML コンテンツの自動デプロイメントの無効化

      write-attribute 操作を使用して XML アプリケーションコンテンツの自動デプロイメントを無効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-xml,value=false)     
      {"outcome" => "success"}
    3. zip 形式のコンテンツの自動デプロイメントの無効化

      write-attribute コマンドを使用して zip 形式のアプリケーションコンテンツの自動デプロイメントを無効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-zipped,value=false)
      {"outcome" => "success"}
    4. パス属性の設定

      write-attribute 操作を使用して、パス属性を変更し、例の newpathname 値を監視するデプロイメントスキャナーの新しいパス名に置き換えます。変更を反映するにはサーバーでリロードする必要があります。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=path,value=newpathname)            
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }
    5. 相対パス属性の設定

      write-attribute 操作を使用して、設定 XML ファイルのパスセクションで定義されたファイルシステムパスに対する相対参照を変更します。変更を反映するには、サーバーでリロードする必要があります。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=relative-to,value=new.relative.dir)
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }
    6. デプロイメントスキャナーの無効化

      write-attribute 操作を使用して、scan-enabled 値を false に設定することにより、デプロイメントスキャナーを無効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=scan-enabled,value=false)        
      {"outcome" => "success"}
    7. スキャン間隔の変更

      write-attribute 操作を使用してスキャン間隔を 5000 ミリ秒から 10000 ミリ秒に変更します。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=scan-interval,value=10000)
      {"outcome" => "success"}
結果

設定の変更が、デプロイメントスキャナーに保存されます。

10.6. Maven でのデプロイ

10.6.1. Maven によるアプリケーションデプロイメントの管理

Maven を使用してアプリケーションをデプロイすると、デプロイメントのサイクルを既存の開発ワークフローの一部として取り入れることができます。

10.6.2. Maven によるアプリケーションのデプロイ

概要

このタスクでは、Maven を用いてアプリケーションをデプロイする方法について説明します。ここで使用される例は、JBoss EAP 6 のクイックスタートにある jboss-helloworld.war アプリケーションを使用します。helloworld プロジェクトには、jboss-as-maven-plugin を初期化する POM ファイルが含まれています。このプラグインを使用すると、アプリケーションサーバーでアプリケーションを簡単にデプロイおよびアンデプロイできます。

手順10.13 Maven によるアプリケーションのデプロイ

  1. ターミナルセッションを開き、quickstart サンプルが含まれるディレクトリーに移動します。

    例10.13 helloworld アプリケーションディレクトリーへの移動

    [localhost]$ cd /QUICKSTART_HOME/helloworld
    
  2. Maven デプロイコマンドを実行してアプリケーションをデプロイします。アプリケーションがすでに実行されている場合、アプリケーションは再デプロイされます。
    [localhost]$ mvn package jboss-as:deploy
  3. 結果を確認します。
    • デプロイメントは、ターミナルウィンドウで操作ログを参照して確認できます。

      例10.14 Maven での helloworld アプリケーションの確認

                              
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESS
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 32.629s
      [INFO] Finished at: Fri Mar 14 09:09:50 EDT 2014
      [INFO] Final Memory: 23M/204M
      [INFO] ------------------------------------------------------------------------
      
    • また、デプロイメントは、アクティブアプリケーションサーバーインスタンスのステータスストリームで確認することもできます。

      例10.15 アプリケーションサーバーでの helloworld アプリケーションの確認

      09:09:49,167 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /home/username/EAP_HOME/standalone/data/content/32/4b4ef9a4bbe7206d3674a89807203a2092fc70/content
      09:09:49,175 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "jboss-helloworld.war" (runtime-name: "jboss-helloworld.war")
      09:09:49,563 INFO  [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016002: Processing weld deployment jboss-helloworld.war
      09:09:49,611 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: jboss-helloworld.war
      09:09:49,680 INFO  [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900 1.1.17 (redhat)
      09:09:49,705 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016008: Starting weld service for deployment jboss-helloworld.war
      09:09:50,080 INFO  [org.jboss.web] (ServerService Thread Pool -- 55) JBAS018210: Register web context: /jboss-helloworld
      09:09:50,425 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "jboss-helloworld.war" (runtime-name : "jboss-helloworld.war")
結果

アプリケーションが、アプリケーションサーバーにデプロイされます。

10.6.3. Maven によるアプリケーションのアンデプロイ

概要

このタスクでは、Maven を用いてアプリケーションをアンデプロイする方法について説明します。ここで使用される例は、JBoss EAP 6 のクイックスタートにある jboss-helloworld.war アプリケーションを使用します。helloworld プロジェクトには、jboss-as-maven-plugin を初期化する POM ファイルが含まれています。このプラグインを使用すると、アプリケーションサーバーでアプリケーションを簡単にデプロイおよびアンデプロイできます。

手順10.14 Maven によるアプリケーションのアンデプロイ

  1. ターミナルセッションを開き、quickstart サンプルが含まれるディレクトリーに移動します。

    例10.16 helloworld アプリケーションディレクトリーへの移動

    [localhost]$ cd /QUICKSTART_HOME/helloworld
    
  2. Maven アンデプロイコマンドを実行してアプリケーションをアンデプロイします。
    [localhost]$ mvn jboss-as:undeploy
  3. 結果を確認します。
    • アンデプロイメントは、ターミナルウィンドウの操作ログを参照して確認できます。

      例10.17 Maven による helloworld アプリケーションのアンデプロイの確定

      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESSFUL
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 1 second
      [INFO] Finished at: Mon Oct 10 17:33:02 EST 2011
      [INFO] Final Memory: 11M/212M
      [INFO] ------------------------------------------------------------------------
    • また、アンデプロイメントは、アクティブアプリケーションサーバーインスタンスのステータスストリームで確認することもできます。

      例10.18 アプリケーションサーバーによる helloworld アプリケーションのアンデプロイの確定

      09:51:40,512 INFO  [org.jboss.web] (ServerService Thread Pool -- 69) JBAS018224: Unregister web context: /jboss-helloworld
      09:51:40,522 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016009: Stopping weld service for deployment jboss-helloworld.war
      09:51:40,536 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment jboss-helloworld.war (runtime-name: jboss-helloworld.war) in 27ms
      09:51:40,621 INFO  [org.jboss.as.repository] (management-handler-thread - 10) JBAS014901: Content removed from location /home/username/EAP_HOME/jboss-eap-6.4/standalone/data/content/44/e1f3c55c84b777b0fc201d69451223c09c9da5/content
      09:51:40,621 INFO  [org.jboss.as.server] (management-handler-thread - 10) JBAS018558: Undeployed "jboss-helloworld.war" (runtime-name: "jboss-helloworld.war")
      
結果

アプリケーションが、アプリケーションサーバーからアンデプロイされます。

10.7. JBoss EAP 6 にデプロイされたアプリケーションの順序制御

JBoss EAP 6 では、サーバー起動時にアプリケーションがデプロイされる順序を細かく制御できます。複数の ear ファイルに存在するアプリケーションのデプロイメント順序を徹底することが可能で、再起動後の順序を永続化することも可能です。

手順10.15 EAP 6.0 におけるデプロイメント順序の制御

  1. サーバーの起動または停止時に、順番にアプリケーションをデプロイおよびアンデプロイする CLI スクリプトを作成します。
  2. CLI はバッチモードの概念をサポートします。バッチモードでは、コマンドや操作をグループ化でき、グループ化したコマンドや操作をアトミックユニットとして一緒に実行できます。1 つ以上のコマンドや操作が失敗すると、正常に実行された他のコマンドや操作はロールバックされます。

手順10.16 EAP 6.1 以降におけるデプロイメント順序の制御

EAP 6.1 以降は、Inter Deployment Dependencies (デプロイメント間依存関係) を使用すると、トップレベルのデプロイメント間の依存関係を宣言できます。
  1. jboss-all.xml ファイルがない場合は、app.ear/META-INF フォルダーに作成します。app.ear はアプリケーションアーカイブで、このアーカイブの前にデプロイされる他のアプリケーションアーカイブに依存します。
  2. 次のように、このファイルに jboss-deployment-dependencies エントリーを作成します。下記では、framework.ear は依存されるアプリケーションアーカイブで、app.ear アプリケーションアーカイブの前にデプロイする必要があります。
    <jboss umlns="urn:jboss:1.0">
      <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0">
        <dependency name="framework.ear" />
      </jboss-deployment-dependencies>
    </jboss>

10.8. デプロイメント記述子の上書き

JBoss EAP 6.1 以降では、デプロイメント記述子、JAR、クラス、JSP ページー、およびその他のファイルを実行時に上書きできます。デプロイメントオーバーレイは、アーカイブで上書きする必要があるファイルのルールセットを表します。また、上書きされるファイルの代わりに使用する必要がある新しいファイルへのリンクも提供します。上書きされたファイルがデプロイメントアーカイブにない場合は、デプロイメントへ戻されます。

手順10.17 管理 CLI を使用したデプロイメント記述子の上書き

次の手順は、app.war というデプロイされたアプリケーションが存在し、このアプリケーションの WEB-INF/web.xml ファイルを /home/user/web.xml にある別の web.xml で上書きすることを前提とします。
  1. デプロイメントオーバーレイを追加し、そこにコンテンツを追加します。これを行う方法は 2 つあります。
    • DMR ツリーの使用

      1. /deployment-overlay=myoverlay:add
      2. /deployment-overlay=myoverlay/content=WEB-INF\/web.xml:add(content={url=file:///home/user/web.xml})
        また、2 番目のステートメントを使用してコンテンツルールを追加できます。
    • 便利なメソッドの使用

      deployment-overlay add --name=myoverlay --content=WEB-INF/web.xml=/home/user/web.xml
  2. オーバーレイをデプロイメントアーカイブへリンクします。これには、以下の 2 つの方法があります。
    • DMR ツリーの使用

      /deployment-overlay=myoverlay/deployment=app.war:add
    • 便利なメソッドの使用

      deployment-overlay link --name=myoverlay --deployments=app.war
      複数のアーカイブ名を指定するには、コンマで区切ります。
    デプロイメントアーカイブ名がサーバー上に存在する必要がないことに注意してください。名前は指定しますが、まだこの段階では実際のデプロイメントへはリンクしません。
  3. アプリケーションの再デプロイ

    /deployment=app.war:redeploy

第11章 サブシステムの設定

11.1. サブシステム設定の概要

はじめに

JBoss EAP 6 は単純化された設定を使用します (ドメインごとまたはスタンドアロンサーバーごとに 1 つの設定ファイルを使用)。ドメインモードでは、各ホストコントローラーに対しても個別のファイルが存在します。設定の変更は自動的に保持されるため、XML を手動で編集する必要はありません。設定は、管理 API により自動的にスキャンされ、上書きされます。コマンドラインベースの管理 CLI および Web ベースの管理コンソールにより、JBoss EAP 6 の各側面を設定することができます。

JBoss EAP 6 は、モジュールベースのクラスローディングの概念に基づいて構築されています。プラットフォームによって提供される各 API やサービスはモジュールとして実装されます。このモジュールはオンデマンドでロード/アンロードされます。ほとんどのモジュールにはサブシステムと呼ばれる設定可能な要素が含まれています。サブシステム設定情報は、管理対象ドメインの場合には EAP_HOME/domain/configuration/domain.xml、スタンドアロンサーバーの場合には EAP_HOME/standalone/configuration/standalone.xml という統合設定ファイルに保管されます。多くのサブシステムには、以前の JBoss EAP の旧バージョンでデプロイメント記述子に追加された設定詳細が含まれます。
サブシステム設定スキーマ

各サブシステムの設定は XML スキーマで定義されます。設定スキーマは、ご使用のインストールの EAP_HOME/docs/schema/ ディレクトリーにあります。

以下のサブシステムは、設定可能な属性や要素がないため簡易サブシステムと呼ばれ、通常は設定ファイルの最上部に記載されます。

簡易サブシステム

  • ee– Java EE 6 API 実装
  • ejb– Enterprise JavaBeans (EJB) サブシステム
  • jaxrs– RESTeasy によって提供される JAX-RS API
  • sar– サービスアーカイブをサポートするサブシステム
  • threads– プロセススレッドをサポートするサブシステム
  • weld– Weld によって提供される Contexts and Dependency Injection (コンテキストと依存性の注入) API

第12章 ロギングサブシステム

12.1. はじめに

12.1.1. ロギングの概要

JBoss EAP 6 は、独自の内部使用とデプロイされたアプリケーションによる使用のために設定可能な高度なロギング機能を提供します。ロギングサブシステムは JBoss LogManager を基盤とし、JBoss Logging 以外にも複数のサードパーティーアプリケーションのロギングフレームワークをサポートします。
ロギングサブシステムは、ログカテゴリーとログハンドラーのシステムを使用して設定されます。ログカテゴリーはキャプチャーするメッセージを定義し、ログハンドラーはこれらのメッセージの処理方法を定義します (ディスクへの書き込みやコンソールへの送信など)。
ロギングプロファイルは、一意に名前が付けられたロギング設定のセットを作成し、他のロギング設定に依存しないアプリケーションへ割り当てることが可能です。ロギングプロファイルの設定はメインのロギングサブシステムとほぼ同じです。

12.1.2. JBoss LogManager でサポートされるアプリケーションロギングフレームワーク

JBoss LogManager は次のロギングフレームワークをサポートします。

12.1.3. 起動時のロギング

起動中に JBoss EAP は Java 環境と各サービスの起動に関するログエントリーを出力します。このログは、トラブルシューティングを行う場合に役に立ちます。デフォルトでは、すべてのログエントリーがファイル server.log に書き込まれます。このファイルの場所はランタイムモードによって異なります。
スタンドアロンモード
EAP_HOME/standalone/log/server.log
ドメインモード
EAP_HOME/domain/servers/SERVER_NAME/log/server.log
起動時のロギングの設定は、設定ファイル logging.properties で指定されます。このファイルの場所はランタイムモードによって異なります。
スタンドアロンモード
EAP_HOME/standalone/configuration/logging.properties
ドメインモード
ドメインモードでは、ドメインコントローラーと各サーバー向けのファイル logging.properties が存在します。
ドメインコントローラー: EAP_HOME/domain/configuration/logging.properties
サーバー: EAP_HOME/domain/servers/SERVER_NAME/data/logging.properties
設定ファイル logging.properties は、ロギングサブシステムが起動し、引き継ぐまでアクティブです。

警告

logging.properties ファイルは、直接編集が必要な特定のユースケースではない限り直接編集しないことが推奨されます。直接編集する前に、サポートケースを報告することが推奨されます。
logging.properties ファイルに手動で行った変更は起動時に上書きされます。

12.1.4. 起動エラーの表示

JBoss EAP をトラブルシューティングする場合、最初に行うべきことの 1 つは、起動時に発生したエラーをチェックすることです。起動エラーを表示するには 2 つの方法があります。どちらの方法でも、起動時に発生したすべてのエラーがリストされます。提供された情報を使用して原因を診断し、解決してください。トラブルシューティングのサポートについては、Red Hat カスタマーサポートまでご連絡ください。
  • server.log ログファイルを調べます。
    この方法では、各エラーメッセージおよび関連するメッセージを確認でき、エラーが発生した理由の詳細を知ることができます。また、エラーメッセージをプレーンテキスト形式で表示することもできます。
  • JBoss EAP 6.4 以降は、管理 CLI コマンド read-boot-errors を使用します。
    この方法では、サーバーのファイルシステムにアクセスする必要がありません。したがって、エラーを監視する担当者がファイルシステムアクセスを持ってない場合に役に立ちます。これは CLI コマンドであるため、スクリプトで使用できます。たとえば、複数の JBoss EAP インスタンスを起動し、起動時に発生したエラーをチェックするスクリプトを記述できます。

手順12.1 server.log でエラーを調べる

  1. ファイル server.log をファイルビューアーで開きます。
  2. ファイルの最後に移動します。
  3. 最後の起動シーケンスの開始を示すメッセージ ID JBAS015899 を後方検索します。
  4. ログのその位置から ERROR を前方検索します。各検索一致箇所には、エラーの説明が示され、関連するモジュールがリストされます。

例12.1 server.log のエラー説明

以下は、server.log ログファイルのエラー説明の例です。
13:23:14,281 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-4) JBWEB003043: Error initializing endpoint: java.net.BindException: Address already in use /127.0.0.1:8080

手順12.2 管理 CLI で起動エラーをリストする

  • 次の管理 CLI コマンドを実行します。
    /core-service=management:read-boot-errors
    起動中に発生したすべてのエラーがリストされます。
    各エラーのタイムスタンプは Java メソッド currentTimeMillis() を使用します。これは、現在時刻と 1970 年 1 月 1 日午前 0 時 UTC (協定世界時) の差 (ミリ秒単位) です。

例12.2 read-boot-errors コマンドの出力

{
"outcome" => "success",
"result" => [{
    "failed-operation" => {
        "operation" => "add",
        "address" => [
            ("subsystem" => "web"),
            ("connector" => "http")
        ]
    },
    "failure-timestamp" => 1417560953245L,
    "failure-description" => "{\"JBAS014671: Failed services\" => {\"jboss.web.connector.http\" => \"org.jboss.msc.service.StartException in service jboss.web.connector.http: JBAS018007: Error starting web connector
Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed\"}}",
    "failed-services" => {"jboss.web.connector.http" => "org.jboss.msc.service.StartException in service jboss.web.connector.http: JBAS018007: Error starting web connector
Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed"}
}]
}

12.1.5. ガベッジコレクションロギング

ガベッジコレクションロギングは、すべてのガベッジコレクションのアクティビティーをプレーンテキストのログファイルに記録します。これらのログファイルは診断を行うのに便利です。JBoss EAP 6 より、ガベッジコレクションロギングは IBMJDK を除くすべてのサポート対象設定の standalone モードでデフォルトで有効になっています。
ロギングはファイル EAP_HOME/standalone/log/gc.log.digit へ出力されます。ログロテーションは有効になっており、ログファイルの数は 5 に制限され、各ログファイルの最大サイズは 3 MiB に制限されています。

12.1.6. 暗黙的なロギング API の依存関係

JBoss EAP 6 のロギングサブシステムには、コンテナが暗黙的なロギング API 依存関係をデプロイメントに追加するかどうかを制御する add-logging-api-dependencies 属性が含まれています。デフォルトでは、この属性は true に設定され、暗黙的なロギング API 依存関係はすべてデプロイメントへ追加されます。false に設定すると、暗黙的なロギング API 依存関係は追加されません。
管理 CLI を使用して add-logging-api-dependencies 属性を設定できます。例は次のとおりです。
/subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)