管理および設定ガイド

JBoss Enterprise Application Platform 6.3

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.3.0 の機能

機能説明
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.3 では、ドメインコントローラーを検索する複数のオプションを使用して各ホストコントローラーを設定できるようになりました。ホストコントローラーは、適切なオプションが見つかるまでオプションのリストを繰り返し処理します。
これにより、バックアップドメインコントローラーのコンタクト情報を用いてホストコントローラーを事前設定できます。プライマリードメインコントローラーに問題がある場合は、バックアップホストコントローラーをマスターに昇格でき、昇格後にホストコントローラーを新しいマスターへ自動的にフェールオーバーできます。
以下は、ドメインコントローラー検索の複数のオプションを持つホストコントローラーを設定する方法の例になります。
<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 つ目のサーバーグループでアプリケーションがアップデートされるアプリケーションのローリングアップグレードが可能になり、サービスの完全停止を防ぎます。
以下はサーバーグループ定義の例になります。
<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 を開始するために使用される設定を作成します。

1.10. JBoss EAP 6 プロファイル

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

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

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

2.1.1. JBoss EAP 6 の起動

JBoss EAP 6 を次のいずれかの方法で起動します。

2.1.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.1.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.1.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.1.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.1.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.1.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.1.8. サーバー実行時に渡すスイッチと引数のリファレンス

アプリケーションサーバーの起動スクリプトは実行時に追加の引数とスイッチを受け取ります。これらのパラメーターを使用すると、standalone.xmldomain.xml、および host.xml の設定ファイルで定義されたものとは別の設定でサーバーを起動できます。これには、ソケットバインディングの代替セットや二次設定でのサーバーの起動が含まれることがあります。起動時にヘルプスイッチを渡すと、利用可能なこれらのパラメーターのリストを表示できます。

例2.5

以下の例は、「JBoss EAP 6 をスタンドアロンサーバーとして起動」 および 「JBoss EAP 6 を管理対象ドメインとして起動」 に説明のあるサーバーの起動と似ていますが、-h または --help スイッチが追加で使用されています。help スイッチの結果は以下の表を参照してください。
スタンドアロンモード:
[localhost bin]$ standalone.sh -h
ドメインモード:
[localhost bin]$ domain.sh -h

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

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

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

2.2.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.2.2. 管理コンソールを使用したサーバーの起動

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

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

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

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

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

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

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

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

2.3.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説明
jboss.home.dirJBoss EAP 6 ディストリビューションのルートディレクトリー。
user.homeユーザーのホームディレクトリー。
user.dirユーザーのカレントワーキングディレクトリー。
java.homeJava インストールディレクトリー。
jboss.server.base.dir各サーバーインスタンスのルートディレクトリー。
jboss.server.data.dirサーバーが永続データファイルストレージに使用するディレクトリー。
jboss.server.config.dirサーバー設定が含まれるディレクトリー。
jboss.server.log.dirサーバーがファイルストレージに使用するディレクトリー。
jboss.server.temp.dirサーバーが一時ファイルストレージに使用するディレクトリー。
jboss.controller.temp.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=/var/log
my.relative.path を使用するよう、ログハンドラーを変更します。

2.4. 設定ファイル

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

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

表2.3 設定ファイルの場所

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

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

アプリケーションの設定 (データソース接続パラメーターなど)は、通常はデプロイメント、テスト、および製品のデプロイメントによって異なります。Java EE 仕様にはこれらの設定を外部化するメソッドが含まれておらず、このような違いはビルドシステムスクリプトで対応することがあります。
JBoss Enterprise Application Platform 6 では、記述子ベースのプロパティー置換 を使用して設定を外部で管理できます。
記述子ベースのプロパティー置換 は、記述子を基にプロパティーを置き換えるため、アプリケーションやビルドチェーンから環境に関する仮定を除外できます。環境固有の設定は、アノテーションやビルドシステムスクリプトでなく、デプロイメント記述子に指定できます。設定はファイルに指定したり、パラメーターとしてコマンドラインで提供したりできます。
記述子ベースのプロパティー置換は、standalone.xml または domain.xml からグローバルに有効化されます。
<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>
ejb-jar.xml および persistence.xml の Java EE 記述子は置き換えできますが、デフォルトでは無効になっています。
JBoss 固有の記述子の置換はデフォルトで有効になっています。記述子は以下で置換できます。
  • jboss-ejb3.xml
  • jboss-app.xml
  • jboss-web.xml
  • *-jms.xml
  • *-ds.xml
たとえば、以下のアノテーションを持つ Bean があるとします。
 @ActivationConfigProperty(propertyName = "connectionParameters", propertyValue = "host=192.168.1.1;port=5445")
記述子ベースのプロパティー置換が有効になっている場合、コマンドラインで以下のように connectionParameters を指定できます。
./standalone.sh -DconnectionParameters='host=10.10.64.1;port=5445'
システムプロパティーで指定する場合は以下のようになります。
<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.4.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
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.4.4. ファイルの履歴設定

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

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

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

管理コンソールは、Google Web Toolkit (GWT) で構築された Web インターフェースの例です。管理コンソールは、HTTP 管理インターフェースを使用してサーバーと通信します。HTTP API エンドポイントは、管理レイヤーと統合するために HTTP プロトコルに依存する管理クライアントのエントリーポイントで、JSON でエンコードされたプロトコルとデタイプな (detyped) RPC スタイルの API を使用して管理対象ドメインまたはスタンドアロンサーバーに対して管理操作を記述および実行します。HTTP 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 と同じポートを介して提供されます。デフォルトの localhost でアクセスされる管理コンソール、特定のホストとポートの組み合わせによってリモートでアクセスされる管理コンソール、および公開されたドメイン API を区別することが重要です。

表3.1 管理コンソールへの URL

URL説明
http://localhost:9990/consoleローカルホストでアクセスされる管理コンソール (管理対象ドメイン設定を制御します)。
http://hostname:9990/consoleリモートでアクセスされる管理コンソール (ホストを指定し、管理対象ドメイン設定を制御します)。
http://hostname:9990/managementHTTP 管理 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.3 では、ユーザーは管理コンソールの 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.3 では、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.5. 管理 CLI

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

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

3.5.2. 管理 CLI の起動

手順3.6 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.7 管理対象サーバーインスタンスへの接続

  • 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.8 バッチモードのコマンドおよび操作

  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.9 要求の作成、設定、および実行

  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 ファイルは管理対象ドメインの設定を保持します。

      例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ファイルパスで指定されたアプリケーションをデプロイするか、リポジトリーで無効になっている既存のアプリケーションを有効にします。引数なしで実行された場合、既存のデプロイメントすべてがリストされます。
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-namespacenamespaces 属性のマップに名前空間接頭辞のマッピングを追加します。
add-schema-locationschema-locations 属性のマップにスキーマロケーションマッピングを追加します。
delete-snapshotsnapshots ディレクトリーからサーバー設定のスナップショットを削除します。
full-replace-deployment以前にアップロードされたデプロイメントコンテンツを使用可能なコンテンツの一覧に追加して、ランタイムの同名の既存コンテンツを置き換え、その置き換えられたコンテンツを使用可能なコンテンツの一覧から削除します。詳細については、リンク先を参照してください。
list-snapshotssnapshots ディレクトリーに保存されているサーバー設定のスナップショットを一覧表示します。
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-namespacenamespaces 属性マップから名前空間接頭辞のマッピングを削除します。
remove-schema-locationschema-locations 属性マップからスキーマロケーションマッピングを削除します。
replace-deploymentランタイムの既存のコンテンツを新しいコンテンツに置き換えます。新しいコンテンツを事前にデプロイメントコンテンツリポジトリーにアップロードする必要があります。
resolve-expression式を、式へ解析可能な入力または文字列として許可し、ローカルのシステムプロパティーおよび環境変数に対して解決する操作です。
resolve-internet-addressインターフェース解決基準を取り、その基準と一致するローカルマシンの IP アドレスを見つけます。一致する IP アドレスが見つからない場合は失敗します。
server-set-restart-required再起動が必要なモードにサーバーを設定します。
shutdownSystem.exit(0) の呼び出しにより、サーバーをシャットダウンします。
start-servers現在実行されていないすべての設定済みサーバーを管理対象ドメインで起動します。
stop-servers管理対象ドメインで現在実行しているすべてのサーバーを停止します。
take-snapshotサーバー設定のスナップショットを作成し、snapshots ディレクトリーに保存します。
upload-deployment-bytes含まれたバイトアレイのデプロイメントコンテンツをデプロイメントコンテンツリポジトリーに追加すべきであることを示します。この操作は、コンテンツがランタイムにデプロイされるべきであることを示すものではありません。
upload-deployment-stream対象入力ストリームインデックスで利用可能なデプロイメントコンテンツをデプロイメントコンテンツレポジトリーに追加すべきか指定します。この操作は、コンテンツをランタイムにデプロイすべきかは指定していません。
upload-deployment-url対象の URL で利用可能なデプロイメントコンテンツをデプロイメントコンテンツリポジトリーに追加すべきかを指定します。この操作は、コンテンツをランタイムにデプロイすべきかは指定しません。
validate-address操作のアドレスを検証します。
write-attribute選択したリソースの属性値を設定します。

3.6. 管理 CLI 操作

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

概要

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

要求プロパティー

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

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

  • read-attribute 操作の実行

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

例3.7 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.11 whoami を使用した管理 CLI でのアクティブユーザーの表示

  • whoami の実行

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

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

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

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

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

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

  • version コマンドの実行

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

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

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

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

  • read-operation-description 操作の実行

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

例3.9 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.14 管理 CLI でのコマンドの実行

  • read-operation-names の実行

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

例3.10 管理 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.15 管理 CLI でのコマンドの実行

  1. read-resource 操作の実行

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

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

    [standalone@localhost:9999 /]:read-resource
    {
        "outcome" => "success",
        "result" => {
            "deployment" => undefined,
            "deployment-overlay" => undefined,
            "management-major-version" => 1,
            "management-micro-version" => 0,
            "management-minor-version" => 4,
            "name" => "longgrass",
            "namespaces" => [],
            "product-name" => "EAP",
            "product-version" => "6.3.0.GA",
            "release-codename" => "Janus",
            "release-version" => "7.2.0.Final-redhat-3",
            "schema-locations" => [],
            "system-property" => undefined,
            "core-service" => {
                "management" => undefined,
                "service-container" => undefined,
                "server-environment" => undefined,
                "platform-mbean" => 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" => {
                "logging" => undefined,
                "datasources" => undefined,
                "deployment-scanner" => undefined,
                "ee" => undefined,
                "ejb3" => undefined,
                "infinispan" => undefined,
                "jaxrs" => undefined,
                "jca" => undefined,
                "jdr" => undefined,
                "jmx" => undefined,
                "jpa" => undefined,
                "jsf" => undefined,
                "mail" => undefined,
                "naming" => undefined,
                "pojo" => undefined,
                "remoting" => undefined,
                "resource-adapters" => undefined,
                "sar" => undefined,
                "security" => undefined,
                "threads" => undefined,
                "transactions" => undefined,
                "web" => undefined,
                "webservices" => undefined,
                "weld" => undefined
            }
        }
    }
  2. 子ノードに対する read-resource 操作の実行

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

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

    [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.13 ディレクトリーの変更による子ノードリソースの公開

    [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.14 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.16 管理 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.15 アプリケーションのリロード

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

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

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

  • 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
      Connected to IP_ADDRESS:PORT_NUMBER
      [192.168.1.10:9999 /] :shutdown
      IP_ADDRESS をインスタンスの IP アドレスに置き換えます。
結果

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

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

概要

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

要求プロパティー

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

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

  • write-attribute 操作の実行

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

例3.16 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.19 管理 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.17 システムプロパティーをスタンドアロンサーバーへ追加

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

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

      [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.19 システムプロパティーをドメインのホストおよびそのサーバーへ追加

      [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.20 システムプロパティーを管理対象ドメインのサーバーインスタンスへ追加

      [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.21 スタンドアロンサーバーからシステムプロパティーの読み取り

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

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

      [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.23 ドメインのホストおよびそのサーバーからシステムプロパティーを読み取り

      [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.24 管理対象ドメインのサーバーインスタンスからシステムプロパティーを読み取り

      [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.25 スタンドアロンサーバーからシステムプロパティーを削除

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

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

      [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.27 ドメインのホストおよびそのインスタンスからシステムプロパティーを削除

      [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.28 管理対象ドメインのサーバーからシステムプロパティーを削除

      [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.20 管理 CLI コマンド履歴の表示

  • history コマンドの実行

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

監査ロギングが有効な場合、管理 API より実行されたすべての操作は監査ログに記録されます。管理コンソール、管理 CLI インターフェース、またはカスタムのインターフェースから実行されたすべての操作が監査ロギングの対象となります。デフォルトでは、ロギングは無効になっています。
ログエントリーは、保存される前にフォーマッターおよびハンドラーへ渡されます。フォーマッターはログエントリーの形式を指定し、ハンドラーはレコードを指定の宛先に出力します。現在、エントリーを JSON 形式で出力する 1 つのフォーマッターのみを使用できます。ハンドラーがログレコードをファイルに出力するよう設定したり、Syslog サーバーに転送したりすることができ、その両方を行うこともできます。

注記

監査ロギングは、管理 CLI からのみ設定できます。

3.8.2. 管理 CLI からの管理インターフェース監査ロギングの有効化

管理インターフェース監査ロギングはデフォルトで無効になっていますが、file という名前のファイルハンドラーを使用して EAP_HOME/standalone/data/audit-log.log ファイルにログレコードを出力するよう事前設定されています。
管理 CLI から監査ロギングを有効にするには、次のコマンドを使用します。
/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
管理インターフェースの監査ロギング設定属性とそれらの値をすべて表示するには、以下のコマンドを入力します。
/core-service=management/access=audit:read-resource(recursive=true)
管理インターフェースの監査ロギングを有効または無効にする以外に、以下の logger 設定属性を使用することもできます。
log-boot
true に設定された場合、サーバーを起動するときの管理操作が監査ログに含まれます。false の場合は含まれません。デフォルト値は false です。
log-read-only
true に設定された場合、すべての操作が監査ログに記録されます。false の場合は、モデルを変更する操作のみが記録されます。デフォルト値は false です。

3.8.3. 管理インターフェースの監査ロギングフォーマッター

フォーマッターはログエントリーの形式を指定します。ログエントリーを JSON 形式で出力する 1 つのフォーマッターのみを利用できます。各ログエントリーは任意のタイムスタンプで始まり、「JSON フォーマッターフィールド」の表に記載されているフィールドが続きます。
「JSON フォーマッター属性」の表には、ログエントリーの形式変更に使用できるすべての属性が記載されています。

表3.5 JSON フォーマッター属性

属性説明
include-dateフォーマットされたログレコードにタイムスタンプが含まれるかどうかを定義するブール値。
date-separator日付と日付以外のフォーマットされたログメッセージを区別する文字が含まれる文字列。include-date=false の場合は無視されます。
date-formatjava.text.SimpleDateFormat が理解するように、タイムスタンプに使用するデータ形式。include-date=false の場合は無視されます。
compacttrue の場合、JSON を 1 行でフォーマットします。新しい行が含まれる値が存在する可能性があるため、レコード全体を 1 行にするのが重要な場合は、escape-new-line または escape-control-characterstrue に設定します。
escape-control-characterstrue の場合、すべての制御文字 (10 進値が 32 未満の ASCII エントリー) を 8 進の ASCII コードでエスケープします。たとえば、新しい行は「#012」になります。true の場合、escape-new-line=false を上書きします。
escape-new-linetrue の場合、新しい行を 8 進の ASCII コードでエスケープします (例: #012)。

表3.6 JSON フォーマッターフィールド

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

3.8.4. 管理インターフェースの監査ロギングファイルハンドラー

ファイルハンドラーは、監査ログの記録がファイルへ出力されるようにするパラメーターを指定します。ファイルハンドラーは、ファイルのフォーマッター、ファイル名、およびパスを定義します。
「ファイルハンドラー監査ログ属性」の表には、ログエントリーの出力を変更するために使用できるすべての属性が記載されています。

表3.7 ファイルハンドラー監査ログ属性

属性説明読み取り専用
formatterログレコードをフォーマットするために使用する JSON フォーマッターの名前。False
path監査ログファイルのパス。False
relative-to以前指定された別のパスの名前、またはシステムによって提供される標準的なパスの 1 つ。relative-to が指定された場合、パス属性の値は、この属性によって指定されたパスへの相対値としてみなされます。False
failure-countハンドラーが初期化された後に発生したロギング失敗数。True
max-failure-countこのハンドラーを無効化する前の最大ロギング失敗数。False
disabled-due-to-failureロギングの失敗によりこのハンドラーが無効になった場合の値は true になります。True

3.8.5. 管理インターフェイスの監査ロギング syslog ハンドラー

syslog ハンドラーは、監査ログエントリーが syslog サーバーへ送信されるパラメーターを指定します。特に、syslog サーバーのホスト名と syslog サーバーがリッスンするポートを指定します。
監査ロギングを syslog サーバーへ送信すると、ローカルファイルまたはローカル syslog サーバーへロギングするよりも、セキュリティーオプションが多くなります。複数の syslog ハンドラーを定義できます。
syslog サーバーごとに実装が異なるため、すべての設定をすべての syslog サーバーに適用できるとは限りません。テストは rsyslog syslog 実装を使用して実行されています。

表3.8 syslog ハンドラーの属性

属性説明デフォルト値
app-nameRFC-5424 のセクション 6.2.5 で定義された syslog レコードに追加するアプリケーション名。指定されない場合、デフォルト値は製品の名前になります。undefined
disabled-due-to-failureロギングの失敗によりこのハンドラーが無効になった場合の値は true になります。false
facilityRFC-5424 のセクション 6.2.1 と RFC-3164 のセクション 4.1.1 で定義された syslog ロギングに使用する機能。USER_LEVEL
failure-countハンドラーが初期化された後に発生したロギング失敗数。0 (ゼロ)
formatterログレコードのフォーマットに使用するフォーマッターの名前。null
hostsyslog サーバーのホスト名。localhost
max-failure-countこのハンドラーを無効化する前の最大ロギング失敗数。10
max-lengthヘッダーを含む、ログメッセージの最大長 (バイト単位)。未定義の場合、デフォルト値は 1024 バイト (syslog-formatRFC3164 の場合) または 2048 バイト (syslog-formatRFC5424 の場合) になります。undefined
portsyslog サーバーがリッスンしているポート。514
protocolsyslog ハンドラーに使用するプロトコル。udptcp、または tls のいずれか 1 つである必要があります。null
syslog-formatsyslog 形式: RFC-5424 または RFC-3164.RFC5424
truncateヘッダーを含むメッセージの長さ (バイト長) が最大長を越える場合に、そのメッセージが省略されるかどうか。false に設定すると、メッセージが分割され、同じヘッダー値で送信されます。false

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

注記

管理対象ドメインへ変更を適用する場合は、/host=HOST_NAME 接頭辞を /core-service コマンドへ追加します。
この例では、syslog サーバーは 514 番ポートのローカルホストで実行しています。これらのパラメーターをご使用の環境に該当する値に置き換えます。

手順3.24 syslog サーバーへのロギングの有効化

  1. msyslog という名前の syslog ハンドラーを作成します。

    [standalone@localhost:9999 /]batch
    [standalone@localhost:9999 /]/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
    [standalone@localhost:9999 /]/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
    [standalone@localhost:9999 /]run-batch
  2. syslog ハンドラーへの参照を追加します。

    [standalone@localhost:9999 /]/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add
結果

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

第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-addressIPv6 または 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. 追加 をクリックします。
        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">
    <socket-binding name="http" port="8080"/>
    <socket-binding name="https" port="8443"/>
    <socket-binding name="jacorb" port="3528"/>
    <socket-binding name="jacorb-ssl" port="3529"/>
    <socket-binding name="jmx-connector-registry" port="1090" interface="management"/>
    <socket-binding name="jmx-connector-server" port="1091" interface="management"/>
    <socket-binding name="jndi" port="1099"/>
    <socket-binding name="messaging" port="5445"/>
    <socket-binding name="messaging-throughput" port="5455"/>
    <socket-binding name="osgi-http" port="8090" interface="management"/>
    <socket-binding name="remoting" port="4447"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
</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="osgi-http" interface="management" port="8090"/>
        <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="osgi-http" interface="management" port="8090"/>
        <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="osgi-http" interface="management" port="8090"/>
        <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="osgi-http" interface="management" port="8090"/>
        <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-porttrue の場合、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

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

名前ポートマルチキャストポート説明full-ha-socketsfull-socketsha-socketstandard-socket
ajp8009 Apache JServ プロトコル。HTTP クラスタリングおよび負荷分散に使用します。
http8080 デプロイされた Web アプリケーションのデフォルトポート。
https8443 デプロイされた Web アプリケーションとクライアント間の SSL 暗号化接続。
jacorb3528 JTS トランザクションおよび他の ORB 依存サービス用の CORBA サービス。××
jacorb-ssl3529 SSL 暗号化 CORBA サービス。××
jgroups-diagnostics 7500マルチキャスト。HA クラスターでのピアの検出に使用されます。管理インターフェースを使用しても設定できません。××
jgroups-mping 45700マルチキャスト。HA クラスターでの初期メンバーシップの検出に使用されます。××
jgroups-tcp7600 TCP を使用した、HA クラスター内でのユニキャストピア検出。××
jgroups-tcp-fd57600 TCP を介した HA 障害検出に使用されます。××
jgroups-udp5520045688UDP を使用した、HA クラスター内でのマルチキャストピア検出。××
jgroups-udp-fd54200 UDP を介した HA 障害検出に使用されます。××
messaging5445 JMS サービス。××
messaging-group HornetQ JMS ブロードキャストと検出グループにより参照されます。××
messaging-throughput5455 JMS Remoting により使用されます。××
mod_cluster 23364JBoss EAP 6 と HTTP ロードバランサー間の通信に対するマルチキャストポート。××
osgi-http8090 OSGi サブシステムを使用する内部コンポーネントにより使用されます。管理インターフェースを使用して設定できません。
remoting4447 リモート EJB の呼び出しに使用されます。
txn-recovery-environment4712 JTA トランザクションリカバリーマネージャー。
txn-status-manager4713 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
    例を以下に示します。
    # 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
    例を以下に示します。
    # 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 の管理ツールではサポートされないため、本番環境での使用は推奨されません。

重要

*-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
    複数のエントリーがある場合は、ドライバークラスの名前も指定する必要があります。これを行わないと、以下のようなエラーが発生します。
    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.1 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.2 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.3 複数のドライバークラスエントリーを持つ 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.4 複数のドライバークラスエントリーを持つ 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.5 依存関係の例

        Dependencies: com.mysql
      1. jboss-deployment-structure.xml ファイルの作成

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

        例6.6 サンプル jboss-deployment-structure.xml ファイル

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

例6.7 ベンダー固有 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. 以下のコマンドを実行して非 XA データソースを作成し、適切に変数を設定します。
        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. 以下のコマンドを実行して XA データソースを作成し、適切に変数を設定します。
        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 データソースが不適切に設定された場合は、ログ出力に次のようなエラーが示されることがあります。
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 インスタンスに対する適切なステートメントです。
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. データソースセキュリティー

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

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

 <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.9 パスワード vault の例

<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-urlJDBC ドライバーの接続 URL。
driver-classJDBC ドライバークラスの完全修飾名。
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-minpool-size が厳密かどうかを指定します。デフォルト値は false に設定されています。
flush-strategy
エラーの場合にプールをフラッシュするかどうかを指定します。有効な値は次の通りです。
  • FailingConnectionOnly
  • IdleConnections
  • EntirePool
デフォルト値は FailingConnectionOnly です。
allow-multiple-users複数のユーザーが getConnection(user, password) メソッドを使いデータソースへアクセスするかどうか、および内部プールタイプがこの動作に対応するかを指定します。

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

パラメーター説明
is-same-rm-overridejavax.transaction.xa.XAResource.isSameRM(XAResource) クラスが true あるいは false のどちらを返すかを指定します。
interleavingXA 接続ファクトリーのインターリービングを有効にするかどうかを指定します。
no-tx-separate-pools
コンテキスト毎に sub-pool を作成するかどうかを指定します。これには Oracle のデータソースが必要ですが、このデータソースは JTA トランザクションの内部、外部に関わらず、XA 接続の利用ができなくなります。
このオプションを使用すると 2 つの実際のプールが作成されるため、プールサイズの合計が max-pool-size の 2 倍になります。
pad-xidXid のパディングを行うかどうかを指定します。
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-locklock() の代わりに 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-sizeLRU (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
PostgreSQLjdbc:postgresql://SERVER_NAME:PORT/DATABASE_NAME
MySQLjdbc:mysql://SERVER_NAME:PORT/DATABASE_NAME
Oraclejdbc:oracle:thin:@ORACLE_HOST:PORT:ORACLE_SID
IBM DB2jdbc:db2://SERVER_NAME:PORT/DATABASE_NAME
Microsoft SQLServerjdbc: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.11

  • /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 データソースの例

例6.10

PostgreSQL のデータソースの設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<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>
      <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 ファイルの例は次のとおりです。
<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 データソースの例

例6.11

PostgreSQL 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>
      <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 ファイルの例は次のとおりです。
<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 データソースの例

例6.12

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>
      <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 ファイルの例は次のとおりです。
<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 データソースの例

例6.13

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>
      <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 ファイルの例は次のとおりです。
<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/> パラメーターが必要でした。一部のアプリケーションでは、このパラメーターが不要になりました。

例6.14

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>
      <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 ファイルの例は次のとおりです。
<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 を使用する場合)

例6.15

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>
      <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 ファイルの例は次のとおりです。
<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 のデータソースの例

例6.16

Microsoft SQLServer のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <datasource jndi-name="java:/MSSQLDS" pool-name="MSSQLDS">
    <connection-url>jdbc:microsoft: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>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
    </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 ファイルの例は次のとおりです。
<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 のデータソースの例

例6.17

Microsoft 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>
      <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 ファイルの例は次のとおりです。
<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 データソースの例

例6.18

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>
      <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 ファイルの例は次のとおりです。
<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 のデータソースの例

例6.19

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>
      <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 ファイルの例は次のとおりです。
<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 データソースの例

例6.20

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>
      <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 ファイルの例は次のとおりです。
<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 データソースの例

例6.21

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>
    <validation>
      <background-validation>true</background-validation>
      <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 ファイルの例は次のとおりです。
<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 サブシステム要素の例になります。
        <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
            <global-modules>
                <module name="myorg-conf" slot="main" />            
            </global-modules>
        </subsystem>
  3. my.properties という名前のファイルを正しいモジュールの場所にコピーした場合は、以下のようなコードを使用してプロパティーファイルをロードできるようになります。
    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 では、以下のようにディレクトリーのリストをコロンで区別します。
    export JBOSS_MODULEPATH=EAP_HOME/modules/:/home/username/external/modules/directory/
    Windows では、以下のようにディレクトリーのリストをセミコロンで区別します。
    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 ファイルになります。
    以下は、JBOSS_MODULEPATH 変数を 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=testvalve:add-param(param-name="NAME", param-value="VALUE")
    /subsystem=web/valve=testvalve: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 コマンドを入力します。
    [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.1 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.2 コマンドの実行

    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.3 デプロイおよびアンデプロイコマンド

    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.4 コマンドの実行

    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.5 touch コマンドを使用したデプロイ

      [user@host bin]$ touch $EAP_HOME/standalone/deployments/example.war.dodeploy
結果

アプリケーションファイルがアプリケーションサーバーにデプロイされます。マーカーファイルがデプロイメントフォルダーで作成され、デプロイメントが正常に終了したことを示します。アプリケーションは、管理コンソールで、Enabled と示されます。

例10.6 デプロイメント後のデプロイメントフォルダーコンテンツ

example.war
example.war.deployed

10.5.3. デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスからアプリケーションをアンデプロイ

概要

このタスクでは、デプロイメントスキャナーを使用してデプロイされたスタンドアロンサーバーインスタンスからアプリケーションをアンデプロイする方法を説明します。「アプリケーションデプロイメント 」 の説明にあるように、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には管理コンソールと管理 CLI の方法が推奨されます。

注記

デプロイメントスキャナーは、アプリケーション管理の他のデプロイメント方法とともに使用しないでください。管理コンソールによってアプリケーションサーバーから削除されたアプリケーションは、デプロイメントディレクトリーに含まれるマーカーファイルまたはアプリケーションに影響を与えずにランタイムから削除されます。意図しない再デプロイメントや、他のエラーの可能性を最低限にするには、本番稼働環境での管理に管理 CLI および管理コンソールを使用します。

手順10.10 以下の方法の 1 つを用いたアプリケーションのアンデプロイ

  • アプリケーションのアンデプロイ

    アプリケーションをデプロイする方法は 2 つありますが、アプリケーションをデプロイメントフォルダーから削除する場合と、デプロイメントの状態のみを変更する場合によって、使用する方法が異なります。
    • マーカーファイルの削除によるアンデプロイ

      デプロイされたアプリケーションの example.war.deployed マーカーファイルを削除して、ランタイムからアプリケーションのアンデプロイを開始するためにデプロイメントスキャナーをトリガーします。
      結果
      デプロイメントスキャナーは、アプリケーションをアンデプロイし、example.war.undeployed マーカーファイルを作成します。アプリケーションは、デプロイメントフォルダーに維持されます。
    • アプリケーションの削除によるアンデプロイ

      デプロイメントディレクトリーからアプリケーションを削除して、ランタイムからアプリケーションのアンデプロイを開始するためにデプロイメントスキャナーをトリガーします。
      結果
      デプロイメントスキャナーは、アプリケーションをアンデプロイし、filename.filetype.undeployed マーカーファイルを作成します。アプリケーションはデプロイメントフォルダーに存在しません。
結果

アプリケーションファイルは、アプリケーションサーバーからアンデプロイされ、管理コンソールの Deployments 画面に表示されません。

10.5.4. デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスにアプリケーションを再デプロイ

概要

このタスクでは、デプロイメントスキャナーを使用してデプロイされたスタンドアロンサーバーインスタンスにアプリケーションをデプロイする方法を説明します。「「アプリケーションデプロイメント 」」の説明にあるように、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には管理コンソールと管理 CLI の方法が推奨されます。

手順10.11 アプリケーションをスタンドアロンサーバーへ再デプロイ

  • アプリケーションの再デプロイ

    デプロイメントスキャナーでデプロイされたアプリケーションを再デプロイするには、3 つの方法があります。これらの方法はデプロイメントサイクルを開始するためにデプロイメントスキャナーをトリガーし、個々の設定に応じて選択できます。
結果

アプリケーションファイルが再デプロイされます。

10.5.5. デプロイメントスキャナーマーカーファイルのリファレンス

マーカーファイル

マーカーファイルは、デプロイメントスキャナーサブシステムの一部です。これらのファイルは、スタンドアロンサーバーインスタンスのデプロイメントディレクトリー内にあるアプリケーションの状態をマークします。マーカーファイルは、アプリケーションと同じ名前を持ち、ファイル接尾辞はアプリケーションのデプロイメントの状態を示します。以下の表に、各マーカーファイルのタイプおよび応答の定義を示します。

例10.8 マーカーファイル例

以下の例は、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デプロイメントスキャナーでデプロイメントをキャンセルするまでのデプロイメント試行許可時間 (秒単位)。Long600
pathスキャンする実際のファイルシステムパスを定義します。relative-to 属性が指定された場合は、path 値が、そのディレクトリーまたはパスに対する相対追加分として機能します。文字列deployments
relative-toサーバー設定 XML ファイルの paths セクションで定義されたファイルシステムパスの参照。文字列jboss.server.base.dir
scan-enabledscan-interval により起動時にアプリケーションの自動スキャンを許可します。ブール値True
scan-intervalリポジトリーのスキャン間の時間 (ミリ秒単位)。値が 1 未満の場合は、スキャナーが起動時にのみ動作します。Int5000

10.5.7. デプロイメントスキャナーの設定

デプロイメントスキャナーは、管理コンソールまたは管理 CLI を使用して設定できます。新しいデプロイメントスキャナーを作成したり、既存のスキャナー属性を管理したりできます。これらには、スキャン間隔、デプロイメントフォルダーの場所、およびデプロイメントをトリガーするアプリケーションファイルタイプが含まれます。

10.5.8. 管理 CLI でのデプロイメントスキャナーの設定

概要

デプロイメントスキャナーを設定する方法は複数ありますが、バッチスクリプトの使用やリアルタイムによる属性の公開および変更には、管理 CLI を使用できます。read-attribute および write-attribute グローバルコマンドライン操作を使用すると、デプロイメントスキャナーの挙動を変更できます。デプロイメントスキャナー属性の詳細については 「デプロイメントスキャナー属性のリファレンス」 の説明を参照してください。

デプロイメントスキャナーは JBoss EAP 6 のサブシステムで、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 操作を使用して、デフォルトのデプロイメントスキャナーリソースで定義された属性を公開します。
      [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 でのヘルプの取得」 を参照してください。
      [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.9 helloworld アプリケーションディレクトリーへの移動

    [localhost]$ cd /QUICKSTART_HOME/helloworld
  2. Maven デプロイコマンドを実行してアプリケーションをデプロイします。アプリケーションがすでに実行されている場合、アプリケーションは再デプロイされます。
    [localhost]$ mvn package jboss-as:deploy
  3. 結果を確認します。
    • デプロイメントは、ターミナルウィンドウで操作ログを参照して確認できます。

      例10.10 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.11 アプリケーションサーバーでの 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.12 helloworld アプリケーションディレクトリーへの移動

    [localhost]$ cd /QUICKSTART_HOME/helloworld
  2. Maven アンデプロイコマンドを実行してアプリケーションをアンデプロイします。
    [localhost]$ mvn jboss-as:undeploy
  3. 結果を確認します。
    • アンデプロイメントは、ターミナルウィンドウの操作ログを参照して確認できます。

      例10.13 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.14 アプリケーションサーバーによる 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.3/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.X におけるデプロイメント順序の制御

  1. サーバーの起動または停止時に、順番にアプリケーションをデプロイおよびアンデプロイする CLI スクリプトを作成します。
  2. CLI はバッチモードの概念をサポートします。バッチモードでは、コマンドや操作をグループ化でき、グループ化したコマンドや操作をアトミックユニットとして一緒に実行できます。1 つ以上のコマンドや操作が失敗すると、正常に実行された他のコマンドや操作はロールバックされます。

手順10.16 EAP 6.1.X 以降におけるデプロイメント順序の制御

Inter Deployment Dependencies (デプロイメント間依存関係) と呼ばれる EAP 6.1.X 以降の新機能を使用すると、トップレベルのデプロイメント間の依存関係を宣言できます。
  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. デプロイメント記述子の上書き

EAP 6.1.x には、デプロイメント記述子、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章 JBoss EAP 6 のセキュア化

11.1. セキュリティーサブシステム

security サブシステムは、アプリケーションのセキュリティーインフラストラクチャーを提供します。サブシステムは、現在のリクエストに関連するセキュリティーコンテキストを使用して認証マネージャー、承認マネージャー、監査マネージャー、およびマッピングマネージャーの機能を関係するコンテナに提供します。
security サブシステムはデフォルトで事前設定されているため、セキュリティー要素を変更する必要はほとんどありません。変更が必要となる可能性がある唯一のセキュリティー要素は、deep-copy-subject-mode を使用するかどうかです。ほとんどの場合で、管理者はセキュリティードメインの設定に集中します。
ディープコピーモード

ディープコピーサブジェクトモードの詳細は、「ディープコピーサブジェクトモード」を参照してください。

セキュリティードメイン

セキュリティードメインとは、認証、承認、監査、およびマッピングを制御するために単一または複数のアプリケーションが使用する Java Authentication and Authorization Service (JAAS) 宣言型セキュリティー設定のセットです。デフォルトでは、jboss-ejb-policyjboss-web-policy、および other の 3 つのセキュリティードメインが含まれています。アプリケーションの要件に対応するため、必要な数のセキュリティードメインを作成できます。セキュリティードメインの詳細は、「アプリケーションでのセキュリティードメインの使用」を参照してください。

11.2. セキュリティーサブシステムの構造

セキュリティーサブシステムは、管理対象ドメインまたはスタンドアロン設定ファイルに設定されます。設定要素のほとんどは、Web ベースの管理コンソールまたはコンソールベースの管理 CLI を使用して設定することが可能です。以下の XML はセキュリティーサブシステムの例を表しています。

例11.1 セキュリティーサブシステムの設定例

<subsystem xmlns="urn:jboss:domain:security:1.2">
	<security-management>
		...
	</security-management>
	<security-domains>
        <security-domain name="other" cache-type="default">
            <authentication>
                <login-module code="Remoting" flag="optional">
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
                <login-module code="RealmUsersRoles" flag="required">
                    <module-option name="usersProperties" value="${jboss.domain.config.dir}/application-users.properties"/>
                    <module-option name="rolesProperties" value="${jboss.domain.config.dir}/application-roles.properties"/>
                    <module-option name="realm" value="ApplicationRealm"/>
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
            </authentication>
        </security-domain>
        <security-domain name="jboss-web-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
        <security-domain name="jboss-ejb-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
    </security-domains>
    <vault>
    	...
    </vault>
</subsystem>
<security-management><subject-factory>、および <security-properties> 要素はデフォルト設定では存在しません。<subject-factory> および <security-properties> 要素は JBoss EAP 6.1 およびそれ以降のバージョンで廃止になりました。

11.3. セキュリティーサブシステムの設定

セキュリティーサブシステムの設定には、管理 CLI または Web ベースの管理コンソールを使用できます。
セキュリティーサブシステム内の各トップレベル要素には、セキュリティー設定の異なる情報が含まれています。セキュリティーサブシステムの設定例は 「セキュリティーサブシステムの構造」 を参照してください。
<security-management>
このセクションは、security サブシステムの高レベルの動作をオーバーライドします。スレッドの安全性を強化するため、セキュリティートークンへコピーまたはリンクするかどうかを指定するオプション設定 deep-copy-subject-mode が含まれます。
<security-domains>
複数のセキュリティードメインを保持するコンテナ要素です。セキュリティードメインには認証、承認、マッピング、監査モジュール、JASPI 認証、および JSSE 設定の情報が含まれることがあります。アプリケーションはセキュリティードメインを指定してセキュリティー情報を管理します。
<security-properties>
java.security.Security クラスに設定されるプロパティーの名前と値が含まれます。

11.4. ディープコピーサブジェクトモード

ディープコピーサブジェクトモード が無効であるときに (デフォルト)、セキュリティーデータ構造をコピーすると、データ構造全体がコピーされずに元のデータ構造への参照が作成されます。この挙動は効率的ですが、同一 ID の複数のスレッドによってフラッシュまたはログアウトの操作が行われ、サブジェクトが消去されると、データが破損しやすくなります。
ディープコピーサブジェクトモードでは、クローン可能と指定されていると、データ構造およびデータ構造に関連するデータの完全コピーが作成されます。このモードはよりスレッドセーフですが、効率は悪くなります。
ディープコピーサブジェクトモードは、セキュリティーサブシステムの一部として設定されます。

11.5. ディープコピーサブジェクトモードの有効化

Web ベースの管理コンソールまたは管理 CLI より、ディープコピーセキュリティーモードを有効にできます。

手順11.1 管理コンソールからディープコピーセキュリティーモードを有効化

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

    「管理コンソールへのログイン」 を参照してください。
  2. 管理対象ドメイン: 適切なプロファイルを選択します。

    管理対象ドメインではプロファイルごとにセキュリティーサブシステムが設定されているため、各プロファイルに対して個別にディープコピーセキュリティーモードを有効または無効にできます。
    プロファイルを選択するには、画面の上部にあるの右上にある Configuration をクリックし、左上にある Profile ドロップダウンボックスよりプロファイルを選択します。
  3. Security Subsystem 設定メニューを開きます。

    Security メニューを展開し、Security Subsystem を選択します。
  4. Deep Copy Subject モードを有効にします。

    Edit をクリックします。Deep Copy Subjects の横にあるボックスにチェックを入れ、ディープコピーサブジェクトモードを有効にします。
管理 CLI を使用したディープコピーサブジェクトモードの有効化

管理 CLI を使用してこのオプションを有効にしたい場合、以下のコマンドの 1 つを使用します。

例11.2 管理対象ドメイン

/profile=full/subsystem=security/:write-attribute(name=deep-copy-subject-mode,value=TRUE)

例11.3 スタンドアロンサーバー

/subsystem=security/:write-attribute(name=deep-copy-subject-mode,value=TRUE)

11.6. セキュリティードメイン

11.6.1. セキュリティードメイン

セキュリティードメインは JBoss EAP 6 のセキュリティーサブシステムの一部になります。すべてのセキュリティー設定は、管理対象ドメインのドメインコントローラーまたはスタンドアローンサーバーによって集中管理されるようになりました。
セキュリティードメインは認証、承認、セキュリティーマッピング、監査の設定によって構成されます。セキュリティードメインは Java Authentication and Authorization Service (JAAS) の宣言的セキュリティーを実装します。
認証とはユーザーアイデンティティーを検証することを言います。セキュリティー用語では、このユーザーをプリンシパルと呼びます。認証と承認は異なりますが、含まれている認証モジュールの多くは承認の処理も行います。
承認は、認証されたユーザーが、システムまたは操作の特定のリソースへアクセスできるパーミッションまたは特権を持っているかどうかをサーバーが判断するセキュリティーポリシーです。セキュリティー用語では、ロールとも呼ばれます。
セキュリティーマッピングとは、情報をアプリケーションに渡す前にプリンシパル、ロール、または属性から情報を追加、編集、削除する機能のことです。
監査マネージャーは、プロバイダーモジュールを設定して、セキュリティーイベントの報告方法を制御できるようにします。
セキュリティードメインを使用する場合、アプリケーション自体から特定のセキュリティー設定をすべて削除することが可能です。これにより、一元的にセキュリティーパラメーターを変更できるようにします。このような設定構造が有効な一般的な例には、アプリケーションをテスト環境と実稼動環境間で移動するプロセスがあります。

11.6.2. Picketbox

Picketbox は、認証、許可、監査、およびマッピング機能を、JBoss EAP 6 で実行されている Java アプリケーションに提供する基礎的なセキュリティーフレームワークです。単一構成の単一フレームワークで、次の機能を提供します。

11.6.3. 認証

認証とは、サブジェクトを識別し、身分が本物であるかを検証することを言います。最も一般的な認証メカニズムはユーザー名とパスワードの組み合わせです。その他の一般的な認証メカニズムは共有キー、スマートカード、または指紋などを使用します。Java Enterprise Edition の宣言的セキュリティーでは、成功した認証の結果のことをプリンシパルと呼びます。
JBoss EAP 6 は認証モジュールのプラグ可能なシステムを使用して、組織ですでに使用されている認証システムへ柔軟に対応し、統合を実現します。各セキュリティードメインには 1 つ以上の設定された認証モジュールが含まれます。各モジュールには、挙動をカスタマイズするための追加の設定パラメーターが含まれています。Web ベースの管理コンソール内に認証サブシステムを設定するのが最も簡単な方法です。
認証と承認が関連している場合も多くありますが、認証と承認は同じではありません。含まれている多くの認証モジュールは承認も処理します。

11.6.4. セキュリティードメインでの認証の設定

セキュリティードメインの認証を設定するには、管理コンソールにログインして以下の手順を実行します。

手順11.2 セキュリティードメインの認証設定

  1. セキュリティードメインの詳細ビューを開きます。

    1. 管理コンソールの上部にある Configuration ラベルをクリックします。
    2. プロファイルビューの左上にある Profile 選択ボックスから編集するプロファイルを選択します。
    3. Security メニューを展開し、Security Domains を選択します。
    4. 編集したいセキュリティードメインの View リンクをクリックします。
  2. 認証サブシステム設定に移動します。

    ビューの上部にある Authentication ラベルを選択します (未選択である場合)。
    設定領域が Login ModulesDetails の 2 つの領域に分割されます。ログインモジュールは、設定の基本単位です。セキュリティードメインには複数のログインモジュールを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。
  3. 認証モジュールを追加します。

    Add をクリックして、JAAS 認証モジュールを追加します。モジュールの詳細を入力します。
    Code はモジュールのクラス名です。Flag 設定は、モジュールが同じセキュリティードメイン内で他の認証モジュールにどのように関係するかを制御します。
    フラグの説明

    Java Enterprise Edition 6 の仕様には、以下のようなセキュリティーモジュールの説明があります。次のリストは、http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA に記載されています。詳細については、そのドキュメントを参照してください。

    フラグ説明
    required
    LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストを下方向に進み認証が続行されます。
    requisite
    LoginModule は成功する必要があります。成功すると、LoginModule リストの下方向に進み認証が続行されます。失敗すると、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、認証が続行されません)。
    sufficient
    LoginModule は成功する必要はありません。成功した場合は、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、認証が続行されません)。失敗すると、LoginModule リストの下方向に進み認証が続行されます。
    optional
    LoginModule は成功する必要がありません。成功または失敗した場合、LoginModule リストの下方向に進み認証が続行されます。
  4. 認証設定を編集します。

    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。
  5. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、Login Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を指定します。Remove ボタンを使用してオプションを削除します。
結果

認証モジュールが、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

jboss.security.security_domain モジュールのオプション

デフォルトでは、セキュリティードメインに定義された各ログインモジュールには jboss.security.security_domain モジュールオプションが自動的に追加されます。既知のオプションのみが定義されるようチェックを行うログインモジュールでは、このオプションによって問題が発生します。このようなログインモジュールの 1 つが IBM Kerberos ログインモジュールの com.ibm.security.auth.module.Krb5LoginModule です。

このモジュールオプションを追加する挙動を無効にするには、JBoss EAP 6 の起動時にシステムプロパティーを true に設定します。以下を起動パラメーターに追加します。
-Djboss.security.disable.secdomain.option=true
Web ベースの管理コンソールを使用してこのプロパティーを設定することも可能です。スタンドアロンサーバーでは、システムプロパティーを設定の Profile セクションに設定できます。管理対象ドメインでは、各サーバーグループのシステムプロパティーを設定できます。

11.6.5. 承認

承認とはアイデンティティーを基にリソースへのアクセスを許可または拒否するメカニズムのことです。プリンシパルに追加できる宣言的セキュリティーロールのセットとして実装されます。
JBoss EAP 6 はモジュラーシステムを使用して承認を設定します。各セキュリティードメインに 1 つ以上の承認ポリシーが含まれるようにすることができます。各ポリシーには動作を定義する基本モジュールがあり、特定のフラグや属性より設定されます。Web ベースの管理コンソールを使用すると承認サブシステムを最も簡単に設定できます。
承認は認証とは異なり、通常は認証後に承認が行われます。認証モジュールの多くは承認も処理します。

11.6.6. セキュリティードメインにおける承認の設定

セキュリティードメインの承認を設定するには、管理コンソールにログインして以下の手順を実行します。

手順11.3 セキュリティードメインの承認設定

  1. セキュリティードメインの詳細ビューを開きます。

    1. 管理コンソールの上部にある Configuration ラベルをクリックします。
    2. 管理対象ドメインでは、左上にある Profile ドロップダウンボックスで編集するプロファイルを選択します。
    3. Security メニューを展開し、Security Domains を選択します。
    4. 編集したいセキュリティードメインの View リンクをクリックします。
  2. 承認サブシステム設定に移動します。

    画面の上部にある Authorization ラベルを選択します。
    設定領域が PoliciesDetails の 2 つの領域に分割されます。ログインモジュールは、設定の基本単位です。セキュリティードメインには複数の承認ポリシーを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。
  3. ポリシーを追加します。

    Add をクリックして、JAAS 承認ポリシーモジュールを追加します。モジュールの詳細を入力します。
    Code はモジュールのクラス名です。Flag は、モジュールが同じセキュリティードメイン内で他の承認ポリシーモジュールにどのように関係するかを制御します。
    フラグの説明

    Java Enterprise Edition 6 の仕様には、以下のようなセキュリティーモジュールの説明があります。次のリストは、http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA に記載されています。詳細については、そのドキュメントを参照してください。

    フラグ説明
    required
    LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストを下方向に進み承認が続行されます。
    requisite
    LoginModule は成功する必要があります。成功すると、LoginModule リストの下方向に進み承認が続行されます。失敗すると、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、承認が続行されません)。
    sufficient
    LoginModule は成功する必要はありません。成功した場合は、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、承認が続行されません)。失敗すると、LoginModule リストの下方向に進み承認が続行されます。
    optional
    LoginModule は成功する必要がありません。成功または失敗した場合、LoginModule リストを下方向に進み承認が続行されます。
  4. 承認設定を編集します。

    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。
  5. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、Policies リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add をクリックし、オプションのキーと値を指定します。Remove ボタンを使用してオプションを削除します。
結果

承認ポリシーモジュールが、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

11.6.7. セキュリティー監査

セキュリティー監査とは、セキュリティーサブシステム内で発生したイベントに応答するため、ログへの書き込みなどのイベントをトリガーすることです。監査のメカニズムは、認証、承認、およびセキュリティーマッピングの詳細と共に、セキュリティードメインの一部として設定されます。
監査にはプロバイダーモジュールが使用されます。含まれているプロバイダーモジュールを使用するか、独自のモジュールを実装することができます。

11.6.8. セキュリティー監査の設定

セキュリティードメインのセキュリティー監査を設定するには、管理コンソールにログインして以下の手順を実行します。

手順11.4 セキュリティードメインのセキュリティー監査の設定

  1. セキュリティードメインの詳細ビューを開きます。

    1. 画面の上部にある Configuration をクリックします。
    2. 管理対象ドメインでは、左上にある Profile 選択ボックスから編集するプロファイルを選択します。
    3. Security メニューを展開し、Security Domains を選択します。
    4. 編集したいセキュリティードメインの View リンクをクリックします。
  2. 監査サブシステム設定に移動します。

    画面の上部にある Audit タブを選択します。
    設定領域が Provider ModulesDetails の 2 つの領域に分割されます。プロバイダーモジュールは、設定の基本単位です。セキュリティードメインには複数のプロバイダーモジュールを含めることができ、各ログインモジュールには属性とオプションを含めることができます。
  3. プロバイダーモジュールを追加します。

    Add をクリックします。Code セクションに、プロバイダーモジュールのクラス名を入力します。
  4. モジュールの挙動を確認します。

    監査モジュールの目的は、セキュリティーサブシステムのイベントを監視する方法を提供することです。ログファイルの記述、メールによる通知、またはその他の監査メカニズムによって監視を行うことが可能です。
    たとえば、JBoss EAP 6 にはデフォルトで LogAuditProvider モジュールが含まれています。この監査モジュールを前述の手順に従って有効にすると、EAP_HOME ディレクトリー内の log サブフォルダーにある audit.log ファイルにセキュリティー通知を書き込みます。
    前述の手順が LogAuditProvider のコンテキスト内で動作するかを確認するには、通知が発生するようなアクションを実行した後、監査ログファイルをチェックします。
    含まれるセキュリティー監査プロバイダーモジュールの完全一覧は 「含まれるセキュリティー監査プロバイダーモジュール」 を参照してください。
  5. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する場合は、Policies リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add をクリックし、オプションのキーと値を指定します。
    すでに存在するオプションを編集するには、Remove をクリックして削除し、Add をクリックして正しいオプションで再度追加します。
結果

セキュリティー監査モジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

11.6.9. 監査ログ

LogAuditProvider モジュールが有効な場合、アプリケーションおよびログインモジュールでの認証および承認を記録する監査ログが JBoss EAP 6 によって維持されます。デフォルトでは、このファイルの名前は audit.log になり、EAP_HOME ディレクトリーの log サブディレクトリーに保存されます。挙動は、ロギングサブシステムのログハンドラーの設定によって決定されます。syslog ログハンドラーを使用すると、ファイルの代わりまたはファイルとともに LogAuditProvider モジュールの出力を syslog サーバーに送信できます。
デフォルトでは、LogAuditProvider モジュールは累積の audit.log ファイルへのみ出力します。AUDIT と呼ばれる定期的にローテーションを行うファイルハンドラーを実装するには、以下の管理 CLI コマンドを入力します。
/subsystem=logging/periodic-rotating-file-handler=AUDIT/:add(suffix=.yyyy-MM-dd,formatter=%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n,level=TRACE,file={"relative-to" => "jboss.server.log.dir","path" => "audit.log"})

関連トピック:

11.6.10. セキュリティーマッピング

セキュリティーマッピングを使用すると、認証または承認が実行された後、情報がアプリケーションに渡される前に認証情報と承認情報を組み合わせることができます。
プリンシパル (認証)、ロール (承認)、またはクレデンシャル (プリンシパルやロールでない属性) をマッピングすることが可能です。
ロールマッピングは、認証後にサブジェクトへロールを追加、置換、または削除するために使用されます。
プリンシパルマッピングは、認証後にプリンシパルを変更するために使用されます。
属性マッピングは、外部システムからの属性値をアプリケーションで使用するために変換したり、逆にそのような外部システムへ属性を変換したりするために使用されます。

11.6.11. セキュリティードメインでのセキュリティーマッピングの設定

セキュリティードメインのセキュリティーマッピングを設定するには、管理コンソールにログインして以下の手順を実行します。

手順11.5 セキュリティードメインでのセキュリティーマッピングの設定

  1. セキュリティードメインの詳細ビューを開きます。

    1. 管理コンソールの上部にある Configuration ラベルをクリックします。
    2. 管理対象ドメインでは、左上にある Profile 選択ボックスからプロファイルを選択します。
    3. Security メニューを展開し、Security Domains を選択します。
    4. 編集したいセキュリティードメインの View リンクをクリックします。
  2. マッピングサブシステム設定に移動します。

    画面の上部にある Mapping ラベルを選択します。
    設定領域が ModulesDetails の 2 つの領域に分割されます。マッピングモジュールは、設定の基本単位です。セキュリティードメインには複数のマッピングモジュールを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。
  3. セキュリティーマッピングモジュールを追加します。

    Add をクリックします。
    モジュールの詳細を記入します。Code がモジュールのクラス名です。Type フィールドは、このモジュールが実行するマッピングのタイプを示します。許可される値は、principal、role、attribute、または credential です。
  4. セキュリティーマッピングモジュールを編集します。

    モジュールを追加したら、Code または Type を変更できます。
    1. Attributes タブを選択します。
    2. 画面の Details セクションにある Edit をクリックします。
  5. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する場合は、Policies リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add をクリックし、オプションのキーと値を指定します。
    すでに存在するオプションを編集するには、Remove をクリックして削除し、新たな値で再度追加します。
    Remove ボタンを使用して、オプションを削除します。
結果

セキュリティーマッピングモジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

11.6.12. アプリケーションでのセキュリティードメインの使用

概要

アプリケーションでセキュリティードメインを使用するには、最初にサーバーの設定でセキュリティードメインを定義し、アプリケーションのデプロイメント記述子でアプリケーションに対して有効にする必要があります。その後、使用する EJB に必要なアノテーションを追加する必要があります。ここでは、アプリケーションでセキュリティードメインを使用するために必要な手順について取り上げます。

警告

アプリケーションが、認証キャッシュを使用するセキュリティードメインの一部である場合、セキュリティードメインの他のアプリケーションもそのアプリケーションのユーザー認証を使用できます。

手順11.6 セキュリティードメインを使用するようアプリケーションを設定

  1. セキュリティードメインの定義

    サーバーの設定ファイルでセキュリティードメインを定義した後、アプリケーションの記述子ファイルでアプリケーションに対して有効にする必要があります。
    1. サーバーの設定ファイルへセキュリティードメインを設定

      セキュリティードメインは、サーバーの設定ファイルの security サブシステムに設定されます。JBoss EAP 6 インスタンスが管理対象ドメインで実行されている場合、domain/configuration/domain.xml ファイルになります。JBoss EAP 6 インスタンスがスタンドアロンサーバーとして実行されている場合は standalone/configuration/standalone.xml ファイルになります。
      otherjboss-web-policy、および jboss-ejb-policy セキュリティードメインはデフォルトとして JBoss EAP 6 に提供されます。次の XML の例は、サーバーの設定ファイルの security サブシステムよりコピーされました。
      セキュリティードメインの cache-type 属性は、高速な認証チェックを行うためにキャッシュを指定します。簡単なマップをキャッシュとして使用する default か、Infinispan キャッシュを使用する infinispan を値として使用できます。
      <subsystem xmlns="urn:jboss:domain:security:1.2">
          <security-domains>
              <security-domain name="other" cache-type="default">
                  <authentication>
                      <login-module code="Remoting" flag="optional">
                          <module-option name="password-stacking" value="useFirstPass"/>
                      </login-module>
                      <login-module code="RealmDirect" flag="required">
                          <module-option name="password-stacking" value="useFirstPass"/>
                      </login-module>
                  </authentication>
              </security-domain>
              <security-domain name="jboss-web-policy" cache-type="default">
                  <authorization>
                      <policy-module code="Delegating" flag="required"/>
                  </authorization>
              </security-domain>
              <security-domain name="jboss-ejb-policy" cache-type="default">
                  <authorization>
                      <policy-module code="Delegating" flag="required"/>
                  </authorization>
              </security-domain>
          </security-domains>
      </subsystem>
      管理コンソールまたは CLI を使用して、追加のセキュリティードメインを必要に応じて設定できます。
    2. アプリケーションの記述子ファイルでのセキュリティードメインの有効化

      セキュリティードメインはアプリケーションの WEB-INF/web.xml ファイルにある <jboss-web> 要素の <security-domain> 子要素に指定されます。次の例は my-domain という名前のセキュリティードメインを設定します。
      <jboss-web>
          <security-domain>my-domain</security-domain>
      </jboss-web>
      これが WEB-INF/jboss-web.xml 記述子に指定できる多くの設定の 1 つになります。
  2. EJB への必要なアノテーションの追加

    @SecurityDomain および @RolesAllowed アノテーションを使用してセキュリティーを EJB に設定します。次の EJB コードの例は、guest ロールのユーザーによる other セキュリティードメインへのアクセスを制限します。
    package example.ejb3;
    
    import java.security.Principal;
    
    import javax.annotation.Resource;
    import javax.annotation.security.RolesAllowed;
    import javax.ejb.SessionContext;
    import javax.ejb.Stateless;
    
    import org.jboss.ejb3.annotation.SecurityDomain;
    
    /**
     * Simple secured EJB using EJB security annotations
     * Allow access to "other" security domain by users in a "guest" role.
     */
    @Stateless
    @RolesAllowed({ "guest" })
    @SecurityDomain("other")
    public class SecuredEJB {
    
       // Inject the Session Context
       @Resource
       private SessionContext ctx;
    
       /**
        * Secured EJB method using security annotations
        */
       public String getSecurityInfo() {
          // Session context injected using the resource annotation
          Principal principal = ctx.getCallerPrincipal();
          return principal.toString();
       }
    }
    その他のコード例は、Red Hat カスタマーポータルより入手できる JBoss EAP 6 Quickstarts バンドルの ejb-security クイックスタートを参照してください。

11.6.13. JACC (Java Authorization Contract for Containers)

11.6.13.1. JACC (Java Authorization Contract for Containers)

JACC (Java Authorization Contract for Containers) はコンテナーと承認サービスプロバイダー間のインターフェースを定義する規格で、これによりコンテナーによって使用されるプロバイダーの実装が可能になります。JACC は JSR-115 に定義されており、http://jcp.org/en/jsr/detail?id=115 の Java Community Process Web サイトで確認できます。Java EE バージョン 1.3 より、コアの Java Enterprise Edition (Java EE) 仕様の一部となっています。
JBoss EAP 6 はセキュリティーサブシステムのセキュリティー機能内に JACC のサポートを実装します。

11.6.13.2. JACC (Java Authorization Contract for Containers) のセキュリティーの設定

JACC (Java Authorization Contract for Containers) を設定するには、適切なモジュールでセキュリティードメインを設定し、適切なパラメーターが含まれるよう jboss-web.xml を編集する必要があります。
セキュリティードメインへの JACC サポートの追加

セキュリティードメインに JACC サポートを追加するには、required フラグセットで JACC 承認ポリシーをセキュリティードメインの承認スタックへ追加します。以下は JACC サポートを持つセキュリティードメインの例になりますが、セキュリティードメインは直接 XML には設定されず、管理コンソールまたは管理 CLI で設定されます。

<security-domain name="jacc" cache-type="default">
    <authentication>
        <login-module code="UsersRoles" flag="required">
        </login-module>
    </authentication>
    <authorization>
        <policy-module code="JACC" flag="required"/>
    </authorization>
</security-domain>
JACC を使用するよう Web アプリケーションを設定

jboss-web.xml は デプロイメントの WEB-INF/ ディレクトリーに存在し、Web コンテナに対する追加の JBoss 固有の設定を格納し、上書きします。JACC が有効になっているセキュリティードメインを使用するには、<security-domain> 要素が含まれるようにし、 さらに <use-jboss-authorization> 要素を true に設定する必要があります。以下は、上記の JACC セキュリティードメインを使用するよう適切に設定されているアプリケーションになります。

<jboss-web>
    <security-domain>jacc</security-domain>
    <use-jboss-authorization>true</use-jboss-authorization>
</jboss-web>
JACC を使用するよう EJB アプリケーションを設定

セキュリティードメインと JACC を使用するよう EJB を設定する方法は Web アプリケーションの場合とは異なります。EJB の場合、ejb-jar.xml 記述子にてメソッドまたはメソッドのグループ上でメソッドパーミッションを宣言できます。<ejb-jar> 要素内では、<method-permission> 要素のすべての子に JACC ロールに関する情報が含まれます。詳細は設定例を参照してください。EJBMethodPermission クラスは Java Enterprise Edition 6 API の一部で、http://docs.oracle.com/javaee/6/api/javax/security/jacc/EJBMethodPermission.html で説明されています。

例11.4 EJB の JACC メソッドパーミッション例

<ejb-jar>
  <assembly-descriptor>
    <method-permission>
      <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description>
      <role-name>employee</role-name>
      <role-name>temp-employee</role-name>
      <method>
        <ejb-name>EmployeeService</ejb-name>
        <method-name>*</method-name>
      </method>
    </method-permission>
  </assembly-descriptor>
</ejb-jar>
Web アプリケーションと同様にセキュリティードメインを使用して EJB の認証および承認メカニズムを指定することも可能です。セキュリティードメインは <security> 子要素の jboss-ejb3.xml 記述子に宣言されます。セキュリティードメインの他に、EJB が実行されるプリンシパルを変更する run-as プリンシパル を指定することもできます。

例11.5 EJB におけるセキュリティードメイン宣言の例

<ejb-jar> 
	<assembly-descriptor>
		<security>
  		<ejb-name>*</ejb-name>
  		<security-domain>myDomain</security-domain>
  		<run-as-principal>myPrincipal</run-as-principal>
		</security>
 	</assembly-descriptor>
</ejb-jar>

11.6.14. JASPI (Java Authentication SPI for Containers)

11.6.14.1. JASPI (Java Authentication SPI for Containers) のセキュリティー

Java Authentication SPI for Containers (JASPI または JASPIC) は Java アプリケーションのプラグ可能なインターフェースです。Java Community Process の JSR-196 に定義されています。この仕様の詳細は http://www.jcp.org/en/jsr/detail?id=196 を参照してください。

11.6.14.2. JASPI (Java Authentication SPI for Containers) のセキュリティーの設定

JASPI プロバイダーに対して認証するには、<authentication-jaspi> 要素をセキュリティードメインに追加します。設定は標準的な認証モジュールと似ていますが、ログインモジュール要素は <login-module-stack> 要素で囲まれています。設定の構成は次のとおりです。

例11.6 authentication-jaspi 要素の構成

<authentication-jaspi>
	<login-module-stack name="...">
	  <login-module code="..." flag="...">
	    <module-option name="..." value="..."/>
	  </login-module>
	</login-module-stack>
	<auth-module code="..." login-module-stack-ref="...">
	  <module-option name="..." value="..."/>
	</auth-module>
</authentication-jaspi>
ログインモジュール自体は標準的な認証モジュールと全く同じように設定されます。
Web ベースの管理コンソールは JASPI 認証モジュールの設定を公開しないため、JBoss EAP 6 を完全に停止してから、設定を EAP_HOME/domain/configuration/domain.xml または EAP_HOME/standalone/configuration/standalone.xml へ直接追加する必要があります。

11.7. IIOP のセキュア化

11.7.1. JBoss IIOP

IIOP (Internet Inter-ORB Protocol) は CORBA サーバー上でリモート機能を呼び出すために CORBA クライアントによって使用される通信プロトコルです。JBoss IIOP は、EJB 仕様によって定義されるとおり、JBoss EAP サーバー上にデプロイされたエンタープライズ Bean への CORBA/IIOP アクセスをサポートします。これにより、Java で書かれた RMI および IIOP クライアントや、Java、C++、およびその他の言語で書かれた CORBA クライアントがエンタープライズ Bean メソッドを利用できます。IIOP エンジンは CORBA に完全対応する他のエンジンに置き換えることができます。デフォルトのエンジンは、CORBA 標準の無料の実装である JacORB です。

11.7.2. IOR

IOR (Interoperable Object Reference) は、オブジェクトを識別するために CORBA システムで使用されます。IOR は以下で構成されます。
  • オブジェクトタイプ
  • サーバーのホスト名
  • サーバーのポート番号
  • オブジェクトを識別するオブジェクトキー
ホスト名とポート番号は、サーバーと通信するために使用されます。オブジェクトキーは、オブジェクトを識別するためサーバーによって使用されます。

11.7.3. IOR セキュリティーパラメーター

前提条件

  • 以下の管理 CLI コマンドで IOR 設定を有効にします。
    /subsystem=jacorb/ior-settings=default:add
  • JacORB サブシステムが有効になっていることを確認します。たとえば、