Sun GlassFish Enterprise Server v3 管理ガイド

パート I ランタイム管理

第 2 章管理の概要

この章では、asadmin コマンド行ユーティリティーを使用して、&ProductBrand^TM; Enterprise Server v3 の環境で一般的な管理タスクを実行する方法について説明します。

ここでは、次のテーマを取り上げます。

管理コンソールを使用してこの章のタスクを実行する方法は、管理コンソールのオンラインヘルプに記載されています。

`asadmin` ユーティリティーの使用

Sun GlassFish Enterprise Server の管理タスクを実行するには、コマンド行またはスクリプトから asadmin ユーティリティーを使用します。このユーティリティーは、管理コンソールインタフェースの代わりに使用できます。

ここでは、次のテーマを取り上げます。

`asadmin` ユーティリティーのパス

asadmin ユーティリティは、as-install /bin ディレクトリにあります。パスを指定せずに asadmin ユーティリティーを実行するには、このディレクトリをパスに入れてください。

`asadmin` ユーティリティーの構文

asadmin ユーティリティーを実行するための構文は次のとおりです。

asadmin [asadmin-util-options] [subcommand [subcommand-options] [operands]]

この構文で置き換え可能な項目については、以降の項で説明します。この構文の詳細については、asadmin(1M) のマニュアルページを参照してください。

`asadmin` ユーティリティーのサブコマンド

次の「サブコマンド」は、実行する動作またはタスクを指定します。サブコマンドは大文字と小文字を区別します。サブコマンドは、ローカルサブコマンドとリモートサブコマンドのいずれかです。

「ローカルサブコマンド」は、ドメイン管理サーバー (DAS) を動作させずに実行できます。ただし、サブコマンドを実行してインストールディレクトリやドメインディレクトリにアクセスするには、ドメインのホストマシンにログインする必要があります。
「リモートコマンド」は常に、DAS に接続して DAS でサブコマンドを実行することにより実行されます。稼働中の DAS が必要です。

このリリースの Enterprise Server のサブコマンドリストについては、『Sun GlassFish Enterprise Server v3 Reference Manual』の第 1 節を参照してください。

`asadmin` ユーティリティーのオプションとサブコマンドのオプション

オプションは、asadmin ユーティリティーとそのサブコマンドの動作を制御します。オプションは大文字と小文字を区別します。

asadmin ユーティリティーには、次のタイプのオプションがあります。

asadmin ユーティリティーのオプション。これらのオプションは、asadmin ユーティリティーの動作を制御します。サブコマンドの動作は制御しません。asadmin ユーティリティーのオプションは、サブコマンドの前後に指定できますが、サブコマンドの後に asadmin ユーティリティーのオプションを指定することは推奨しません。asadminユーティリティーのオプションは、サブコマンドの前、または後にすべて指定する必要があります。asadmin ユーティリティーのオプションをサブコマンドの前と後の両方に指定した場合、エラーが発生します。asadmin ユーティリティーのオプションの詳細については、asadmin(1M) のマニュアルページを参照してください。
「サブコマンドオプション」。これらのオプションは、サブコマンドの動作を制御します。asadmin ユーティリティーの動作は制御しません。サブコマンドオプションは、サブコマンドの後に指定する必要があります。サブコマンドのオプションの詳細については、『Sun GlassFish Enterprise Server v3 Reference Manual』のサブコマンドの項目を参照してください。

注 –
サブコマンドオプションの一部は、このリリースの Enterprise Server ではサポートされていません。サポートされていないオプションを指定しても、構文エラーは発生しません。その代わりコマンドが正常に実行され、未サポートのオプションは単に無視されます。

サブコマンドオプションの名前が、asadmin ユーティリティーのオプションの名前と同じ場合がありますが、2 つのオプションの効果は異なります。

オプションには、長形式と省略形式があります。

オプションの省略形式では、ダッシュ 1 つ (-) の後に文字 1 つが続きます。
オプションの長形式では、ダッシュ 2 つ (--) の後にオプションのワードが続きます。

たとえば、terse 出力を指定するオプションの省略形式と長形式は次のとおりです。

省略形式: -t
長形式: --terse

論理型オプションを除く多くのオプションには、機能の有効と無効を切り替える引数の値が必要です。

`asadmin` ユーティリティーのサブコマンドのオペランド

オペランドは、サブコマンドの動作対象となる項目を指定します。オペランドは、サブコマンドオプションの引数の後に指定する必要があり、空白 1 文字、タブ 1 文字、またはダッシュ 2 文字 (--) で区切ります。asadmin ユーティリティーは、サブコマンドオプションとその値に続くものはすべて、オペランドとして扱います。

シングルモードで `asadmin` ユーティリティーのサブコマンドを実行する

シングルモードでは、使用するサブコマンドについて個々に asadmin コマンドを入力する必要があります。サブコマンドの実行後は、オペレーティングシステムのコマンドシェルに戻ります。asadmin ユーティリティーのオプションは、実行する asadmin コマンドについて個々に指定する必要があります。複数のサブコマンドについて同じ asadmin ユーティリティーのオプションが必要な場合は、マルチモードで asadmin ユーティリティーを使用します。詳細については、「マルチモードセッションを開始する」を参照してください。

オペレーティングシステムのコマンドシェルで、asadmin ユーティリティーを実行してサブコマンドを指定します。

必要に応じて、必須の asadmin ユーティリティーのオプション、サブコマンドのオプション、およびオペランドも指定します。

例 2–1 シングルモードでの `asadmin` ユーティリティーのサブコマンド実行

この例は、シングルモードでサブコマンド list-applications(1) を実行します。この例では、すべてのオプションでデフォルト値を使用します。

この例は、ローカルホストでアプリケーション hello が配備されていることを示します。

asadmin list-applications
hello <web>

Command list-applications executed successfully.

例 2–2 シングルモードでの `asadmin` ユーティリティーオプションとサブコマンドの指定

この例は、シングルモードで asadmin ユーティリティーのオプション --host とサブコマンド list-applications を指定します。この例では、DAS はホスト srvr1.example.com で稼働中です。

この例は、アプリケーション basic-ezcomp、scrumtoys、ejb31-war、および automatic-timer-ejb がホスト srvr1.example.com に配備されていることを示します。

asadmin --host srvr1.example.com list-applications
basic-ezcomp <web>
scrumtoys <web>
ejb31-war <ejb, web>
automatic-timer-ejb <ejb>

Command list-applications executed successfully.

例 2–3 シングルモードでの `asadmin` ユーティリティーオプションとサブコマンドオプションの指定

この例は、シングルモードで asadmin ユーティリティーオプション --host、サブコマンドオプション --type、およびサブコマンド list-applications を指定します。この例では、DAS がホスト srvr1.example.com で稼働し、web タイプのアプリケーションが一覧表示されます。

asadmin --host srvr1.example.com list-applications --type web
basic-ezcomp <web>
scrumtoys <web>
ejb31-war <ejb, web>

Command list-applications executed successfully.

`asadmin` ユーティリティーまたはサブコマンドのヘルプ情報を表示する

Enterprise Server には、asadmin ユーティリティーとそのサブコマンドの構文、目的、およびオプションに関するヘルプ情報が用意されています。このヘルプ情報は、UNIX® プラットフォームのマニュアルページのスタイルで作成されています。このヘルプ情報は、『Sun GlassFish Enterprise Server v3 Reference Manual』にも記載されています。

リモートサブコマンドのヘルプ情報を表示する場合は、サーバーが稼働中であることを確認してください。

リモートサブコマンドを実行するには、稼働中のサーバーが必要です。

対象のサブコマンドを、help サブコマンドのオペランドとして指定します。

オペランドを指定せずに help サブコマンドを実行した場合、asadmin ユーティリティーのヘルプ情報が表示されます。

例 2–4 `asadmin` ユーティリティーのヘルプ情報の表示

この例は、asadmin ユーティリティーのヘルプ情報を表示します。

asadmin help

例 2–5 `asadmin` ユーティリティーサブコマンドのヘルプ情報表示

この例は、サブコマンド create-jdbc-resource のヘルプ情報を表示します。

asadmin help create-jdbc-resource

参照

使用できるサブコマンドを表示するには、サブコマンド list-commands(1) を使用します。ローカルサブコマンドが、リモートサブコマンドの前に表示されます。サーバーが稼働していない場合は、ローカルサブコマンドのみが表示されます。

マルチモードセッションを開始する

asadmin ユーティリティーは、複数コマンドモード、つまりマルチモードで使用できます。マルチモードでは、asadmin ユーティリティーを一度実行してマルチモードセッションを開始します。セッションを終了してオペレーティングシステムのコマンドシェルに戻るまでの間、asadmin ユーティリティーは継続してサブコマンドを受け取ります。マルチモードセッションで設定した asadmin ユーティリティーのオプションは、セッションの後続のサブコマンドすべてについて使用されます。

注 –

マルチモードセッションを開始するには、稼働中の DAS は「不要」です。

次のいずれかの操作を行います。
- サブコマンドを指定せずに asadmin ユーティリティーを実行します。
- サブコマンド multimode(1) を使用します。
必要に応じて、マルチモードセッション全体に適用する asadmin ユーティリティーのオプションも指定します。

マルチモードセッションでは、コマンド行に asadmin> プロンプトが表示されます。このプロンプトに asadmin のサブコマンドを入力して Enterprise Server を管理できます。

例 2–6 `asadmin` ユーティリティーオプションによるマルチモードセッション開始

この例は、マルチモードセッションを開始し、asadmin ユーティリティーのオプション --user および --passwordfile をこのセッションに設定します。

asadmin --user admin1 --passwordfile pwd.txt multimode

例 2–7 サブコマンド `multimode` によるマルチモードセッションの開始

この例は、サブコマンド multimode を使用して、デフォルトの asadmin ユーティリティーのオプションを使用するマルチモードセッションを開始します。

asadmin multimode

コマンド行に asadmin> プロンプトが表示されます。

例 2–8 マルチモードセッションでのサブコマンドの実行

この例は、マルチモードセッションを開始し、そのセッションでサブコマンド list-domains を実行します。

asadmin
Enter commands one per "line", ^D to quit
asadmin> list-domains
Name: domain1 Status: Running
Command list-domains executed successfully.
asadmin>

既存のマルチモードセッションからのマルチモードセッション開始

既存のセッションからマルチモードセッションを開始するには、既存のセッションからサブコマンド multimode を実行します。2 つ目のマルチモードセッションを終了すると、元のマルチモードセッションに戻ります。

参照

また、コマンド行に asadmin help multimode を入力して、サブコマンドの詳細構文とオプションも表示できます。

マルチモードセッションを終了する

asadmin> プロンプトに、次のコマンドまたはキーコンビネーションのいずれかを入力します。
- exit
- quit
- UNIX および Linux システム: Ctrl-D
- Windows システム: Ctrl-Z
オペレーティングシステムのコマンドシェルに戻ります。asadmin> プロンプトは表示されなくなります。asadmin> プロンプトがまだ表示されている場合は、マルチモードセッションからマルチモードセッションを開いた可能性があります。この場合は、この手順を繰り返して残りのマルチモードセッションを終了します。

ファイルから `asadmin` の一連のサブコマンドを実行する

ファイルから asadmin の一連のサブコマンドを実行すると、繰り返し実行するタスクを自動化できます。

実行するサブコマンドのシーケンスを含むプレーンテキストファイルを作成します。

作成したファイルを指定して、サブコマンド multimode(1) を実行します。

必要に応じて、ファイル内のサブコマンドを実行可能にするために必要な asadmin ユーティリティーのオプションも指定します。

例 2–9 ファイルからの `asadmin` の一連のサブコマンドの実行

この例には、次のものが含まれます。

asadmin のサブコマンドのシーケンスを含む、名前が commands_file.txt のファイルリスト
ファイル commands_file.txt 内のサブコマンドを実行するためのコマンド

commands_file.txt ファイルには、次の動作シーケンスを実行するための asadmin ユーティリティーのサブコマンドがあります。

ドメイン customdomain の作成
ドメイン customdomain の開始
使用できるすべてのサブコマンドの一覧表示
ドメイン customdomain の停止
ドメイン customdomain の削除

ファイル commands_file.txt の内容は次のとおりです。

create-domain --portbase 9000 customdomain
start-domain customdomain
list-commands
stop-domain customdomain
delete-domain customdomain

この例は、commands_file.txt ファイル内のサブコマンドのシーケンスを実行します。ファイル内のサブコマンド create-domain にオプション --portbase が指定されているので、asadmin ユーティリティーのオプション --port も設定する必要があります。

asadmin --port 9048 multimode --file commands_file.txt

参照

上の例のサブコマンドの詳細については、次のマニュアルページを参照してください。

システムプロパティーの管理

共有サーバーインスタンスでは、参照される構成に定義された属性の上書きが頻繁に必要になります。任意の構成の属性を、対応する名前のシステムプロパティーによって上書きできます。

ここでは、次のテーマを取り上げます。

システムプロパティーを作成する

ドメインまたは構成の 1 つ以上のシステムプロパティーの作成または更新を行うには、リモートモードでサブコマンド create-system-properties を使用します。任意の構成の属性を、対応する名前のシステムプロパティーによって上書きできます。

サーバーが稼働中であることを確認してください。

リモートサブコマンドには、実行中のサーバーが必要です。

create-system-properties(1) サブコマンドを使用して、システムプロパティーを作成します。

サブコマンドのプロパティーに関する情報が、このマニュアルページにあります。

例 2–10 システムプロパティーの作成

この例は、localhost の http-listener-port=1088 に関するシステムプロパティーを作成します。

asadmin> create-system-properties http-listener-port=1088
Command create-system-properties executed successfully.

参照

コマンド行に asadmin help create-system-properties と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

システムプロパティーを一覧表示する

ドメインまたは構成に適用するシステムプロパティーを一覧表示するには、リモートモードで list-system-properties サブコマンドを使用します。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-system-properties(1) サブコマンドを使用して、システムプロパティーを一覧表示します。

HTTP_LISTENER_PORT や HTTP_SSL_LISTENER_PORT などの事前定義プロパティーを含む、既存のシステムプロパティーが表示されます。

例 2–11 システムプロパティーの一覧表示

この例は、ホスト localhost のシステムプロパティーを一覧表示します。

asadmin> list-system-properties
http-listener-port=1088
Command list-system-properties executed successfully.

参照

コマンド行に asadmin help list-system-properties と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

システムプロパティーを削除する

システムプロパティーを削除するには、リモートモードで delete-system-property サブコマンドを使用します。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-system-properties(1) サブコマンドを使用して、既存のシステムプロパティーを一覧表示します。

delete-system-property(1) サブコマンドを使用して、システムプロパティーを削除します。

必要に応じて、システムプロパティーが削除されたことをユーザーに通知します。

例 2–12 システムプロパティーの削除

この例は、localhost から http-listener-port という名前のシステムプロパティーを削除します。

asadmin> delete-system-property http-listener-port
Command delete-system-property executed successfully.

参照

コマンド行に asadmin help delete-system-property と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

リソースの管理

この節では、Enterprise Server 環境にリソースを統合する方法を説明します。JDBC のような特定リソースの管理に関する情報は、他の章に記載されています。

ここでは、次のテーマを取り上げます。

「XML ファイルからリソースを追加する」

XML ファイルからリソースを追加する

指定の XML ファイル内に名前が指定されているリソースを作成するには、リモートモードで add-resources サブコマンドを使用します。サポートするリソースは、JDBC 接続プールおよびリソース、JMS、JNDI、および JavaMail のリソース、カスタムリソース、コネクタリソースおよび作業セキュリティーマップ、admin オブジェクト、およびリソースアダプタの構成です。

XML ファイルは、as-install/domains/domain1/config ディレクトリに配置される必要があります。相対パスを指定した場合、または単に XML ファイルの名前を指定した場合は、このサブコマンドのオペランドの前に as-install/domains/domain1/config が付けられます。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

add-resources(1) サブコマンドを使用して、XML ファイルからリソースを追加します。

このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

Enterprise Serverを再起動します。

「ドメインの再起動」を参照してください。

例 2–13 リソースの追加

この例は、localhost の resource.xml の内容を使用して、リソースを作成します。

asadmin> add-resources c:\tmp\resource.xml
Command : JDBC resource jdbc1 created successfully.
Command : JDBC connection pool poolA created successfully.
Command add-resources executed successfully.

参照

コマンド行に asadmin help add-resources と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

さまざまなシステム要素の一覧表示

Enterprise Server のバージョンを表示する

特定サーバーの Enterprise Server のバージョンに関する情報を表示するには、リモートモードで version サブコマンドを使用します。指定のログイン (ユーザーとパスワード) およびターゲット (ホストとポート) の情報を使用してサブコマンドがサーバーと通信できない場合は、ローカルバージョンと警告メッセージが表示されます

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

version(1) サブコマンドを使用してバージョンを表示します。

例 2–14 バージョン情報の表示

この例では、ローカルホストの Enterprise Server のバージョンを表示します。

asadmin> version
Version = GlassFish v3
Command version executed successfully.

参照

コマンド行に asadmin help version と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

アプリケーションを一覧表示する

配備した Java^TM アプリケーションを一覧表示するには、リモートモードで list-applications サブコマンドを使用します。--type オプションを指定しない場合は、すべてのアプリケーションが一覧表示されます。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-applications(1) サブコマンドを使用して、アプリケーションを一覧表示します。

例 2–15 アプリケーションの一覧表示

この例では、localhost の Web アプリケーションを一覧表示します。

asadmin> list-applications --type web
hellojsp <web>
Command list-applications executed successfully.

参照

コマンド行に asadmin help list-applications と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

コンテナを一覧表示する

アプリケーションコンテナを一覧表示するには、リモートモードで list-containers サブコマンドを使用します。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-containers(1) サブコマンドを使用して、コンテナを一覧表示します。

例 2–16 コンテナの一覧表示

この例は、localhost のコンテナを一覧表示します。

asadmin> list-containers
List all known application containers
Container : grizzly
Container : ejb
Container : webservices
Container : ear
Container : appclient
Container : connector
Container : jpa
Container : web
Container : jruby
Container : security
Container : webbeans
Command list-containers executed successfully.

参照

コマンド行に asadmin help list-containers と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

モジュールを一覧表示する

Enterprise Server のモジュールサブシステムにアクセスできるモジュールを一覧表示するには、リモートモードで list-modules サブコマンドを使用します。各モジュールの状態が含まれます。表示される状態には、NEW と READY があります。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-modules(1) サブコマンドを使用して、モジュールを一覧表示します。

例 2–17 モジュールの一覧表示

この例はアクセス可能なモジュールを一覧表示します。

asadmin> list-modules

次のような情報が表示されます (出力の一部を示す)。

List Of Modules
Module : org.glassfish.web.jstl-connector:10.0.0.b28
    properties=(visibility=public,State=READY,Sticky=true)
    Module Characteristics : List of Jars implementing the module
        Jar : file:/C:/Preview/v3_Preview_release/distributions/web/target/glass
fish/modules/web/jstl-connector.jar
    Module Characteristics : List of imported modules
    Module Characteristics : Provides to following services
Module : org.glassfish.admingui.console-common:10.0.0.b28
    properties=(visibility=public,State=NEW,Sticky=true)
Module : org.glassfish.admin.launcher:10.0.0.b28
    properties=(visibility=public,State=NEW,Sticky=true)
Module : org.glassfish.external.commons-codec-repackaged:10.0.0.b28
    properties=(visibility=public,State=NEW,Sticky=true)
Module : com.sun.enterprise.tiger-types-osgi:0.3.32.Preview-b28
    properties=(visibility=public,State=READY,Sticky=true)
    Module Characteristics : List of imported modules
    Module Characteristics : Provides to following services
    Module Characteristics : List of Jars implementing the module
        Jar : file:/C:/Preview/v3_Preview_release/distributions/web/target/glass
fish/modules/tiger-types-osgi.jar.
.
.
.
Command list-modules executed successfully.

参照

コマンド行に asadmin help list-modules と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

サブコマンドを一覧表示する

配備した asadmin のサブコマンドを一覧表示するには、リモートモードで list-commands サブコマンドを使用します。リモートサブコマンドのみ、またはローカルサブコマンドのみを一覧表示するように指定できます。このサブコマンドのデフォルトでは、ローカルサブコマンドのリストの後にリモートサブコマンドのリストが表示されます。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-commands(1) サブコマンドを使用して、サブコマンドを一覧表示します。

例 2–18 サブコマンドの一覧表示

この例は、ローカルサブコマンドのみを一覧表示します。

asadmin> list-commands --localonly
create-domain
delete-domain
list-commands
list-domains
login
monitor
start-database
start-domain
stop-domain
stop-database
version
Command list-commands executed successfully.

参照

コマンド行に asadmin help list-commands と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

タイマーを一覧表示する

タイマーサービスは、エンタープライズ Bean コンテナによって提供され、エンタープライズ Bean が使用する通知やイベントのスケジュールに使用される、持続的なトランザクション通知サービスです。ステートフルセッション Beans 以外のエンタープライズ Beans はすべて、タイマーサービスからの通知を受信できます。このサービスによって設定された持続タイマーは、サーバーのシャットダウンや再起動では破棄されません。

指定のサーバーインスタンスが所有する持続タイマーを一覧表示するには、リモートモードで list-timers サブコマンドを使用します。この情報を使用して、タイマーを移行するかどうかの決定、または移行が正常に完了したかどうかの検証ができます。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-timers(1) サブコマンドを使用して、タイマーを一覧表示します。

例 2–19 タイマーの一覧表示

この例は、特定のスタンドアロンサーバーインスタンスのタイマーを一覧表示します。現在、アクティブなタイマーが 1 つ設定されています。

asadmin> list-timers server
1
The list-timers command was executed successfully.

コンポーネントの状態を表示する

指定した配備済みコンポーネントの状態 (有効または無効) を取得するには、リモートモードで show-component-status サブコマンドを使用します。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

show-component-status(1) サブコマンドを使用して、コンポーネントの状態を表示します。

例 2–20 コンポーネントの状態の表示

この例は、MEjbApp コンポーネントの状態を表示します。

asadmin> show-component-status MEjbApp
Status of MEjbApp is enabled
Command show-component-status executed successfully.

REST インタフェースによる Enterprise Server の管理

Enterprise Server は、新規にインストールされたアドオンコンポーネントが提供するデータなど、Enterprise Server の監視データや構成データにアクセスできる表現状態転送 (REST) インタフェースを装備しています。

Enterprise Server の REST インタフェースには、次のようなクライアントアプリケーションからアクセスできます。

Web ブラウザ
cURL
GNU Wget

また、Enterprise Server の REST インタフェースは、次のような言語で開発された REST クライアントアプリケーションでも使用できます。

JavaScript
Ruby
Perl
Java
JavaFX

Enterprise Server の REST インタフェースの実装は、project Jersey をベースにしています。Project Jersey は、Java ^TM 仕様要求 (JSR) 311: JAX-RS、RESTful Web サービス用 Java API の参照実装です。JSR 311 に関する情報は、JSR 311 プロジェクトのホームページにも記載されています。

ここでは、次のテーマを取り上げます。

REST URL による Enterprise Server の管理

構成および監視のオブジェクトツリーの各ノードは、HTTP uniform resource locator (URL) からアクセスできる REST リソースとして表現されます。Enterprise Server の監視データや構成データの REST リソースにアクセスするには、稼働中の DAS が必要です。

構成および監視のオブジェクトツリーのノードを表現するリソースの URL の形式は、次のとおりです。

構成: http:// host:port/management/domain/ path
監視: http:// host:port/monitoring/domain/ path

これらの URL で置き換え可能な項目は次のとおりです。

host

DAS が稼働中のホスト

port

管理用の HTTP ポートまたは HTTPS ポート

path

ノードへのパス。パスはノードのドット表記名で、各ドット (.) がスラッシュ (/) に置換されます。詳細については次のドキュメントを参照してください。

Enterprise Server の監視データまたは構成データについて、REST リソースの URL を Web ブラウザで開いた場合、ブラウザには、リソースの次の情報を含む Web ページが表示されます。

リソースの属性とその値のリストリソースが構成ツリーのノードを表現している場合は、それらの属性は、リソースの更新に使用できる HTML 形式で表示されます。監視ツリーにあるノードのリソースの属性は、読み取り専用です。
リソースの子を示すハイパーテキストリンクのリストこのリンクのリストを使用して、リソースを含むツリー内を移動して、ツリー内のすべてのリソースを検出できます。

次の図に、ドメインを管理する REST リソースの Web ページを示します。

図 2–1 ドメインを管理する REST リソースの Web ページ

ドメインを管理する REST リソースの Web ページを示すスクリーンショット

REST リソースメソッドによる Enterprise Server の管理

Enterprise Server の REST インタフェースは、監視および構成のオブジェクトツリーのノードにアクセスする方法をサポートしています。

次の表に、監視データや構成データを管理する REST メソッド、および各メソッドで実行できるタスクを示します。これらのメソッドは、HTTP 1.1 プリミティブです。これらのプリミティブの詳細仕様については、Hypertext Transfer Protocol -- HTTP/1.1 を参照してください。

表 2–1 監視データと構成データを管理する REST リソースメソッド


作業	REST メソッド
ツリー内のノードがサポートするメソッドおよびメソッドパラメータの判定	`OPTIONS` または `GET`
ツリー内のノードのデータ取得	`GET`
ツリーへのノードの追加	`POST`
ツリー内のノードの更新	`POST`
ツリーからのノードの削除	`DELETE`

注 –

GET メソッドを OPTIONS メソッドの代わりに使用して、ツリー内のノードがサポートするメソッドおよびメソッドパラメータを判定することができます。GET メソッドは、ノードの追加情報も表示します。詳細については、「ツリー内のノードのデータを取得する」を参照してください。

ツリー内のノードがサポートするメソッドおよびメソッドパラメータを判定する

ツリー内のノードがサポートするメソッドおよびメソッドパラメータは、ノードを表す REST リソースによって決まります。

監視用の REST リソースは、GET メソッドのみをサポートします。
構成用の REST リソースはすべて、GET メソッドおよび OPTIONS メソッドをサポートします。ただし、構成用の一部の REST リソースは、POST メソッドと DELETE メソッドもサポートします。

ツリーのノードで操作を実行する前に、そのノードがサポートするメソッドおよびメソッドパラメータを判定します。

この情報の表示形式を指定できます。詳細については、「リソースの表現形式」を参照してください。

サーバーが実行されていることを確認します。

Enterprise Server のデータについて、REST リソースを操作するには、稼働中のサーバーが必要です。

ノードを表す REST リソースに対して、適切なメソッドを使用します。
- 監視オブジェクトツリーのノードの場合は、GET メソッドを使用します。
- 構成オブジェクトツリーのノードの場合は、 OPTIONS メソッドまたは GET メソッドを使用します。
GET メソッドと OPTIONS メソッドは、リソースがサポートするメソッドのリストを返します。各メソッドについて、使用できるメッセージパラメータのリスト、または使用できるクエリーパラメータのリストが返されます。

例 2–21 ツリー内のノードがサポートするメソッドおよびメソッドパラメータの判定

この例は、cURL ユーティリティーを使用して、ドメインのリソースがサポートするメソッドおよびメソッドパラメータを判定します。この例は、cURL ユーティリティーの次に示すオプションを使用します。

-X: OPTIONS メソッドを使用していることを示します
-H: リソースが JavaScript Object Notation (JSON) で記述されていることを示します

この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。OPTIONS メソッドに加えて、このリソースは POST メソッドと GET メソッドをサポートしています。

curl -X OPTIONS -H "Accept: application/json" http://localhost:4848/management/domain
{"Domain":
  {
    "Method":{
      "Name":"POST",
      "Message Parameters":{
        "log-root":{"Key":"false", "Type":"string", "Optional":"true"},
        "application-root":{"Key":"false", "Type":"string", "Optional":"true"},
        "locale":{"Key":"false", "Type":"string", "Optional":"true"},
        "version":{"Key":"false", "Type":"string", "Optional":"true"}
      }
    },
    "Method":{
      "Name":"GET"
    }
  }
}

ツリー内のノードのデータを取得する

ツリー内のノードのデータを取得すると、そのノードを表す REST リソースに関する次の情報が得られます。

リソースがサポートする REST メソッドのリスト
リソースの属性とその値のリスト
リソースの子の URL のリスト

この情報の表示形式を指定できます。詳細については、「リソースの表現形式」を参照してください。

サーバーが実行されていることを確認します。

Enterprise Server のデータについて、REST リソースを操作するには、稼働中のサーバーが必要です。

ノードを表す REST リソースに対して、GET メソッドを使用します。

例 2–22 ツリー内のノードのデータの取得

この例は、cURL ユーティリティーを使用して、ドメインのリソースデータを取得します。この例は、cURL ユーティリティーの次に示すオプションを使用します。

-X: GET メソッドを使用していることを示します
-H: リソースが JavaScript Object Notation (JSON) で記述されていることを示します

この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。

改行は読みやすくするためです。

curl -X GET -H "Accept: application/json" http://localhost:4848/management/domain
{

  "Domain":{"log-root":"${com.sun.aas.instanceRoot}/logs", 
"application-root":"${com.sun.aas.instanceRoot}/applications", 
"locale":"", "version":"74.1"},

  "Methods":{
    "Method":{
      "Name":"POST",
      "Message Parameters":{
        "log-root":{"Key":"false", "Type":"string", "Optional":"true"},
        "application-root":{"Key":"false", "Type":"string", "Optional":"true"},
        "locale":{"Key":"false", "Type":"string", "Optional":"true"},
        "version":{"Key":"false", "Type":"string", "Optional":"true"}
      }
    },
    "Method":{
      "Name":"GET"
    }
  },

  "Child Resources":[
    "http://localhost:4848/management/domain/configs",
    "http://localhost:4848/management/domain/resources",
    "http://localhost:4848/management/domain/servers",
    "http://localhost:4848/management/domain/property",
    "http://localhost:4848/management/domain/applications",
    "http://localhost:4848/management/domain/system-applications",
    "http://localhost:4848/management/domain/stop",
    "http://localhost:4848/management/domain/restart",
    "http://localhost:4848/management/domain/uptime",
    "http://localhost:4848/management/domain/version",
    "http://localhost:4848/management/domain/rotate-log",
    "http://localhost:4848/management/domain/host-port"
  ]

ツリーにノードを追加する

サーバーが実行されていることを確認します。

Enterprise Server のデータについて、REST リソースを操作するには、稼働中のサーバーが必要です。

ノードの親を表すリソースの POST メソッドについて、使用できるメッセージパラメータを調べます。

この手順の実行方法については、「ツリー内のノードがサポートするメソッドおよびメソッドパラメータを判定する」を参照してください。

追加するノードの親を表す REST リソースに対して、POST メソッドを使用します。

ノードが追加されたことを確認します。

追加したノード (親ではない) を表すリソースに対してこの手順を実行します。この手順の実行方法については、「ツリー内のノードのデータを取得する」を参照してください。

例 2–23 ツリーへのノードの追加

この例は、cURL ユーティリティーを使用して、JDBC リソースを表す REST リソースを作成することにより、ツリーに JDBC リソースを追加します。

この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。

改行は読みやすくするためです。

この手順は、リソース jdbc-resource の POST メソッドに使用できるメッセージパラメータを調べます。

curl -X OPTIONS -H "Accept: application/json" 
http://localhost:4848/management/domain/resources/jdbc-resource
{"JdbcResource":
  {
    "Method":{
      "Name":"POST",
      "Message Parameters":{
        "id":{"Acceptable Values":"", "Default Value":"", "Type":"string", 
            "Optional":"false"},
        "enabled":{"Acceptable Values":"", "Default Value":"true", 
            "Type":"boolean", "Optional":"true"},
        "description":{"Acceptable Values":"", "Default Value":"", 
            "Type":"string", "Optional":"true"},
        "target":{"Acceptable Values":"", "Default Value":"", "Type":"string", 
            "Optional":"true"},
        "property":{"Acceptable Values":"", "Default Value":"", 
            "Type":"string", "Optional":"true"},
        "connectionpoolid":{"Acceptable Values":"", "Default Value":"", 
            "Type":"string", "Optional":"false"}
      }
    },
    "Method":{
      "Name":"GET"
    }
  }
}

この手順は、jdbc-resource リソースの子としてリソースを追加します。cURL ユーティリティーのオプション -d は、必要なメッセージパラメータを次のように設定します。

id が jdbc/myjdbcresource に設定されます。
connectionpoolid が DerbyPool に設定されます。

curl -X POST -d "id=jdbc/myjdbcresource&connectionpoolid=DerbyPool" 
http://localhost:4848/management/domain/resources/jdbc-resource
"http://localhost:4848/management/domain/resources/jdbc-resource/
jdbc/myjdbcresource" created successfully.

この手順は、ノードを表す REST リソースのデータを取得することにより、ノードが追加されたことを確認します。

curl -X GET -H "Accept: application/json" 
http://localhost:4848/management/domain/resources/
jdbc-resource/jdbc-myjdbcresource
{

  "JdbcMyjdbcresource":{"enabled":"true", "pool-name":"DerbyPool", 
      "description":"", "jndi-name":"jdbc/myjdbcresource", "object-type":"user"},

  "Methods":{
    "Method":{
      "Name":"POST",
      "Message Parameters":{
        "enabled":{"Key":"false", "Default Value":"true", 
            "Type":"boolean", "Optional":"true"},
        "pool-name":{"Key":"false", "Type":"string", "Optional":"true"},
        "description":{"Key":"false", "Type":"string", "Optional":"true"},
        "jndi-name":{"Key":"true", "Type":"string", "Optional":"true"},
        "object-type":{"Key":"false", "Default Value":"user", 
            "Type":"string", "Optional":"true"}
      }
    },
    "Method":{
      "Name":"GET"
    },
    "Method":{
      "Name":"DELETE",
      "Message Parameters":{
        "target":{"Acceptable Values":"", "Default Value":"", 
            "Type":"string", "Optional":"true"}
      }
    }
  }

}

ツリー内のノードを更新する

サーバーが実行されていることを確認します。

Enterprise Server のデータについて、REST リソースを操作するには、稼働中のサーバーが必要です。

ノードを表すリソースの POST メソッドについて、使用できるメッセージパラメータを判定します。

この手順の実行方法については、「ツリー内のノードがサポートするメソッドおよびメソッドパラメータを判定する」を参照してください。

更新するノードを表す REST リソースに対して、POST メソッドを使用します。

ノードが更新されたことを確認します。

この手順の実行方法については、「ツリー内のノードのデータを取得する」を参照してください。

例 2–24 ツリー内のノードの更新

この例は、cURL ユーティリティーを使用して、JDBC リソースを表す REST リソースを変更することにより、ツリーの JDBC リソースを更新します。

この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。

改行は読みやすくするためです。

この手順は、リソース jdbc-myjdbcresource の POST メソッドに使用できるメッセージパラメータを調べます。

curl -X OPTIONS -H "Accept: application/json" 
http://localhost:4848/management/domain/resources/
jdbc-resource/jdbc-myjdbcresource
{"JdbcMyjdbcresource":
  {
    "Method":{
      "Name":"POST",
      "Message Parameters":{
        "enabled":{"Key":"false", "Default Value":"true", 
            "Type":"boolean", "Optional":"true"},
        "pool-name":{"Key":"false", "Type":"string", "Optional":"true"},
        "description":{"Key":"false", "Type":"string", "Optional":"true"},
        "jndi-name":{"Key":"true", "Type":"string", "Optional":"true"},
        "object-type":{"Key":"false", "Default Value":"user", 
            "Type":"string", "Optional":"true"}
      }
    },
    "Method":{
      "Name":"GET"
    },
    "Method":{
      "Name":"DELETE",
      "Message Parameters":{
        "target":{"Acceptable Values":"", "Default Value":"", 
            "Type":"string", "Optional":"true"}
      }
    }
  }
}

この手順は、jdbc-myjdbcresource が表す JDBC リソースを無効にするように、REST リソース jdbc-myjdbcresource を更新します。cURL ユーティリティーのオプション -d は、メッセージパラメータ enabled を disabled に設定します。

curl -X POST -d "enabled=false" 
http://localhost:4848/management/domain/resources/
jdbc-resource/jdbc-myjdbcresource
"http://localhost:4848/management/domain/resources/jdbc-resource/
jdbc-myjdbcresource" updated successfully.

この手順は、ノードを表す REST リソースのデータを取得することにより、ノードが更新されたことを確認します。

curl -X GET -H "Accept: application/json" 
http://localhost:4848/management/domain/resources/
jdbc-resource/jdbc-myjdbcresource
{

  "JdbcMyjdbcresource":{"enabled":"false", "pool-name":"DerbyPool", 
       "description":"", "jndi-name":"jdbc/myjdbcresource", "object-type":"user"},

  "Methods":{
    "Method":{
      "Name":"POST",
      "Message Parameters":{
        "enabled":{"Key":"false", "Default Value":"true", 
            "Type":"boolean", "Optional":"true"},
        "pool-name":{"Key":"false", "Type":"string", "Optional":"true"},
        "description":{"Key":"false", "Type":"string", "Optional":"true"},
        "jndi-name":{"Key":"true", "Type":"string", "Optional":"true"},
        "object-type":{"Key":"false", "Default Value":"user", 
            "Type":"string", "Optional":"true"}
      }
    },
    "Method":{
      "Name":"GET"
    },
    "Method":{
      "Name":"DELETE",
      "Message Parameters":{
        "target":{"Acceptable Values":"", "Default Value":"", 
            "Type":"string", "Optional":"true"}
      }
    }
  }

}

ツリーからノードを削除する

サーバーが実行されていることを確認します。

Enterprise Server のデータについて、REST リソースを操作するには、稼働中のサーバーが必要です。

ノードが削除できることを確認します。

この手順の実行方法については、「ツリー内のノードがサポートするメソッドおよびメソッドパラメータを判定する」を参照してください。

ノードが削除されたことを確認します。

削除したノードを表すリソースに対してこの手順を実行します。この手順の実行方法については、「ツリー内のノードのデータを取得する」を参照してください。

例 2–25 ツリーからのノードの削除

この例は、cURL ユーティリティーを使用して、JDBC リソースを表す REST リソースを削除することにより、ツリーから JDBC リソースを削除します。

この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。

改行は読みやすくするためです。

この手順は、リソース jdbc-myjdbcresource がサポートする REST のメソッドを取得することにより、ノードが削除できることを確認します。

curl -X OPTIONS -H "Accept: application/json" 
http://localhost:4848/management/domain/resources/
jdbc-resource/jdbc-myjdbcresource
{"JdbcMyjdbcresource":
  {
    "Method":{
      "Name":"POST",
      "Message Parameters":{
        "enabled":{"Key":"false", "Default Value":"true", 
            "Type":"boolean", "Optional":"true"},
        "pool-name":{"Key":"false", "Type":"string", "Optional":"true"},
        "description":{"Key":"false", "Type":"string", "Optional":"true"},
        "jndi-name":{"Key":"true", "Type":"string", "Optional":"true"},
        "object-type":{"Key":"false", "Default Value":"user", 
            "Type":"string", "Optional":"true"}
      }
    },
    "Method":{
      "Name":"GET"
    },
    "Method":{
      "Name":"DELETE",
      "Message Parameters":{
        "target":{"Acceptable Values":"", "Default Value":"", 
            "Type":"string", "Optional":"true"}
      }
    }
  }
}

この手順は、リソース jdbc-myjdbcresource を削除します。

curl -X DELETE http://localhost:4848/management/domain/resources/
jdbc-resource/jdbc-myjdbcresource

この手順は、ノードの親を表す REST リソースのデータを取得することにより、ノードが削除されたことを確認します。

curl -X GET -H "Accept: application/json" 
http://localhost:4848/management/domain/resources/jdbc-resource/
{

  "JdbcResource":{},

  "Methods":{
    "Method":{
      "Name":"POST",
      "Message Parameters":{
        "id":{"Acceptable Values":"", "Default Value":"", "Type":"string", 
            "Optional":"false"},
        "enabled":{"Acceptable Values":"", "Default Value":"true", 
            "Type":"boolean", "Optional":"true"},
        "description":{"Acceptable Values":"", "Default Value":"", 
            "Type":"string", "Optional":"true"},
        "target":{"Acceptable Values":"", "Default Value":"", "Type":"string", 
            "Optional":"true"},
        "property":{"Acceptable Values":"", "Default Value":"", "Type":"string",
            "Optional":"true"},
        "connectionpoolid":{"Acceptable Values":"", "Default Value":"", 
            "Type":"string", "Optional":"false"}
      }
    },
    "Method":{
      "Name":"GET"
    }
  },

  "Child Resources":[
    "http://localhost:4848/management/domain/resources/jdbc-resource/
        jdbc-__TimerPool",
    "http://localhost:4848/management/domain/resources/jdbc-resource/
        jdbc-__default"
  ]

CRUD 以外の操作用の子リソース

Enterprise Server の REST インタフェースは次に示すように、作成、読み取り、更新、および削除 (CRUD) 以外の操作もサポートしています。

状態管理
クエリー
アプリケーション配備

これらの操作は、操作の実行対象リソースの子リソースを通じてサポートされます。子リソースは、構成オブジェクトツリーのノードを表しません。

たとえば、ドメイン管理用リソースは、次の表に示す CRUD 以外の操作用の子リソースを提供します。

表 2–2 ドメインでの CRUD 以外の操作用の子リソース


リソース	アクション
`host-port`	DAS が稼働中のホスト、および DAS が HTTP 要求を待機するポートを表示します。
`restart`	ドメインの DAS を停止し、その後再起動します。
`rotate-log`	タイムスタンプ名を持つファイルを `server.log_date-and-time` の形式の名前に変更し、空のログを作成することにより、サーバーログファイルをローテーションします。
`stop`	ドメインの DAS を停止します。
`uptime`	DAS の最後の再起動後の動作時間を表示します。
`version`	Enterprise Server のバージョン情報を表示します。

REST インタフェースのセキュリティー保護

Enterprise Server の REST インタフェースは、セキュアな接続上での基本認証をサポートしています。セキュリティーを有効にしたときには、REST リソースの URL にプロトコルとして https を指定し、ユーザー名とパスワードを指定する必要があります。

Enterprise Server の REST インタフェースのセキュリティー保護では、次のタスクシーケンスが実行されます。

admin-realm ユーザーを asadmin ユーザーグループに追加
Secure Sockets Layer (SSL) を有効化

コマンド行からこれらのタスクを実行する方法については、次に示すドキュメントを参照してください。

管理コンソールを使用してこれらのタスクを実行する方法については、管理コンソールのオンラインヘルプから次に示すトピックを参照してください。

管理レルムにユーザーを追加する
プロトコルの SSL 設定を編集する

リソースの表現形式

Enterprise Server の REST インタフェースは、次に示す形式でリソースを表現します。

JSON
XML
HTML

リソースの表現を指定する方法は、Enterprise Server の REST インタフェースへのアクセス方法によって異なります。たとえば、cURL ユーティリティーを使用している場合は、オプション -H を使用して、次のようにリソースの表現を指定します。

JSON の場合は、-H "Accept: application/json" を指定します。
XML の場合は、-H "Accept: application/xml" を指定します。
HTML の場合は、オプション -H を省略します。

JSON リソースの表現

リソースの JSON 表現の一般的な形式は次のとおりです。

{
    "resource":{attributes},

    "Methods": {
        method-list
    }

    "Child Resources":[urls]
}

この形式の置き換え可能な項目は次のとおりです。

resource: リソース名。
attributes: コンマ (,) で区切られたゼロ以上の名前と値のペア。名前と値の各ペアは、"名前":値 として指定します。
method-list: リソースがサポートするメソッドを表現する、コンマ (,) で区切られた 1 つ以上のメタデータのセット。各メタデータセットの形式については、「メソッドリストのメソッドの JSON 表現」を参照してください。
urls: コンマ (,) で区切られたゼロ以上の子リソースの URL。

メソッドリストのメソッドの JSON 表現

メソッドリストのメソッドの JSON 表現は、次のとおりです。

Method":{
    "Name":"method-name",

    "Message Parameters":{
        message-parameter-list
    }

    "Query Parameters":{
        queryparameter- list
    }
}

この形式の置き換え可能な項目は次のとおりです。

method-name: GET、POST、DELETE のいずれかのメソッド名。
message-parameter-list: メソッドで使用できるメッセージパラメータを表す、コンマ (,) で区切られたゼロ以上のメタデータのセット。各メタデータセットの形式については、「メッセージパラメータまたはクエリーパラメータの JSON 表現」.を参照してください。
query-parameter-list: メソッドで使用できるクエリーパラメータを表す、コンマ (,) で区切られたゼロ以上のメタデータのセット。各メタデータセットの形式については、「メッセージパラメータまたはクエリーパラメータの JSON 表現」.を参照してください。

メッセージパラメータまたはクエリーパラメータの JSON 表現

メッセージパラメータまたはクエリーパラメータの JSON 表現は、次のとおりです。

"parameter-name":{attribute-list}

この形式の置き換え可能な項目は次のとおりです。

parameter-name

パラメータ名。

attribute-list

コンマで区切られた、パラメータの属性の名前と値のペアのリスト。各ペアの形式は次のとおりです。

"name":"value"

使用できる属性は次のとおりです。

Default Value

パラメータのデフォルト値。

Acceptable Values

パラメータに使用できる値のセットまたは範囲。

Type

パラメータのデータ型。次のいずれかです。

boolean
int
string

Optional

パラメータが省略可能かどうか。true の場合、パラメータは省略可能です。false の場合、パラメータは必須です。

Key

パラメータがキーかどうか。true の場合、パラメータはキーです。false の場合、パラメータはキーではありません。

JSON リソースの表現例

この例は、ドメイン管理用リソースの JSON 表現を示します。この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。この例のリソースの URL は、http://localhost:4848/management/domain です。

改行は読みやすくするためです。

{

  "Domain":{"log-root":"${com.sun.aas.instanceRoot}/logs", 
       "application-root":"${com.sun.aas.instanceRoot}/applications", 
       "locale":"", "version":"73"},

  "Methods":{
    "Method":{
      "Name":"POST",
      "Message Parameters":{
        "log-root":{"Key":"false", "Type":"string", "Optional":"true"},
        "application-root":{"Key":"false", "Type":"string", "Optional":"true"},
        "locale":{"Key":"false", "Type":"string", "Optional":"true"},
        "version":{"Key":"false", "Type":"string", "Optional":"true"}
      }
    },
    "Method":{
      "Name":"GET"
    }
  },

  "Child Resources":[
    "http://localhost:4848/management/domain/configs",
    "http://localhost:4848/management/domain/resources",
    "http://localhost:4848/management/domain/servers",
    "http://localhost:4848/management/domain/property",
    "http://localhost:4848/management/domain/applications",
    "http://localhost:4848/management/domain/system-applications",
    "http://localhost:4848/management/domain/stop",
    "http://localhost:4848/management/domain/restart",
    "http://localhost:4848/management/domain/uptime",
    "http://localhost:4848/management/domain/version",
    "http://localhost:4848/management/domain/rotate-log",
    "http://localhost:4848/management/domain/host-port"
  ]

}

XML リソースの表現

リソースの XML 表現の一般的な形式は次のとおりです。

<resource attributes>

    <Methods>
        method-list
    </Methods>
children
</type>

この形式の置き換え可能な項目は次のとおりです。

resource: リソース名。
attributes: 空白文字 1 つで区切られたゼロ以上の名前と値のペア。名前と値の各ペアは名前="値"として指定します。
method-list: リソースがサポートするメソッドを表現する、1 つ以上の XML 要素。各要素の形式については、「リソースメソッドの XML 表現」を参照してください。
children: 子リソースの URL を指定するゼロ以上の XML 要素。各要素は、<child-resource> url</child-resource> として指定します。child-resource は子リソースの名前、url は子リソースの URL です。

リソースメソッドの XML 表現

メソッドリストのメソッドの XML 表現は、次のとおりです。

<Method name="method-name">
    <Message-Parameters>
        message-parameter-list
    </Message-Parameters>
    <Query-Parameters>
        query-parameter-list
    </Query-Parameters>
</Method>

この形式の置き換え可能な項目は次のとおりです。

method-name: GET、POST、DELETE のいずれかのメソッド名。
message-parameter-list: メソッドで使用できるメッセージパラメータを表す、改行で区切られたゼロ以上の XML 要素。各要素の形式については、「メッセージパラメータまたはクエリーパラメータの XML 表現」を参照してください。
query-parameter-list: メソッドで使用できるクエリーパラメータを表す、改行で区切られたゼロ以上の XML 要素。各要素の形式については、「メッセージパラメータまたはクエリーパラメータの XML 表現」を参照してください。

メッセージパラメータまたはクエリーパラメータの XML 表現

メッセージパラメータまたはクエリーパラメータの XML 表現は、次のとおりです。

<parameter-name attribute-list/>

この形式の置き換え可能な項目は次のとおりです。

parameter-name

パラメータ名。

attribute-list

空白文字で区切られた、パラメータの属性の名前と値のペアのリスト。各ペアの形式は次のとおりです。

name="value"

使用できる属性は次のとおりです。

Default Value

パラメータのデフォルト値。

Acceptable Values

パラメータに使用できる値のセットまたは範囲。

Type

パラメータのデータ型。次のいずれかです。

boolean
int
string

Optional

パラメータが省略可能かどうか。true の場合、パラメータは省略可能です。false の場合、パラメータは必須です。

Key

パラメータがキーかどうか。true の場合、パラメータはキーです。false の場合、パラメータはキーではありません。

XML リソースの表現例

この例は、ドメイン管理用リソースの XML 表現を示します。この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。この例のリソースの URL は、http://localhost:4848/management/domain です。

改行は読みやすくするためです。

<Domain log-root="${com.sun.aas.instanceRoot}/logs" 
application-root="${com.sun.aas.instanceRoot}/applications" locale="" version="73">

  <Methods>
    <Method name="POST">
      <Message-Parameters>
        <log-root Key="false" Type="string" Optional="true"/>
        <application-root Key="false" Type="string" Optional="true"/>
        <locale Key="false" Type="string" Optional="true"/>
        <version Key="false" Type="string" Optional="true"/>
      </Message-Parameters>
    </Method>
    <Method name="GET">
    </Method>
  </Methods>

  <Child-Resources>
    <Child-Resource>http://localhost:4848/management/domain/configs</Child-Resource>
    <Child-Resource>http://localhost:4848/management/domain/resources</Child-Resource>
    <Child-Resource>http://localhost:4848/management/domain/servers</Child-Resource>
    <Child-Resource>http://localhost:4848/management/domain/property</Child-Resource>
    <Child-Resource>http://localhost:4848/management/domain/applications</Child-Resource>
    <Child-Resource>http://localhost:4848/management/domain/system-applications</Child-Resource>
    <Child-Resource>http://localhost:4848/management/domain/stop</Child-Resource>
    <Child-Resource>http://localhost:4848/management/domain/restart</Child-Resource>
    <Child-Resource>http://localhost:4848/management/domain/uptime</Child-Resource>
    <Child-Resource>http://localhost:4848/management/domain/version</Child-Resource>
    <Child-Resource>http://localhost:4848/management/domain/rotate-log</Child-Resource>
    <Child-Resource>http://localhost:4848/management/domain/host-port</Child-Resource>
  </Child-Resources>

</Domain>

HTML リソースの表現

リソースの HTML 表現の形式は Web ページであり、リソースに関して次の情報を提供します。

リソースの属性とその値のリスト
リソースがサポートするメソッドおよびメソッドパラメータのリスト各メソッドとそのパラメータは、HTML フォーム内の適切な型を持つフィールドとして表示されます。
リソースの子を示すハイパーテキストリンクのリスト

Web ページの例については、図 2–1 を参照してください。この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。この例のリソースの URL は、http://localhost:4848/management/domain です。

第 3 章ドメインの管理

この章では、asadmin コマンド行ユーティリティーを使用して Sun GlassFish^TM Enterprise Server v3 環境でドメインを管理する手順について説明します。

ここでは、以下のトピックに関して説明します。

本章で説明するタスクを管理コンソールから実行する手順については、管理コンソールオンラインヘルプを参照してください。

ドメイン (サーバー) の管理について

ドメインは同時に管理されるインスタンスのグループです。ドメインは、事前に設定されたランタイムをユーザーアプリケーションに提供します。管理上の境界線を設けることに加え、ドメインは基本的なセキュリティー構造を提供し、これによって別々の管理者がサーバーインスタンスの特定のグループを管理できます。サーバーインスタンスを個別のドメインにグループ化することにより、さまざまな組織や管理者が 1 つの Enterprise Server インストールを共有できます。ドメインには、固有の構成、ログファイル、およびアプリケーションの配備領域があり、これらはほかのドメインとは無関係です。1 つのドメインの構成が変更されても、ほかのドメインの構成は影響を受けません。

Enterprise Server インストーラにより、デフォルトの管理ドメイン ( domain1という名前) が作成されます。さらに、関連するドメイン管理サーバー (DAS) (server という名前) も作成されます。DAS は管理者を認証し、管理ツールからの要求を受け付け、ドメイン内のサーバーインスタンスと通信して要求を実行するように特別に指定されたインスタンスです。DAS はデフォルトサーバーと呼ばれることもあります。デフォルトサーバーと呼ばれる理由は、Enterprise Server のインストール時に作成される唯一のサーバーインスタンスで、配備に使用できるからです。

。デフォルトの管理ポートは 4848 ですが、インストール中に別のポートを指定することもできます。ドメインが作成されると、管理ユーザー名とパスワードを入力するよう求められますが、ユーザー名が admin でパスワードがない場合は、デフォルトのままにすることもできます。管理者パスワードをリセットするには、「管理パスワードを変更する」を参照してください。

グラフィカルな管理コンソールは、特定のDAS と通信し、その DAS と関連するドメインを管理します。管理コンソールの各セッションにより、特定のドメインを設定し、管理できます。ドメインを複数作成した場合は、別々に管理コンソールセッションを起動して、それぞれのドメインを管理する必要があります。

ドメインの作成、ログイン、削除

ここでは、以下のトピックに関して説明します。

ドメインの作成

Enterprise Server をインストールしてデフォルトドメイン (domain1 ) を作成してからは、ローカルの create-domain サブコマンドを使用してさらにドメインが作成できるようになります。このサブコマンドは、ドメインの構成を作成します。所定のシステムの asadmin ユーティリティーに対してアクセス権を持つユーザーは、ドメインを作成し、自分の選択するフォルダにそのドメイン構成を格納することができます。デフォルトでは、ドメイン構成はドメインのデフォルトディレクトリに作成されます。この場所をオーバーライドして、別の場所に構成を格納することもできます。

ドメインを作成すると、管理ユーザーを指定するよう求められます。または、パスワードなしでユーザー名が admin のデフォルトログイン ID のままにしておくこともできます。

始める前に

ドメインに適用するプロファイルを決定します。

作成中のドメイン名を選択します。

まだ使用されていないドメイン名かどうかを確認するには、list-domains(1) を使用します。

ドメインを作成するには、create-domain(1) サブコマンドを使用します。

このサブコマンドのオプションについては、このマニュアルページに記載されています。

ドメインの admin ユーザー名とパスワードを入力します。

admin ログインを設定しないようにするには、パスワードなしでデフォルトの admin のままにします。Return を押しても、デフォルトが選択されます。

例 3–1 ドメインの作成

この例では、domain1 というドメイン名を作成します。コマンドを入力すると、ログイン情報を入力するよう求められることがあります。

asadmin> create-domain --adminport 4848 domain1
Enter admin user name[Enter to accept default]>
Using port 4848 for Admin.
Default port 8080 for HTTP Instance is in use. Using 1161
Using default port 7676 for JMS.
Using default port 3700 for IIOP.
Using default port 8081 for HTTP_SSL.
Using default port 3820 for IIOP_SSL.
Using default port 3920 for IIOP_MUTUALAUTH.
Default port 8686 for JMX_ADMIN is in use. Using 1162
Distinguished Name of the self-signed X.509 Server Certificate is:
[CN=moonbeam.gateway.2wire.net,OU=GlassFish,O=Sun Microsystems,L=Santa Clara,ST
California,C=US]
Domain domain1 created.
Command create-domain executed successfully.

管理コンソールをブラウザで起動するには、次のフォーマットで URL を入力します。

http://hostname:5000

この例の場合、ドメインのログファイル、構成ファイル、および配備されたアプリケーションは次のディレクトリに置かれます。

domain-root-dir/mydomain

参照

このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help create-domain と入力してください。

ドメインの一覧表示

ドメインとそのステータスを一覧表示するには、list-domains サブコマンドを使用します。ドメインのディレクトリが指定されていない場合は、デフォルト as-install の /domains ディレクトリにあるコンテンツが表示されます。複数のドメインが存在する場合は、ドメイン名を指定する必要があります。

別のディレクトリに作成されているドメインを一覧表示するには、--domaindir オプションを指定します。

ドメインを一覧表示するには、list-domains(1) サブコマンドを使用します。

例 3–2 ドメインの一覧表示

この例では、デフォルトの as-install/domains ディレクトリを一覧表示しています。

asadmin> list-domains
Name: domain1 Status: Running
Name: domain4 Status: Not Running
Name: domain6 Status: Not Running
Command list-domains executed successfully.

参照

このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help list-domain と入力してください。

ドメインへのログイン

どのリモートサブコマンドにも資格が必要で、管理ユーザー名とそのパスワードを指定しなくてはなりません。ID が明示的または暗黙的に何も指定されていない場合は、デフォルトでは asadmin ユーザーが管理者向け操作を実行できるような ID でドメインが作成されます。デフォルト ID は、ユーザー名が admin でパスワードがない形式です。コマンド行やプロンプトにユーザー名を指定せず、--passwordfile オプションまたはプロンプトにパスワードを何も指定せず、login サブコマンドまたは create-domain サブコマンドに ----savelogin オプションを付けたうちのいずれかでドメインにログインしたことがなければ、asadmin ユーティリティーが ID を何も指定せずに指定の管理操作を実行しようとします。サーバー (ドメイン) は、次の状況に当てはまる限り、このデフォルト ID を使用して管理操作を行えるようにします。

1. サーバー (ドメイン) が、admin ユーザーの認証にファイルレルムを使用している。

2. ファイルレルムに、ユーザーが 1 人しかいない (ユーザー名の内容は問わない)。

3. その 1 人のユーザーに、パスワードが用意されていない。

デフォルトでは、特定のユーザー名とパスワードでドメインを作成していない限り、これらの条件がすべて当てはまります。したがって、唯一の管理ユーザーは、パスワードなしの admin となります。3. に当てはまらない場合は、パスワードを指定する必要があります。2. に当てはまらない場合も、ユーザー名を指定する必要があります。1. に当てはまらない場合は、ユーザー名とパスワードを指定する必要があります。

特定ドメインへの認証 (ログイン) を行うには、ローカルモードで login サブコマンドを使用します。ログインした後は、そのドメインのそれ以降の操作に管理ユーザーやパスワードを指定しなくても済むようになります。login サブコマンドは、管理パスワードを指定する際にのみ使用できます。リモートサブコマンドから入力を求められるこれ以外のパスワードについては、--passwordfile オプションを使用するか、コマンドプロンプトでパスワードを指定してください。管理ユーザー名とパスワードの入力が常に求められます。

logout サブコマンドは一切ありません。別のドメインにログインするには、asadmin login の --host と --port に新しい値を付けて呼び出します。

ログインしようとしているドメイン名を指定します。

既存ドメインの一覧表示
asadmin list-domains

例 3–3 リモートマシンでのドメインへのログイン

この例では、別のマシンにあるドメインにログインします。login サブコマンドの前に、オプションを指定します。

asadmin> --host foo --port 8282 login
Please enter the admin user name>admin Please enter the admin password> 
Trying to authenticate for administration of server at host [foo] and port [8282] ... 
Login information relevant to admin user name [admin] 
for host [foo] and admin port [8282] stored at [/.asadminpass] successfully. 
Make sure that this file remains protected. Information stored in this
file will be used by asadmin commands to manage associated domain.

例 3–4 Localhost のデフォルトポートにあるドメインへのログイン

この例では、デフォルトポートの myhost にあるドメインにログインします。login サブコマンドの前に、オプションを指定します。

asadmin>  --host myhost login 
Please enter the admin user name>admin Please enter the admin password> 
Trying to authenticate for administration of server at host [myhost] and port [4848] ... 
An entry for login exists for host [myhost] and port [4848], probably from 
an earlier login operation. 
Do you want to overwrite this entry (y/n)?y 
Login information relevant to admin user name [admin] for host [myhost] 
and admin port [4848] stored at [/home/joe/.asadminpass] successfully. 
Make sure that this file remains protected. Information stored in this file will be used by 
asadmin commands to manage associated domain.

参照

このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help login と入力してください。パスワードの詳細は、「パスワードの管理」を参照してください。

ドメインの削除

サーバーから既存のドメインを削除するには、delete-domain サブコマンドを使用します。このサブコマンドを実行できるのは、このドメインを管理する権限があるルートユーザー、もしくはオペレーティングシステムのユーザーだけです。

始める前に

削除する前に、ドメインがすでに停止している必要があります。

ドメインを一覧表示するには、list-domains(1) サブコマンドを使用します。

必要な場合は、削除しようとしているドメインのドメインユーザーに通知してください。

削除対象のドメインが停止していることを確認します。

必要な場合は、「ドメインの停止」を参照してください。

delete-domain(1) サブコマンドを使用して、ドメインを削除します。

例 3–5 ドメインの削除

この例では、domain1 という名前のドメインを指定の場所から削除します。

asadmin> delete-domain --domaindir ..\domains domain1
Domain domain1 deleted.
Command delete-domain executed successfully.

参照

このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help delete-domain と入力してください。

ドメインの起動と停止

ここでは、以下のトピックに関して説明します。

ドメインの起動

ドメインまたはサーバーの起動時に、ドメイン管理サーバー (DAS) が起動されます。DAS は、一度起動すると常時稼動となり、要求を待機して受け付けます。

ドメインのディレクトリが指定されていない場合は、デフォルトの as-install/domains ディレクトリにあるドメインが起動します。複数のドメインが存在する場合、domain_name オペランドを指定する必要があります。各ドメインは、別々に起動する必要があります。

起動しているドメインで restart-domain サブコマンドを使用できるようにするには、--watchdog オプションを true に設定してください (true がデフォルトです)。--watchdog オプションを false に設定しておくと、そのドメインで restart-domain サブコマンドが使用できません。

注 –

Microsoft Windows の場合、ドメインを起動するにはもう 1 つ方法があります。Windows の「スタート」メニューで、「プログラム」>「Sun Microsystems」>「Enterprise Server」>「デフォルトサーバーを起動」を選択します。

このサブコマンドは、ローカルモードでのみサポートされています。

ドメインを起動するには、start-domain(1) サブコマンドを使用します。

例 3–6 ドメインの起動

この例では、デフォルトドメインディレクトリ内の domain2 を起動します。

asadmin> start-domain domain2

ドメインが 1 つだけの場合は、ドメイン名を省略できます。パスワードを含めていない場合は、入力を求められることがあります。

Name of the domain started: [domain1] and its location: 
[C:\prelude\v3_prelude_release\distributions\web\target\glassfish
domains\domain1].
Admin port for the domain: [4848].

参照

このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help start-domain と入力してください。

ドメインの停止

ドメインまたはサーバーを停止すると、そのドメインの管理サーバー (DAS) がシャットダウンします。ドメインを停止すると、その DAS は新しい接続を受け付けなくなり、未完了の接続がすべて完了するまで待機します。このシャットダウンプロセスには数秒間かかります。ドメインの停止処理中は、管理コンソールおよびほとんどの asadmin サブコマンドが使用できません。このサブコマンドは、異常なサーバーを停止する際に特に有用です。制御された状態では、restart-domain(1) サブコマンドも使用できます。

注 –

Microsoft Windows の場合、ドメインを停止するにはもう 1 つ方法があります。「スタート」メニューで、「プログラム」>「Sun Microsystems」>「Enterprise Server」>「デフォルトサーバー停止」を選択します。

必要な場合は、停止しようとしているドメインのユーザーに通知します。

stop-domain(1) サブコマンドを使用して、ドメインを停止します。

例 3–7 ドメイン (サーバー) の停止

この例では、デフォルトディレクトリにある domain1 を停止します。ここで、domain1 はこのディレクトリに存在する唯一のドメインとします。

asadmin> stop-domain
Waiting for the domain to stop ...........
Command stop-domain executed successfully.

参照

このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help stop-domain と入力してください。

ドメインの再起動

指定ホストのドメイン管理サーバー (DAS) を再起動するには、リモートモードで restart-domain サブコマンドを使用します。ドメインを再起動すると、その DAS は新しい接続を受け付けなくなり、未完了の接続がすべて完了するまで待機します。このシャットダウンプロセスには数秒間かかります。ドメインが再起動されるまで、管理コンソールおよびほとんどの asadmin サブコマンドが使用できません。

このサブコマンドは、サーバーマシンがセキュリティー保護されていてアクセスしにくい環境で特に有用です。正当な資格がある状態であれば、そのサーバーをリモートからでも同一マシンからでも再起動できます。

サーバーが再起動しない場合は、stop-domain(1) サブコマンドの後に start-domain(1) サブコマンドを使用します。

始める前に

restart-domain サブコマンドを成功させるには、ドメインを起動した時に start-domain サブコマンドの --watchdog オプションを (デフォルトの) true に設定しておく必要があります。このオプションが false に設定された状態でドメインを再起動しようとすると、ドメインが停止し警告メッセージのログが記録されます。--watchdog オプションを false に設定している場合、ドメインを再起動するには stop-domain および start-domain サブコマンドを使用するほかありません。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

restart-domain(1) サブコマンドを使用して、ドメインを再起動します。

例 3–8 ドメイン (サーバー) の再起動

この例では、デフォルトディレクトリにある mydoimain4 を再起動します。

asadmin> restart-domain mydomain4
Waiting for the domain to restart ...........
Command restart-domain executed successfully.

例 3–9 ブラウザでのドメインの再起動

この例では、ブラウザで restart-domain サブコマンドを呼び出します。

http://yourhost:4848/__asadmin/restart-domain

参照

このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help restart-domain と入力してください。

ドメインの自動再起動

ここでは、Solaris でドメインを自動的に再起動するようにシステムを設定する方法について説明します。

ここでは、以下のトピックに関して説明します。

Solaris 10 でのドメイン自動的再起動

create-service サブコマンドは、Solaris と Windows プラットフォームの両方でサポートされていますが、ここでは Solaris の手順のみ説明します。

Solaris 10 では、asadmin create-service サブコマンドを使用して、ドメイン管理サーバー (DAS) を再起動する Solaris Service Management Facility (SMF) サービスを作成できます。サービスはプロセスに、そのプロセスを実行するユーザーの特権を付与します。SMF サービスを作成する場合、デフォルトのユーザーはスーパーユーザーです。別のユーザーがプロセスを実行する必要がある場合は、method_credential にそのユーザーを指定します。

プロセスを Solaris 10 の特権ポートにバインドする場合、そのプロセスには net_privaddr 特権が必要です。Solaris オペレーティングシステムの特権ポートは、1024 より小さいポート番号です。

ユーザーが net_privaddr 特権を持っているかどうかを確認するには、そのユーザーとしてログインし、ppriv -l | grep net_privaddr コマンドを入力します。

SMF サービスを作成して有効にしたあと、ドメインが停止した場合は、SMF によって再起動されます。

始める前に

asadmin create-service コマンドを実行するには、solaris.smf.* 認証が必要です。この認証の設定方法については、useradd および usermod のマニュアルページを参照してください。さらに次のディレクトリツリーでの書き込み権も必要です。 /var/svc/manifest/application/SUNWappserver。通常、スーパーユーザーはこれらの権限をどちらも持っています。また、svccfg、svcs、auths などの Solaris 10 管理コマンドが PATH で使用できなければなりません。

特定の Enterprise Server ドメインにデフォルトのユーザー特権を与えないようにする場合は、サービスのマニフェストを変更し、サービスを再インポートします。

create-service(1) サブコマンドを使用して、サービスを作成します。

このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

サービスが作成されたら、svacdm enable コマンドを使用してサービスを有効にします。

次に例を示します。
svacdm enable /appserver/domains/domain1

例 3–10 Solaris 10 でドメインを自動再起動するためにサービスを作成する

この例では、サービスを作成します。

asadmin> create-service
The Service was created successfully. Here are the details:
Name of the service:application/GlassFish/domain1
Type of the service:Domain
Configuration location of the service:/home/gfuser/glassfish-installations
/glassfishv3/glassfish/domains
Manifest file location on the system:/var/svc/manifest/application
/GlassFish/domain1_home_gfuser_glassfish-installations_glassfishv3
_glassfish_domains/Domain-service-smf.xml.
You have created the service but you need to start it yourself.
Here are the most typical Solaris commands of interest:
* /usr/bin/svcs -a | grep domain1 // status
* /usr/sbin/svcadm enable domain1 // start
* /usr/sbin/svcadm disable domain1 // stop
* /usr/sbin/svccfg delete domain1 // uninstall
Command create-service executed successfully

参照

サービスを管理するときに、次の Solaris コマンドが役に立ちます。 auths、smf_security、svcadm、 svccfg、rbac、useradd、および usermod。

Linux 上での自動再起動

Linux 上で再起動を設定するには、/etc/inittab を編集します。/etc/rc.local またはこれに相当するファイルを使用している場合は、/etc/rc.local に必要な asadmin サブコマンドを呼び出す行を追加します。

/etc/inittab ファイルにテキストを 1 行追加します。

次に例を示します。
das:3:respawn:/opt/SUNWappserver/bin/asadmin start-domain --user admin --passwordfile /opt/SUNWappserver/password.txt domain1
このテキストは 1 行で記述してください。先頭の 3 文字はこのプロセスに対する一意の指示子ですが、これは変更可能です。

ユーザーの Windows ログアウト時にサービスがシャットダウンされないようにする

デフォルトでは、Java Virtual Machine (JVM) は、Windows のシャットダウンまたはユーザーの Windows ログアウトが行われることを示すシグナルを Windows からキャッチし、Java VM 自身を完全にシャットダウンします。この動作により、Enterprise Server サービスがシャットダウンされます。ユーザーがログアウトするときにサービスがシャットダウンしないようにするには、-Xrs Java VM オプションを設定します。

as-install\domains\ domain-name\config\domain.xml ファイル内の、Java VM オプションを定義するセクションに次の行を追加します。
```
<jvm-options>-Xrs</jvm-options>
```

Enterprise Server サービスが稼働している場合、変更を有効にするには、そのサービスを再起動します。

その他のドメインタスク

ここでは、以下のトピックに関して説明します。

ドメインの稼働時間の表示

ドメイン管理サーバー (DAS) を最後に起動してから今まで稼動している期間を表示するには、リモートモードで uptime サブコマンドを使用します。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

uptime(1) サブコマンドで稼働時間を表示します。

例 3–11 DAS 稼働時間の表示

この例では、DAS の稼働時間を表示します。

asadmin> uptime
Uptime: 1 Weeks, 4 days, 0 hours, 17 minutes, 14 seconds, Total milliseconds: 951434595
Command uptime executed successfully.

参照

このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help uptime と入力してください。

サポートされている別の Java バージョンへドメインを切り換える

Enterprise Server v3 には、Java^TM プラットフォーム (Java Virtual Machine すなわち JVM^TM マシン) のベースとなる仮想マシンに Version 6 Java SE プラットフォームが必要です。

注 –

新しい JVM マシンでドメインを作成したあとは、以前の Java バージョンにはダウングレードしないでください。ご使用の JVM マシンをダウングレードする必要がある場合は、そのドメインの Java バージョンだけをダウングレードしてください。

まだダウングレードしていない場合は、目的の Java SDK (JRE ではありません) をダウンロードして、システムにインストールしてください。

Java SDK は、http://java.sun.com/j2se でダウンロードできます。

JDK を変更するドメインを起動します。

次のフォーマットを使用します。
as-install/bin/asadmin start-domain domain-name
有効な JVM インストールの場合、次の順で場所がチェックされます。
1. domain.xml (java-config 内の java-home)
2. asenv.conf (AS_JAVA="path to java home" 設定)
有効な JDK が見つからない場合は、致命的エラーが発生し、その問題のレポートが返されます。

必要な場合は、ドメインの JVM マシン属性を変更します。

特に、JAVA_HOME 環境変数を変更する必要があります。JAVA_HOME 変数を変更するには、たとえば次のように入力します。
as-install/bin/asadmin set "server.java-config.java-home=path-to-java-home"

第 4 章 Java プラットフォームの仮想マシンの管理

この章では、asadmin コマンド行ユーティリティーを使用して、Sun GlassFish^TM Enterprise Server v3 環境で Java^TM プラットフォームの仮想マシン (Java 仮想マシン、または JVM^TM マシン) を管理する手順について説明します。

ここでは、次のテーマを取り上げます。

これらのタスクを管理コンソールを使用して実行する場合の手順は、管理コンソールのオンラインヘルプで説明します。

JVM オプションの管理

Java 仮想マシンは、コンパイルされた Java プログラムのバイトコードを実行するための、インタプリタ型の処理エンジンです。仮想マシンは Java バイトコードをホストマシンのネイティブ命令に変換します。Java プロセスの 1 つである Enterprise Server は、Java アプリケーションの実行とサポートに仮想マシンを必要とします。JVM の設定は、Enterprise Server の構成の一部です。

ここでは、次のテーマを取り上げます。

JVM オプションを作成する

Java 構成または domain.xml ファイルのプロファイラ要素に JVM オプションを作成するには、リモートモードで create-jvm-options サブコマンドを使用します。プロファイラ用に作成された JVM オプションは、プロファイラを開始する設定を記録するために使用されます。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

create-jvm-options(1) サブコマンドを使用して、JVM オプションを作成します。

複数の JVM オプションを作成する場合は、コロン (:) を使用してオプションを区切ります。JVM オプション自体にコロン (:) が含まれている場合は、バックスラッシュ (\) を使用して区切り記号のコロンと区別します。

このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

変更内容を適用するために、Enterprise Server を再起動します。「ドメインの再起動」を参照してください。

例 4–1 JVM オプションの作成

この例では、複数の Java システムプロパティーを設定します。

asadmin> create-jvm-options -Dunixlocation=/root/example:
-Dvariable=\$HOME:
-Dwindowslocation=d\\:\\\sun\\\appserver:
-Doption1=-value1
created 4 option(s)
Command create-jvm-options executed successfully.

参照

コマンド行に asadmin help create-jvm-options と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JVM オプションを一覧表示する

既存の JVM オプションを一覧表示するには、リモートモードで list-jvm-options サブコマンドを使用します。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-jvm-options(1) サブコマンドを使用して、JVM オプションを一覧表示します。

例 4–2 JVM オプションの一覧表示

この例では、すべての JVM オプションを表示します。

asadmin> list-jvm-options
-Djava.security.auth.login.config=${com.sun.aas.instanceRoot}/config/login.conf
-XX: LogVMOutput
-XX: UnlockDiagnosticVMOptions
-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.
config.serverbeans.AppserverConfigEnvironmentFactory
-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore.jks
-XX:NewRatio=2
-Djava.security.policy=${com.sun.aas.instanceRoot}/config/server.policy
-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver
-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/cacerts.jks
-client
-Djava.ext.dirs=${com.sun.aas.javaRoot}/lib/ext${path.separator}${com.sun.aas.ja
vaRoot}/jre/lib/ext${path.separator}${com.sun.aas.instanceRoot}/lib/ext${path.se
parator}${com.sun.aas.derbyRoot}/lib
-Xmx512m
-XX:LogFile=${com.sun.aas.instanceRoot}/logs/jvm.log
-Djava.endorsed.dirs=${com.sun.aas.installRoot}/lib/endorsed

Command list-jvm-options executed successfully.

参照

コマンド行に asadmin help list-jvm-options と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JVM オプションを削除する

Java 構成または domain.xml ファイルのプロファイラ要素から JVM オプションを削除するには、リモートモードで delete-jvm-options サブコマンドを使用します。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-jvm-options(1) サブコマンドを使用して、JVM オプションを一覧表示します。

必要に応じて、JVM オプションを削除することをユーザーに通知します。

delete-jvm-options(1) サブコマンドを使用して、JVM オプションを削除します。

複数の JVM オプションを削除する場合は、コロン (:) を使用してオプションを区切ります。JVM オプション自体にコロンが含まれている場合は、バックスラッシュ (\) を使用して区切り記号のコロンと区別します。

変更内容を適用するために、Enterprise Server を再起動します。「ドメインの再起動」を参照してください。

例 4–3 単一の JVM オプションの削除

この例では、1 つの JVM オプションを削除します。

asadmin> delete-jvm-options -Dopt1=A
deleted 1 option(s)
Command delete-jvm-options executed successfully.

例 4–4 複数の JVM オプションの削除

この例では、複数の JVM オプションを削除します。

asadmin> delete-jvm-options -Doption1=-value1:-Dvariable=\$HOME
deleted 2 option(s)
Command delete-jvm-options executed successfully.

参照

コマンド行に asadmin help delete-jvm-options と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JVM レポートを生成する

指定したドメイン管理サーバー (DAS) のスレッド (スタックトレースのダンプ)、クラス、メモリー、およびロガーを示す JVM レポートを生成するには、リモートモードで generate-jvm-report サブコマンドを使用します。生成できるレポートのタイプは、概要 (デフォルト)、クラス、スレッド、およびログです。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

generate-jvm-report(1) サブコマンドを使用して、レポートを生成します。

例 4–5 JVM レポートの生成

この例では、スレッド、クラス、およびメモリーの概要情報を表示します。

asadmin> generate-jvm-report --type summary 
Operating System Information:
Name of the Operating System: Windows XP
Binary Architecture name of the Operating System: x86, Version: 5.1
Number of processors available on the Operating System: 2
System load on the available processors for the last minute: NOT_AVAILABLE. 
(Sum of running and queued runnable entities per minute).
.
,
.
user.home = C:\Documents and Settings\Jennifer
user.language = en
user.name = Jennifer
user.timezone = America/New_York
user.variant =
variable = \$HOME
web.home = C:\Preview\v3_Preview_release\distributions\web\target\
glassfish\modules\web
Command generate-jvm-report executed successfully.

参照

コマンド行に asadmin help generate-jvm-report と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

プロファイラの管理

「プロファイラ」は、サーバーパフォーマンスの解析に使用される情報を生成します。ここでは、次のテーマを取り上げます。

プロファイラを作成する

サーバーインスタンスは、Java 構成内のプロファイラ要素によって、特定のプロファイラと連動しています。プロファイラ用に作成された JVM オプションは、特定のプロファイラの有効化に必要な設定を記録するために使用されます。Java 構成にプロファイラ要素を作成するには、リモートモードで create-profiler サブコマンドを使用します。

存在できるプロファイラは 1 つだけです。すでにプロファイラが存在している場合はエラーメッセージが表示され、新しいプロファイラを作成する前に古いプロファイラを削除するように指示されます。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

create-profiler(1) サブコマンドを使用して、プロファイラを作成します。

このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

変更内容を適用するために、Enterprise Server を再起動します。

「ドメインの再起動」を参照してください。

例 4–6 プロファイラの作成

この例では、sample_profiler という名前のプロファイラを作成します。

asadmin> create-profiler --classpath=/home/appserver/ --nativelibrarypath=/u/home/lib
--enabled=false --property=defaultuser=admin:password=adminadmin sample_profiler
Command create-profiler executed successfully.

参照

コマンド行に asadmin help create-profiler と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

プロファイラを削除する

Java 構成からプロファイラ要素を削除するには、リモートモードで delete-profiler サブコマンドを使用します。削除のあと、新しいプロファイラを作成できます。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

delete-profiler(1) サブコマンドを使用して、プロファイラを削除します。

変更内容を適用するために、Enterprise Server を再起動します。

「ドメインの再起動」を参照してください。

例 4–7 プロファイラの削除

この例では、sample_profiler という名前のプロファイラを削除します。

asadmin> delete-profiler sample_profiler
Command delete-profiler executed successfully.

参照

コマンド行に asadmin help delete-profiler と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

第 5 章スレッドプールの管理

この章では、asadmin コマンド行ユーティリティーを使用して、Sun GlassFish^TM Enterprise Server v3 環境でスレッドプールを管理する手順について説明します。

ここでは、次のテーマを取り上げます。

これらのタスクを管理コンソールを使用して実行する場合の手順は、管理コンソールのオンラインヘルプで説明します。

スレッドプールについて

Java^TM プラットフォームの仮想マシン (Java 仮想マシン、または JVM^TM マシン) は、多数の実行スレッドを同時にサポートすることができます。パフォーマンスの向上に役立つように、Enterprise Server は 1 つまたは複数のスレッドプールを維持します。特定のスレッドプールを、コネクタモジュール、ネットワークリスナー、または ORB (Object Request Broker) に割り当てることができます。

1 つのスレッドプールで、複数のコネクタモジュールおよびエンタープライズ Bean を処理できます。「要求スレッド」は、アプリケーションコンポーネントへのユーザーの要求を処理します。Enterprise Server は要求を受け取ると、その要求をスレッドプール内の使用可能なスレッドに割り当てます。スレッドはクライアントの要求を実行し、結果を返します。たとえば、現在ビジー状態のシステムリソースが必要な場合、スレッドはリソースが解放されるのを待ってから、リソースの使用を要求に許可します。

スレッドプールの構成

アプリケーションからの要求用に確保するスレッドの最小数と最大数を指定できます。スレッドプールはこれら 2 つの値の間で動的に調整されます。

ここでは、次のテーマを取り上げます。

スレッドプールを作成する

スレッドプールを作成するには、リモートモードで create-threadpool サブコマンドを使用します。

サーバーは、指定された最小スレッドプールサイズに従って、アプリケーション要求用に確保するスレッドを割り当てます。その数は、指定された最大スレッドプールサイズまで増加できます。プロセスで使用可能なスレッドの数を増やすと、プロセスが同時に応答できるアプリケーション要求数が多くなります。

1 つのリソースアダプタまたはアプリケーションが Enterprise Server のすべてのスレッドを占有すると、スレッド不足が発生します。この状況は、Enterprise Server のスレッドを複数のスレッドプールに分割することで回避できます。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

create-threadpool(1) サブコマンドを使用して、新しいスレッドプールを作成します。

サブコマンドのオプションについては、このサブコマンドのマニュアルページを参照してください。

変更内容を適用するために、Enterprise Server を再起動します。

「ドメインの再起動」を参照してください。

注 –
Web コンテナによって使用されるスレッドプールでは、再起動が必要ない場合もあります。

例 5–1 スレッドプールの作成

この例では、threadpool-l を作成します。

asadmin> create-threadpool --maxthreadpoolsize 100 
      --minthreadpoolsize 20 --idletimeout 2 --workqueues 100 threadpool-1
Command create-threadpool executed successfully

参照

コマンド行に asadmin help create-threadpool と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

スレッドプールを一覧表示する

既存のスレッドプールを一覧表示するには、リモートモードで list-threadpools サブコマンドを使用します。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-threadpools(1) サブコマンドを使用して、既存のスレッドプールを一覧表示します。

例 5–2 スレッドプールの一覧表示

この例では、既存のスレッドプールを一覧表示します。

asadmin> list-threadpools
threadpool-1
Command list-threadpools executed successfully

参照

コマンド行に asadmin help list-threadpools と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

スレッドプールを更新する

set サブコマンドを使用して、指定したスレッドプールの値を更新します。

list-threadpools(1) サブコマンドを使用して、既存のスレッドプールを一覧表示します。

set(1) サブコマンドを使用して、スレッドプールの値を変更します。

スレッドプールはドット表記名で識別されます。

変更内容を適用するために、Enterprise Server を再起動します。

「ドメインの再起動」を参照してください。

注 –
Web コンテナによって使用されるスレッドプールでは、再起動が必要ない場合もあります。

例 5–3 スレッドプールの更新

この例では、max-thread-pool-size を元の値から 8 に変更します。

asadmin> set server.thread-pools.thread-pool.http-thread-pool.max-thread-pool-size=8
Command set executed successfully

参照

コマンド行に asadmin help set と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

スレッドプールを削除する

既存のスレッドプールを削除するには、リモートモードで delete-threadpool サブコマンドを使用します。スレッドプールがネットワークリスナーによって参照されている場合、そのプールの削除は失敗します。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-threadpools(1) サブコマンドを使用して、既存のスレッドプールを一覧表示します。

delete-threadpool(1) サブコマンドを使用して、指定したスレッドプールを削除します。

変更内容を適用するために、Enterprise Server を再起動します。

「ドメインの再起動」を参照してください。

注 –
Web コンテナによって使用されるスレッドプールでは、再起動が必要ない場合もあります。

例 5–4 スレッドプールの削除

この例では、threadpool-1 を削除します。

asadmin> delete-threadpool threadpool-1
Command delete-threadpool executed successfully

参照

コマンド行に asadmin help delete-threadpool と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

第 6 章 Web アプリケーションの管理

この章では、Sun GlassFish^TM Enterprise Server v3 環境で Web アプリケーションを管理する方法について説明します。

ここでは、次のテーマを取り上げます。

これらのタスクの一部を管理コンソールを使用して実行する場合の手順は、管理コンソールのオンラインヘルプで説明します。

サーブレッドの呼び出し方法について

Enterprise Server に配備されたサーブレットは、ブラウザに URL を指定して呼び出すことができます。また、HTML ファイルや JSP ファイル内にリンクとして埋め込まれたサーブレットも呼び出すことができます。サーブレットの呼び出し URL の形式は次のとおりです。

http://server:port/context-root/servlet-mapping?name=value

次の表に URL の各セクションの意味を示します。

表 6–1 アプリケーション内のサーブレットを呼び出す URL のフィールド


URL 要素	説明
`server:port`	IP アドレス (またはホスト名) および省略可能のポート番号。仮想サーバーのデフォルト Web モジュールにアクセスする場合は、この URL セクションだけを指定します。名前と値のパラメータも指定するのでない限り、`context-root` と servlet-name を指定する必要はありません。
`context-root`	アプリケーションのコンテキストルートは、`application.xml`、`sun-application.xml`、または `sun-web.xml` ファイルの `context-root` 要素で定義されます。個別に配備される Web モジュールのコンテキストルートは、配備中に指定されます。アプリケーションと個別に配備された Web モジュールのどちらでも、デフォルトのコンテキストルートは WAR ファイルの名前から `.war` のサフィックスを除いた文字列になります。
`servlet-mapping`	`web.xml` ファイルで設定された `servlet-mapping`。
`?name=` `value...`	省略可能な要求のパラメータ。

例 6–1 URL によるサーブレットの呼び出し

この例では、localhost はホスト名、MortPages はコンテキストルート、および calcMortgage はサーブレットマッピングを表します。

http://localhost:8080/MortPages/calcMortgage?rate=8.0&per=360&bal=180000

例 6–2 JSP ファイル内でのサーブレットの呼び出し

JSP ファイル内でサーブレットを呼び出す場合は、相対パスを使用できます。次に例を示します。

<jsp:forward page="TestServlet"/><jsp:include page="TestServlet"/>

サーブレットのログ出力の変更

ServletContext.log のメッセージは、サーバーログに送信されます。デフォルトでは、サーブレットの System.out および System.err 出力はサーバーログに送信されます。起動中に、サーバーログのメッセージは System.err 出力にエコーされます。またデフォルトでは、System.err 出力用の Windows 専用コンソールはありません。

これらのデフォルト設定は、管理コンソールの「システムログに書き込み」ボックスを使用して変更できます。このボックスにチェックマークを付けると、System.out 出力がサーバーログに送信されます。チェックマークを外すと、System.out 出力はシステムのデフォルトの場所だけに送信されます。

Web アプリケーションのグローバルな機能の定義

default-web.xml ファイルを使用して、フィルタやセキュリティー制約などの、すべての Web アプリケーションに適用される機能を定義できます。

たとえば、ディレクトリの一覧表示は、セキュリティーの強化のためにデフォルトで無効化されます。ドメインの default-web.xml ファイルでディレクトリの一覧表示を有効にするには、servlet-name が default であるサーブレットの定義を検索し、listings という名前の init-param を true に設定します。続いて、サーバーを再起動します。

<init-param>
   <param-name>listings</param-name>
   <param-value>true</param-value>
</init-param>

listings を true に設定した場合、ディレクトリの一覧表示をソートする方法も決定できます。sortedBy という名前の init-param の値を、NAME、SIZE、または LAST_MODIFIED に設定します。続いて、サーバーを再起動します。

<init-param>
   <param-name>sortedBy</param-name>
   <param-value>LAST_MODIFIED</param-value>
</init-param>

default-web.xml ファイルの mime-mapping 要素はグローバルで、すべての Web アプリケーションで継承されます。Web アプリケーションの web.xml ファイルで mime-mapping 要素を使用して、これらのマッピングを上書きするか、独自に定義することができます。mime-mapping 要素の詳細は、Servlet 仕様を参照してください。

default-web.xml ファイルは、管理コンソールを使用して編集するか、次の手順で直接編集することができます。

`default-web.xml` ファイルを使用する

フィルタ、セキュリティー制約、またはその他の機能の JAR ファイルを、domain-dir/lib ディレクトリに配置します。

配置した JAR ファイルを参照するように、domain-dir/config/default-web.xml ファイルを編集します。

変更内容を適用するために、Enterprise Server を再起動します。

「ドメインの再起動」を参照してください。

URL のリダイレクト

古い URL に対する要求を、新しい URL に対する要求として処理するように指定できます。この処理は、URL の「リダイレクト」と呼ばれます。

仮想サーバーのリダイレクトされる URL を指定するには、redirect_ n プロパティーを使用します。n は正の整数で、複数の指定が可能です。各 redirect_n プロパティーは、仮想サーバーに配備されたすべての Web アプリケーションによって継承されます。

redirect_n プロパティーの値には 2 つの構成要素があり、任意の順番で指定できます。

最初の構成要素の from は、照合する要求された URI のプレフィックスを指定します。
2 番目の構成要素の url-prefix はクライアントに返す新しい URL プレフィックスを指定します。 from プレフィックスは、この URL プレフィックスで置き換えられます。

例 6–3 URL のリダイレクト

この例では、from に指定した dummy を etude にリダイレクトします。

<property name="redirect_1" value="from=/dummy url-prefix=http://etude"/>

`mod_jk` の管理

mod_jk コネクタを使用すると、Web コンテナを Apache HTTP Server などの Web サーバーに接続できます。mod_jk は Enterprise Server に付属するコネクタで、これを使用することにより、Enterprise Server の前に Apach HTTP Server をたてることができます。この処理の一般的な目的は、静的なリソースに対する要求を Apache HTTP Server に処理させ、サーブレットや JavaServer^TM Pages (JSP) などの動的なリソースに対する要求を、Enterprise Server のバックエンドインスタンスに転送して処理することです。

負荷分散の目的で、mod_jk を JSP またはサーブレットエンジンで直接使用することもできます。

ここでは、次のテーマを取り上げます。

mod_jk を有効にする

ここで説明するように mod_jk コネクタを有効化することで、Enterprise Server と Apache HTTP Server を連携させることができます。ネットワークリスナーの jk-enabled 属性を使用する場合、追加の JAR ファイルを /lib ディレクトリにコピーする必要はありません。ネットワークリスナー属性の jk-enabled を使用することで、JK コネクタを別の仮想サーバーに作成することもできます。

Apache HTTP Server と mod_jk をインストールします。
- Apache HTTP Server のインストール方法については、http://httpd.apache.org/docs/2.0/install.html を参照してください。
- mod_jk のインストール方法については、http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html を参照してください。

次のファイルを設定します。
- apache2/conf/httpd.conf (Apache の主要な構成ファイル)
- apache2/config/workers.properties または domain-dir /config/glassfish-jk.properties (http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html で説明されている属性のデフォルト以外の値を使用する場合)
worker.properties ファイルと glassfish-jk.properties ファイルの両方を使用する場合は、httpd.conf で参照されている (または、httpd.conf で最初に参照される) ファイルが優先されます。

Apache HTTP Server (httpd) を起動します。

Web アプリケーションが少なくとも 1 つ配備されている Enterprise Server を起動します。

配備済み Web アプリケーションを少なくとも 1 つ使用する Web コンテナが起動されていなければ、mod_jk コネクタは起動できません。

次のコマンドを実行して、HTTP リスナーを作成します。

asadmin> create-http-listener --listenerport 8009 
--listeneraddress 0.0.0.0 --defaultvs server listener-name

次のコマンドを実行して、mod_jk を有効にします。
asadmin> set server-config.network-config.network-listeners. network-listener.listener-name.jk-enabled=true
listener-name は、mod_jk を有効にするネットワークリスナーの ID です。

glassfish-jk.properties ファイルを使用していて、httpd.conf でこのファイルを参照していない場合は、次のコマンドを実行してファイルの場所を指定します。
asadmin> create-jvm-options -Dcom.sun.enterprise.web.connector.enableJK.propertyFile= domain-dir/config/glassfish-jk.properties

変更内容を適用するために、Enterprise Server を再起動します。

「ドメインの再起動」を参照してください。

例 6–4 `mod_jk` を使用する場合の `httpd.conf` ファイルの設定

この例では、httpd.conf ファイルを示します。

LoadModule jk_module /usr/lib/httpd/modules/mod_jk.so
JkWorkersFile /etc/httpd/conf/worker.properties
# Where to put jk logs
JkLogFile /var/log/httpd/mod_jk.log
# Set the jk log level [debug/error/info]
JkLogLevel debug
# Select the log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
# JkOptions indicate to send SSL KEY SIZE,
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
# JkRequestLogFormat set the request format
JkRequestLogFormat "%w %V %T"
# Send all jsp requests to GlassFish
JkMount /*.jsp worker1
# Send all glassfish-test requests to GlassFish
JkMount /glassfish-test/* worker1

例 6–5 `mod_jk` を使用する場合の `worker.properties` ファイルの設定

この例では、worker.properties または glassfish-jk.properties ファイルを示します。

# Define 1 real worker using ajp13
worker.list=worker1
# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009

参照

Apache の詳細は、http://httpd.apache.org/ を参照してください。

mod_jk と Enterprise Server を使用して負荷分散する

負荷分散は、1 台のコンピュータで実行しなければならない作業を複数のコンピュータに分配し、同じ時間でより多くの作業を行う処理です。

「mod_jk を有効にする」の手順を実行します。

少なくとも 1 つの Web アプリケーションが配備されている、別の Enterprise Server を起動します。

配備済み Web アプリケーションを少なくとも 1 つ使用する Web コンテナが起動されていなければ、mod_jk コネクタは起動できません。

次のようなコマンドを実行して、HTTP リスナーを作成します。
asadmin> create-http-listener --listenerport 8010 --listeneraddress 0.0.0.0 --defaultvs server my-connector
複数のインスタンスが同じマシンで動作している場合は、別の JK ポートを選択する必要があります。ポートは worker.properties ファイルの worker.worker*.port に一致する必要があります。以下のプロパティーファイルの例を参照してください。

次のコマンドを実行して、mod_jk を有効にします。
asadmin> set server-config.network-config.network-listeners. network-listener.listener-name.jk-enabled=true
listener-name は、mod_jk を有効にするネットワークリスナーの ID です。

変更を適用するには、Apache と Enterprise Server を再起動します。

「ドメインの再起動」を参照してください。

例 6–6 負荷分散を行う場合の `httpd.conf` ファイルの設定

この例では、httpd.conf ファイルを示します。

LoadModule jk_module /usr/lib/httpd/modules/mod_jk.so 
JkWorkersFile /etc/httpd/conf/worker.properties 
# Where to put jk logs 
JkLogFile /var/log/httpd/mod_jk.log 
# Set the jk log level [debug/error/info] 
JkLogLevel debug 
# Select the log format 
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " 
# JkOptions indicate to send SSL KEY SIZE, 
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories 
# JkRequestLogFormat set the request format 
JkRequestLogFormat "%w %V %T" 
# Send all jsp requests to GlassFish 
JkMount /*.jsp worker1 
# Send all glassfish-test requests to GlassFish 
JkMount /glassfish-test/* loadbalancer

例 6–7 負荷分散を行う場合の `worker.properties` ファイルの設定

この例では、worker.properties または glassfish-jk.properties ファイルを示します。worker.worker*.port は、作成した JK ポートに一致している必要があります。

worker.list=loadbalancer
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009
worker.worker1.lbfactor=1
worker.worker1.socket_keepalive=1
worker.worker1.socket_timeout=300
worker.worker2.type=ajp13
worker.worker2.host=localhost
worker.worker2.port=8010
worker.worker2.lbfactor=1
worker.worker2.socket_keepalive=1
worker.worker2.socket_timeout=300
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=worker1,worker2

第 7 章ロギングサービスの管理

この章では、Sun GlassFish^TM Enterprise Server v3 環境で、ロギングを設定する手順とログ情報を表示する手順について説明します。

ここでは、次のテーマを取り上げます。

これらのタスクの実行とプロパティーの編集を管理コンソールを使用して行う場合の手順は、管理コンソールのオンラインヘルプで説明します。

ロギングについて

「ロギング」は、構成エラー、セキュリティー障害、サーバーの不完全な動作といったサーバーの動作中に発生したイベントに関する情報を、Enterprise Server が取得するための処理です。このデータはログファイルに記録され、通常は問題が発生したときの主要な情報源となります。ログファイルの解析は、サーバーの健全性を判断する際に役立ちます。

アプリケーションコンポーネントでは Apache Commons Logging Library を使用してメッセージを記録することもできますが、より適切なログ構成を行うには、プラットフォーム標準の JSR 047 API をお勧めします。

ここでは、次のテーマを取り上げます。

ログファイル

Enterprise Server のログレコードはサーバーログに記録されます。デフォルトのサーバーログの名前は server.log で、通常は domain-dir/logs に保存されます。サーバーログのデフォルトの名前または場所は、管理コンソールを使用して変更できます。

サーバーログのほかに、domain-dir/logs ディレクトリには次のログも保存されます。

HTTP サービスアクセスログ (/access サブディレクトリ)
トランザクションサービスログ (/tx サブディレクトリ)

サーバーログのサイズが指定された値 (バイト単位) に達すると、ログはローテーションされ、タイムスタンプを付加した server.log_ date という名前に変更されます。date は、ファイルがローテーションされた日時を表します。ログファイルのローテーションは、「サーバーログのローテーション」の手順に従って手動で行うこともできます。

Enterprise Server のログレコードは、次の統一形式に従います。

[#|yyyy-mm-ddThh:mm:ss.SSS-Z|Log Level|ProductName-Version|LoggerName|Key Value Pairs|Message|#]

[# と #] はレコードの開始と終了をマーク付けします。
垂直線 (|) は、レコードのフィールドを区切ります。
yyyy-mm-ddThh:mm:ss.SSSS-Z は、レコードが作成された日時を表します。たとえば、2006-10-21T13:25:53.852-0400 です。
Log Level は、指定したログレベルを表します。ログレベルには、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、および FINEST のいずれかの値を選択できます。デフォルトは、「INFO」です。
ProductName-Version は、Enterprise Server の現在のバージョンを表します。たとえば、glassfish です。
LoggerName は、ログモジュールのソースを識別する階層ロガーの名前空間です。たとえば、javax.enterprise.system.core です。
Key Value Pairs は、キーの名前と値のペア (通常はスレッド ID) を表します。たとえば、_ThreadID=14; です。
Message は、ログメッセージのテキストです。Enterprise Server のすべての SEVERE および WARNING のメッセージと、多くの INFO メッセージは、モジュールコードと数値で構成されるメッセージ ID で始まります。たとえば、CORE5004 です。

ログレコードの例を次に示します。

[#|2006-10-21T13:25:53.852-0400|INFO|GlassFish10.0|javax.enterprise.
system.core|_ThreadID=13;|CORE5004: Resource Deployed: 
[cr:jms/DurableConnectionFactory].|#]

管理コンソールでは、ログレコードがわかりやすい形式で表示されます。

ロガー名前空間

list-logger-levels(1) サブコマンドを使用して、モジュールの既存のロガーを一覧表示できます。次に例を示します。

javax.enterprise.system.container.cmp: INFO
javax.enterprise.system.tools.admin: INFO
javax.enterprise.system.container.web: INFO
javax.enterprise.system.util: INFO
javax.enterprise.resource.webcontainer.jsf.timing: INFO
javax: INFO
javax.enterprise.resource.corba: INFO
javax.enterprise.system.core.naming: INFO
javax.enterprise.system.core.selfmanagement: INFO
javax.enterprise.system.container.ejb: INFO
javax.enterprise.resource.webcontainer.jsf.config: INFO
javax.enterprise.resource.javamail: INFO
org.apache.catalina: INFO
javax.enterprise.system.core.config: INFO
javax.enterprise.system.webservices.rpc: INFO
javax.enterprise.system.webservices.registry: INFO
javax.enterprise.system.tools.deployment: INFO
javax.enterprise.resource.jms: INFO
javax.enterprise.system: INFO
javax.enterprise.system.webservices.saaj: INFO
org.apache.jasper: INFO
javax.enterprise.resource.webcontainer.jsf.lifecycle: INFO
javax.enterprise.resource.jta: INFO
javax.enterprise.resource.jdo: INFO
javax.enterprise.resource.resourceadapter: INFO
javax.enterprise.system.core.transaction: INFO
javax.enterprise.resource.webcontainer.jsf.resource: INFO
javax.enterprise.system.core.security: INFO
javax.enterprise.resource.webcontainer.jsf.application: INFO
javax.enterprise.system.core.classloading: INFO
org.apache.coyote: INFO
javax.enterprise.resource.webcontainer.jsf.managedbean: INFO
javax.enterprise.system.container.ejb.mdb: INFO
javax.enterprise.resource.webcontainer.jsf.context: INFO
javax.enterprise.resource.webcontainer.jsf.renderkit: INFO
javax.enterprise.resource.webcontainer.jsf.facelets: INFO
javax.enterprise.resource.webcontainer.jsf.taglib: INFO

ログレベルの設定

「ログレベル」は、ログに記録するメッセージの粒度を決定します。ここには、エラーのみ (SEVERE) から詳細なデバッグ情報 (FINEST) までのいずれかを指定します。選択できる値は、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、および FINEST です。各ログレベルは上位のレベルを含みます。つまり、特定のログレベル (たとえば、INFO) を設定した場合、これより上位のログレベル (SEVERE および WARNING) のメッセージも記録されます。もっとも低いログレベル (FINEST) に設定した場合、出力にはファイルのすべてのメッセージが含まれます。デフォルト設定は、INFO です。

ログレベルの設定には、グローバル設定とロガー固有の設定の 2 つを利用できます。ロガー固有の設定を選択し、この設定がグローバル設定と異なる場合は、ロガー固有の設定が優先されます。

グローバルログレベルを設定するには、logging.properties ファイルを編集します。モジュールごとのログレベルは、この節で説明するように asadmin サブコマンドを使用して設定します。

ログレベルの設定

ログレベルの設定は動的な処理であるため、変更を有効にするために Enterprise Server を再起動する必要はありません。

ここでは、次のテーマを取り上げます。

ロガーレベルを一覧表示する

モジュールと各モジュールの現在のログレベルを一覧表示するには、リモートモードで list-logger-levels サブコマンドを使用します。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-logger-levels(1) サブコマンドを使用して、既存のモジュールのロガーを一覧表示します。

例 7–1 モジュールのロガーレベルの一覧表示

この例では、既存のロガーの一部と、各ロガーで設定されているログレベルを一覧表示します。

asadmin> list-logger-levels
javax.enterprise.system.container.cmp: INFO
javax.enterprise.system.tools.admin: INFO
java.util.logging.ConsoleHandler: FINEST
javax.enterprise.system.container.web: INFO
javax.enterprise.system.util: INFO
javax.enterprise.resource.webcontainer.jsf.timing: INFO
javax: INFO
javax.enterprise.resource.corba: INFO
...
Command list-logger-levels executed successfully.

参照

コマンド行に asadmin help list-logger-levels と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

グローバルログレベルを設定する

「グローバルログレベル」は、すべてのロガーで記録されるイベントの種類を指定します。コンソールへのメッセージ出力のデフォルトレベルは INFO です。このレベルには、SEVERE と WARNING のメッセージも含まれます。

グローバルロギングは、logging.properties ファイルを編集して設定します。デフォルトの logging.properties ファイルは、domain.xml ファイルと同じディレクトリにあり、通常は domain-dir/config に保存されています。java.util.logging.config.file システムプロパティーにファイル名を指定して、別のファイルを選択することもできます。たとえば、次のように指定します。

java -Djava.util.logging.config.file=myfile

ConsoleHandler には、表示されるメッセージを制限する独立したログレベル設定があります。次に例を示します。

java.util.logging.ConsoleHandler.level = INFO 
java.util.logging.ConsoleHandler.formatter = 
com.sun.enterprise.server.logging.UniformLogFormatter

テキストエディタで、ConsoleHandler のログレベルを設定している行を検索して変更を行います。

ファイルを保存します。

例 7–2 すべてのロガーを対象とするグローバルログレベルの変更

ログレベルをルートレベルで設定すると、すべてのロガーのレベルを設定できます。この例では、すべてのロガーのログレベルを INFO に設定します。

.level= INFO

モジュールのロガーレベルを設定する

「モジュールログレベル」は、特定のロガーで記録するイベントの種類を指定します。コンソールへのメッセージ出力のデフォルトレベルは INFO です。このレベルには、SEVERE と WARNING のメッセージも含まれます。グローバルログレベルは、モジュールに固有のログレベルで上書きされます。

デフォルトでは、モジュールログレベルは FINE に設定されます。ロガーを設定する行は次のようになります。太字はモジュールを示しています。

#javax.enterprise.system.tools.level=FINE
#javax.enterprise.system.container.ejb.level=FINE
#javax.enterprise.system.core.security.level=FINE
#javax.enterprise.system.tools.admin.level=FINE
#javax.enterprise.level=FINE
#javax.enterprise.system.container.web.level=FINE

ログレベルの設定は動的な処理であるため、変更を有効にするために Enterprise Server を再起動する必要はありません。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-logger-levels(1) サブコマンドを使用して、既存のモジュールのロガーを一覧表示します。

set-log-level(1) サブコマンドを使用して、モジュールのログレベルを設定します。

選択できる値は、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、および FINEST です。

例 7–3 モジュールロガーのログレベルの設定

この例では、Web コンテナロガーのログレベルを FINE に設定します。

asadmin> set-log-level javax.enterprise.system.container.web.level=FINE
Command set-log-level executed successfully.

例 7–4 複数のロガーのログレベルの設定

この例では、セキュリティーロガーと Web コンテナロガーのログレベルを設定します。

asadmin> set-log-level javax.enterprise.system.core.security.level=FINE
javax.enterprise.system.container.web=WARNING 
Command set-log-level executed successfully.

参照

コマンド行に asadmin help set-log-level と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

サーバーログのローテーション

ログは logging.properties ファイルの設定に従って自動的にローテーションされます。これらの設定は管理コンソールを使用して変更できます。

ログファイルを手動でローテーションする

サーバーログファイルを手動でローテーションするには、リモートモードで rotate-log サブコマンドを使用します。デフォルトの場所にあるサーバーログは、ただちにタイムスタンプ付きの名前に変更され、新しいサーバーログが作成されます。

ログのローテーションは動的な処理であるため、変更を有効にするために Enterprise Server を再起動する必要はありません。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

rotate-log(1) サブコマンドを使用して、ログをローテーションします。

例 7–5 手動によるログファイルのローテーション

この例では、server.log ファイルの名前を yyyy-mm-dd_server.log に変更し、デフォルトの場所に新しい server.log ファイルを作成します。

asadmin> rotate-log
Command rotate-log executed successfuly.

参照

コマンド行に asadmin help rotate-log と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

ログ情報の表示

デフォルトでは、すべてのロギング情報は server.log ファイルに記録されます。このファイルは、通常 domain-dir /logs に保存されます。ロギング情報は、管理コンソールのログビューアを使用して表示できます。管理コンソールのロギング機能を使用する手順は、管理コンソールのオンラインヘルプで説明します。

特定のモジュールで収集された情報を表示するには、server.log ファイルをテキストエディタで開き、対象のモジュールを検索します。

第 8 章監視サービスの管理

この章では、asadmin コマンド行ユーティリティーを使用して、Sun GlassFish^TM Enterprise Server v3 のコンポーネントとサービスを監視する方法について説明します。Enterprise Server リソースを監視するための JConsole の設定手順についても説明します。

ここでは、次のテーマを取り上げます。

管理コンソールを使用して監視を行う場合の手順は、管理コンソールのオンラインヘルプで説明します。

REST インタフェースを使用して監視を行う方法については、「REST インタフェースによる Enterprise Server の管理」を参照してください。

監視について

「監視」は、パフォーマンスの向上や問題の解決のために、システムの統計を調査する処理です。監視サービスでは、1 秒あたりの要求数、平均応答時間、スループットなどの運用上の統計を追跡および表示できます。Enterprise Server に配備されたさまざまなコンポーネントとサービスの状態を監視することで、パフォーマンスのボトルネックの識別、障害の予測、根本原因の分析を行い、すべての機能を期待どおりに動作させることができます。監視によって収集されたデータは、パフォーマンスの調整や容量計画にも役立ちます。

Enterprise Server のこのリリースでは、監視はモジュール方式で公開され、多くのクライアントモジュールが監視統計にアクセスして、これらを表示することができます。これらのクライアントには、管理コンソール、asadmin ユーティリティー、AMX、および REST インタフェースが含まれます。

ここでは、次のテーマを取り上げます。

監視のツリー構造の仕組みについて

「監視可能なオブジェクト」は、監視の対象に指定できるコンポーネント、サブコンポーネント、またはサービスです。Enterprise Server は、ツリー構造を使って監視可能なオブジェクトを追跡します。ツリーは動的であるため、Enterprise Server のコンポーネントが追加または削除されるときに、ツリーも変更されます。

ツリー内の監視可能なオブジェクトは、そのオブジェクトで監視できる対象を正確に表す子オブジェクト (ノード) を持ちます。すべての子オブジェクトのアドレス指定にはドット (.) 文字を区切り記号として使用します。このようなドット区切りの名前は、「ドット表記名」と呼ばれます。ドット表記名の詳細は、dotted-names(5ASC) のマニュアルページを参照してください。

次のコマンドは、インスタンス server の監視可能な子オブジェクトを一覧表示します。

asadmin> list --monitor "server.*"

server.applications
server.connector-service
server.http-service
server.jms-service
server.containers.jruby
server.jvm
server.network
server.orb
server.resources 
server.security
server.thread-pool
server.transaction-service
server.web

各オブジェクトはドット表記名で表されます。また、監視可能なオブジェクトの特定の属性も、ドット表記名で指定します。たとえば、jvm オブジェクトには memory 属性と maxheapsize という名前の統計があります。この属性は次のドット表記名で表します。

server.jvm.memory.maxheapsize

オブジェクトが監視可能であっても、常に監視する必要はありません。監視を有効にする手順については、「監視の設定」を参照してください。

監視可能なオブジェクトのツリー構造について

監視可能なオブジェクトは、それぞれ階層的なツリー構造を持ちます。ツリー中の「*statistics」などの置換可能な文字列は、統計を表示できる属性の名前を表しています。

ここでは、次のノードのツリー階層を説明します。

アプリケーションのツリー階層

applications ツリーには、次のノードが含まれます。

server.applications
   |--- application1
   |    |--- ejb-module-1
   |    |        |--- ejb1 *
   |    |                  |--- bean-cache (for entity/sfsb) *
   |    |                  |--- bean-pool (for slsb/mdb/entity) *
   |    |                  |--- bean-methods
   |    |                       |---method1 *
   |    |                       |---method2 *
   |    |                  |--- timers (for s1sb/entity/mdb) *
   |    |--- web-module-1
   |    |        |--- virtual-server-1 *
   |    |                       |---servlet1  *
   |    |                       |---servlet2  *
   |--- standalone-web-module-1
   |    |        |----- virtual-server-2 *
   |    |                       |---servlet3 *
   |    |                       |---servlet4 *
   |    |        |----- virtual-server-3 *
   |    |                       |---servlet3 *(same servlet on different vs)
   |    |                       |---servlet5 *
   |--- standalone-ejb-module-1
   |    |        |--- ejb2 *
   |    |                  |--- bean-cache (for entity/sfsb) *
   |    |                  |--- bean-pool (for slsb/mdb/entity) *
   |    |                  |--- bean-methods
   |    |                       |--- method1 *
   |    |                       |--- method2 *
   |    |                  |--- timers (for s1sb/entity/mdb) *
   |--- jersey-application-1
   |    |--- jersey
   |    |        |--- resources
                           resource-0
                               hitcount
                                    *statistic   
   |--- application2

ドット表記名は、server.applications.hello.server.request.maxtime のようになります。

EJB の method ノード以下のドット表記名は、server.applications.ejbsfapp1.ejbsfapp1ejbmod1\.jar.SFApp1EJB1 のようになります。

Jersey のドット表記名は、server.applications.helloworld-webapp.jersey.resources.resource-0.hitcount .resourcehitcount-count のようになります。

使用可能な統計については、「EJB 統計」、「Jersey の統計」、および「Web の統計」を参照してください。

コネクタサービスのツリー階層

connector-service ツリーには、コネクタ接続プールなどの、プールの監視可能な属性が格納されます。connector-service ツリーには、次のノードが含まれます。

server.connector-service
        resource-adapter-1
             connection-pools
                  pool-1
             work-management

ドット表記名は、server.connector-service.resource-adapter-1.connection-pools.pool-1 のようになります。使用可能な統計については、「JMS サービスおよびコネクタサービスの統計」を参照してください。

HTTP サービスのツリー階層

http-service ツリー階層には、次のノードが含まれます。

server.http-service
       virtual-server
           request
               *statistic
       _asadmin
           request
               *statistic

virtual-server ノード以下のドット表記名は、server.http-service.virtual-server1.request.requestcount のようになります。使用可能な統計については、「HTTP サービスの統計」を参照してください。

JMS およびコンテナサービスのツリー階層

jms-service ツリーには、接続ファクトリ (リソースアダプタの接続プール) と作業管理 (Message Queue リソースアダプタ用) の監視可能な属性が格納されます。jms-service ツリーには、次のノードが含まれます。

server.jms-service
        connection-factories
             connection-factory-1
        work-management

connection-factories ノード以下のドット表記名は、server.jms-service.connection-factories.connection-factory-1 のようになります。この表記名は、この接続ファクトリのすべての統計を表します。使用可能な統計については、「JMS サービスおよびコネクタサービスの統計」を参照してください。

JRuby のツリー階層

jruby ツリーには、次のノードが含まれます。

server.containers.jruby.applications
         jruby-application
               *statistic
               http
                   *statistic
               runtime-pool
                   *statistic

使用可能な統計については、「JRuby の統計」を参照してください。

JVM のツリー階層

jvm ツリーには、次のノードが含まれます。

server.jvm
           class-loading-system
           compilation-system
           garbage-collectors
           memory
           operating-system
           runtime

memory ノード以下のドット表記名は、server.jvm.memory.maxheapsize のようになります。使用可能な統計については、「JVM の統計」を参照してください。

ネットワークのツリー階層

ネットワークの統計は、admin-listener 、http-listener-1、http-listener-2 などのネットワークリスナーに適用されます。network ツリーには、次のノードが含まれます。

server.network
          type-of-listener
              keep-alive
                    *statistic
              file-cache
                    *statistic
              thread-pool
                    *statistic
              connection-queue
                     *statistic

network ノード以下のドット表記名は、server.network.admin-listener.keep-alive.maxrequests-count のようになります。使用可能な統計については、「ネットワークの統計」を参照してください。

ORB のツリー階層

orb ツリーには、接続マネージャーの監視可能な属性が格納されます。orb ツリーには、次のノードが含まれます。

server.orb
    transport
        connectioncache
            inbound
                *statistic
            outbound
                *statistic

ドット表記名は、server.orb.transport.connectioncache.inbound.connectionsidle-count のようになります。使用可能な統計については、「ORB の統計 (接続マネージャー)」を参照してください。

リソースのツリー階層

resources ツリーには、JDBC 接続プールやコネクタ接続プールなどの、プールの監視可能な属性が格納されます。resources ツリーには、次のノードが含まれます。

server.resources
       connection-pool
           request
               *statistic

ドット表記名は、server.resources.jdbc-connection-pool1.numconnfree.count のようになります。使用可能な統計については、「リソースの統計 (接続プール)」を参照してください。

セキュリティーのツリー階層

security ツリーには、次のノードが含まれます。

server.security
       ejb
          *statistic
       web
          *statistic
       realm
          *statistic

ドット表記名は、server.security.realm.realmcount-starttime のようになります。使用可能な統計については、「セキュリティーの統計」を参照してください。

スレッドプールのツリー階層

thread-pool ツリー階層には、接続マネージャーの監視可能な属性が格納され、次のノードが含まれます。

server.thread-pool
                orb
                    threadpool
                            thread-pool-1
                                *statistic

ドット表記名は、server.thread-pool.orb.threadpool.thread-pool-1.averagetimeinqueue-current のようになります。使用可能な統計については、「スレッドプールの統計」を参照してください。

トランザクションサービスのツリー階層

transaction-service ツリーには、トランザクションをロールバックするためのトランザクションサブシステムに関して、監視可能な属性が格納されます。transaction-service ツリーには、次のノードが含まれます。

server.transaction-service
         statistic

ドット表記名は、server.tranaction-service.activeids のようになります。使用可能な統計については、「トランザクションサービスの統計」を参照してください。

Web のツリー階層

web ツリーには、次のノードが含まれます。

server.web
           jsp
              *statistic
           servlet
              *statistic
           session
              *statistic
           request
              *statistic

servlet ノードのドット表記名は、server.web.servlet.activeservletsloadedcount のようになります。使用可能な統計については、「Web モジュールの共通統計」を参照してください。

アドオンコンポーネントの監視について

一般的に、アドオンコンポーネントは、Enterprise Server が実行時に収集できる統計を生成します。監視機能を追加することで、アドオンコンポーネントは Enterprise Server の配布で提供されているコンポーネントと同じ方法で、Enterprise Server に統計を提供できるようになります。結果として、コンポーネントの製造元にかかわらず、インストールされているすべての Enterprise Server コンポーネントの統計を、同じ管理インタフェースを使用して監視することができます。

Enterprise Server を監視するためのツール

Enterprise Server のサービスとコンポーネントを監視するために、次の asadmin サブコマンドが提供されています。

enable-monitoring、disable-monitoring、または get および set サブコマンドは、監視を有効または無効にするために使用します。手順については、「監視の設定」を参照してください。
monitor --type サブコマンドは、特定のタイプの監視可能なオブジェクトの基本データを表示するために使用します。手順については、「共通の監視データの表示」を参照してください。
list --monitor サブコマンドは、monitor サブコマンドで監視できるオブジェクトを表示するために使用します。ガイドラインと手順については、「list および get サブコマンドを監視に使用する場合のガイドライン」を参照してください。
get サブコマンドは、属性や値などの総合的なデータをドット表記名で表示するために使用します。get サブコマンドでワイルドカードのパラメータを使用すると、任意の監視可能なオブジェクトで使用可能なすべての属性を表示できます。詳細は、「list および get サブコマンドを監視に使用する場合のガイドライン」を参照してください。

監視の設定

デフォルトでは、Enterprise Server の監視サービスは有効になっていますが、各モジュールの監視は有効になっていません。モジュールの監視を有効にするには、モジュールの監視レベルを LOW または HIGH に変更します。監視の必要がないオブジェクトでは、監視レベルを OFF のままにすることもできます。

LOW。作成数やバイト数などの簡単な統計が含まれます。
HIGH。簡単な統計に加え、メソッドの数や実行時間などのメソッドの統計が含まれます。
OFF。監視を行いません。パフォーマンスへの影響はありません。

ここでは、次のタスクを説明します。

監視を有効にする

enable-monitoring サブコマンドを使用して、監視サービス自体を有効にするか、個々のモジュールの監視を有効にします。監視はただちに有効になります。Enterprise Server の再起動は必要ありません。

set(1) サブコマンドを使用して、モジュールの監視を有効にすることもできます。set コマンドの使用は動的な手順ではないため、変更を有効にするには Enterprise Server を再起動する必要があります。

現在監視が有効になっているサービスとコンポーネントを確認します。

asadmin> get server.monitoring-service.module-monitoring-levels.*

この例の出力は、HTTP サービスでは監視が有効でなく (OFF)、その他のオブジェクトでは有効であることを示しています。

configs.config.server-config.monitoring-service.module-monitoring-levels.web-container=HIGH
       configs.config.server-config.monitoring-service.module-monitoring-levels.http-service=OFF
           configs.config.server-config.monitoring-service.module-monitoring-levels.jvm=HIGH

enable-monitoring(1) サブコマンドを使用して、監視を有効にします。

サーバーの再起動は必要ありません。

例 8–1 監視サービスの動的な有効化

この例では、個々のモジュールの監視に影響を与えずに、監視サービスを有効にします。

asadmin> enable-monitoring
Command enable-monitoring executed successfully

例 8–2 モジュールの監視の動的な有効化

この例では、ejb-container モジュールの監視を有効にします。

asadmin> enable-monitoring --level ejb-container=HIGH
Command enable-monitoring executed successfully

例 8–3 `set` サブコマンドによるモジュールの監視の有効化

この例では、監視レベルを HIGH に設定することで、HTTP サービスの監視を有効にします。変更を有効にするには、サーバーを再起動する必要があります。

asadmin> set server.monitoring-service.module-monitoring-levels.http-service=HIGH
Command set executed successfully

参照

コマンド行に asadmin help enable-monitoring と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

監視を無効にする

disable-monitoring サブコマンドを使用して、監視サービス自体を無効にするか、個々のモジュールの監視を無効にします。監視はただちに停止されます。Enterprise Server の再起動は必要ありません。

set(1) サブコマンドを使用して、モジュールの監視を無効にすることもできます。set コマンドの使用は動的な手順ではないため、変更を有効にするには Enterprise Server を再起動する必要があります。

現在監視が有効になっているサービスとコンポーネントを確認します。

asadmin get server.monitoring-service.module-monitoring-levels.*

この例の出力は、web-container 、http-service、および jvm で監視が有効であることを示しています。

configs.config.server-config.monitoring-service.module-monitoring-levels.web-container=HIGH
       configs.config.server-config.monitoring-service.module-monitoring-levels.http-service=HIGH
              configs.config.server-config.monitoring-service.module-monitoring-levels.jvm=HIGH

disable-monitoring(1) サブコマンドを使用して、サービスまたはモジュールの監視を無効にします。

サーバーの再起動は必要ありません。

例 8–4 監視サービスの動的な無効化

この例では、個々のモジュールの監視レベルを変更することなく、監視サービスを無効にします。

asadmin> disable-monitoring
Command disable-monitoring executed successfully

例 8–5 モジュールの監視の動的な無効化

この例では、指定したモジュールの監視を無効にします。これらのモジュールの監視レベルは OFF に設定されます。

asadmin> disable-monitoring --modules web-container,ejb-container
Command disable-monitoring executed successfully

例 8–6 `set` サブコマンドによる監視の無効化

この例では、HTTP サービスの監視を無効にします。変更を有効にするには、サーバーを再起動する必要があります。

asadmin> set server.monitoring-service.module-monitoring-levels.http-service=OFF
Command set executed successfully

参照

コマンド行に asadmin help disable-monitoring と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

共通の監視データの表示

monitor サブコマンドを使用して、共通で監視されるオブジェクトについての基本的なデータを表示できます。

共通の監視データを表示する

monitor サブコマンドの --type オプションを使用して、httplistener、jvm、webmodule などの、データを表示するオブジェクトを指定します。タイプを指定せずに monitor サブコマンドを使用すると、エラーメッセージが表示されます。

サブコマンドの出力は、表形式で続けて表示されます。--interval オプションを使用すると、特定の間隔 (デフォルトでは 30 秒) で出力を表示することができます。

始める前に

監視可能なオブジェクトのデータを表示する前に、対象のオブジェクトで監視を設定する必要があります。「監視を有効にする」を参照してください。

監視する監視可能なオブジェクトのタイプを決定します。

v3 では、jvm、httplistener 、および webmodule を選択できます。

monitor(1) サブコマンドを使用して、監視データを要求します。

例 8–7 共通の監視データの表示

この例では、インスタンス server の jvm タイプの共通データを要求します。

asadmin> monitor --type jvm server

UpTime(ms)                          Heap and NonHeap Memory(bytes)
current                   min        max        low        high       count

9437266                   8585216    619642880  0          0          93093888
9467250                   8585216    619642880  0          0          93093888

参照

コマンド行に asadmin help monitor と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

共通の監視統計

共通の監視統計について、次の節で説明します。

HTTP リスナーの共通統計

httplistener タイプに関して利用可能な統計を、次の表に示します。

表 8–1 HTTP リスナーの共通監視統計


Statistic	説明
`ec`	エラー数。エラー数の累積値です。
`mt`	最大時間。要求あたりの最長応答時間です。累積値ではなく、応答時間の中で最大の値です。
`pt`	処理時間。各要求の処理にかかった時間の累積値。処理時間は、要求全体での要求処理時間の平均になります。
`rc`	要求数。現時点までに処理された要求の累積数。

JVM の共通統計

jvm タイプに関して利用可能な統計を、次の表に示します。

表 8–2 JVM の共通監視統計


Statistic	説明
`count`	JVM マシンでの使用が保証されているメモリー量 (バイト)。
`high`	他のリリースとの互換性を維持するために使用されます。
`low`	他のリリースとの互換性を維持するために使用されます。
`max`	メモリー管理用として使用可能なメモリーの最大サイズ。
`min`	起動中のメモリー管理用に JVM マシンがオペレーティングシステムに要求するメモリー量の初期値 (バイト)。
`UpTime`	直前の起動日時からの JVM マシンの稼働時間 (ミリ秒)。

Web モジュールの共通統計

webmodule タイプに関して利用可能な統計を、次の表に示します。

表 8–3 Web モジュールの共通監視統計


Statistic	説明
`ajlc`	読み込まれているアクティブな JavaServer Pages^TM (JSP^TM) テクノロジページの数。
`asc`	現在のアクティブなセッション。
`aslc`	読み込まれているアクティブなサーブレットの数。
`ast`	アクティブなセッションの合計数。
`mjlc`	読み込まれている JSP ページの最大数。
`mslc`	読み込まれているサーブレットの最大数
`rst`	拒否されたセッションの合計数。
`st`	セッションの合計数。
`tjlc`	読み込まれている JSP ページの合計数。
`tslc`	読み込まれているサーブレットの合計数。

総合的な監視データの表示

ツリー構造に対して list および get サブコマンドをドット表記名を使用して適用することで、各統計の説明や測定単位など、より総合的な監視データを表示することができます。

ここでは、次のテーマを取り上げます。

`list` および `get` サブコマンドを監視に使用する場合のガイドライン

list コマンドと get コマンドでドット表記名を使用する場合は、基本として次の内容が前提となります。

list サブコマンドにドット表記名を指定する場合、ドット表記名のあとにワイルドカード (*) を指定しないと、現在のノードの直接の子だけが一覧表示されます。たとえば、次のサブコマンドは server ノードに属する直接の子をすべて表示します。
```
list --monitor server
```
list サブコマンドにドット表記名を指定する場合、ドット表記名の後ろに .* の形式のワイルドカードを指定すると、指定したノードから子ノードの階層ツリーが一覧表示されます。たとえば、次のサブコマンドは applications ノード以下のすべての子ノードを、それぞれの子ノードも含めてすべて表示します。
```
list --monitor server.applications.*
```
list サブコマンドにドット表記名を指定する場合、ドット表記名の前または後ろに、*dottedname、dotted * name、または dottedname * の形式のワイルドカードを指定すると、指定したマッチングパターンで表される正規表現に一致する、すべてのノードとその子ノードが一覧表示されます。
get サブコマンドのあとに .* または * を指定すると、指定したノードに含まれる属性とその値のセットが取得されます。

例として、list および get サブコマンドに resources ノードのドット表記名を使用した場合の出力を、次の表に示します。

表 8–4 リソースレベルのドット表記名の例


サブコマンド	ドット表記名	出力
`list --monitor`	`server.resources`	プール名の一覧。
`list --monitor`	`server.resources.connection-pool1`	属性は表示されず、代わりに「`get` `--monitor` サブコマンドを使用して、このノードの属性と値を表示してください」というメッセージが表示されます。
`get --monitor`	`server.resources.connection-pool1.*`	接続プールの属性に対応した属性と値のリスト。

ドット表記名の詳細は、dotted-names(5ASC) のマニュアルページを参照してください。

総合的な監視データを表示する

monitor サブコマンドは多くの状況で役に立ちますが、すべての監視可能なオブジェクトの完全なリストを表示することはできません。特定のオブジェクトタイプの総合的なデータを操作するには、list --monitor サブコマンドおよび get --monitor サブコマンドのあとに、監視可能なオブジェクトのドット表記名を指定します。

始める前に

監視可能なオブジェクトの情報を表示する前に、対象のオブジェクトで監視を設定する必要があります。必要な場合は、「監視を有効にする」を参照してください。

list(1) サブコマンドを使用して、監視が有効なオブジェクトを一覧表示します。

たとえば、次のサブコマンドは、インスタンス server で監視が有効になっているコンポーネントとサービスをすべて表示します。
asadmin> list --monitor "*" server.web server.connector-service server.orb server.jms-serviceserver.jvm server.applications server.http-service server.thread-pools

get(1) サブコマンドを使用して、監視対象のコンポーネントまたはサービスのデータを取得します。

例 8–8 特定のタイプの属性の表示

この例では、インスタンス serverで、オブジェクトタイプ jvm のすべての属性に関する情報を取得します。

asadmin> get --monitor server.jvm.*
server.jvm.class-loading-system.loadedclasscount = 3715
server.jvm.class-loading-system.totalloadedclasscount = 3731
server.jvm.class-loading-system.unloadedclasscount = 16
server.jvm.compilation-system.name-current = HotSpot Client Compiler
server.jvm.compilation-system.totalcompilationtime = 769
server.jvm.garbage-collectors.Copy.collectioncount = 285
server.jvm.garbage-collectors.Copy.collectiontime = 980
server.jvm.garbage-collectors.MarkSweepCompact.collectioncount = 2
server.jvm.garbage-collectors.MarkSweepCompact.collectiontime = 383
server.jvm.memory.committedheapsize = 23498752
server.jvm.memory.committednonheapsize = 13598720
server.jvm.memory.initheapsize = 0
server.jvm.memory.initnonheapsize = 8585216
server.jvm.memory.maxheapsize = 66650112
server.jvm.memory.maxnonheapsize = 100663296
server.jvm.memory.objectpendingfinalizationcount = 0
server.jvm.memory.usedheapsize = 19741184
server.jvm.memory.usednonheapsize = 13398352
server.jvm.operating-system.arch-current = x86
server.jvm.operating-system.availableprocessors = 2
server.jvm.operating-system.name-current = Windows XP
server.jvm.operating-system.version-current = 5.1
server.jvm.runtime.classpath-current = glassfish.jar
server.jvm.runtime.inputarguments-current = []
server.jvm.runtime.managementspecversion-current = 1.0
server.jvm.runtime.name-current = 4372@ABBAGANI_WORK
server.jvm.runtime.specname-current = Java Virtual Machine Specification
server.jvm.runtime.specvendor-current = Sun Microsystems Inc.
server.jvm.runtime.specversion-current = 1.0
server.jvm.runtime.uptime = 84813
server.jvm.runtime.vmname-current = Java HotSpot(TM) Client VM
server.jvm.runtime.vmvendor-current = Sun Microsystems Inc.
server.jvm.runtime.vmversion-current = 1.5.0_11-b03

例 8–9 監視可能なアプリケーションの表示

この例では、インスタンス server の監視可能なアプリケーションをすべて表示します。

asadmin> list --monitor server.applications.*
server.applications.app1
server.applications.app2
server.applications.app1.virtual-server1
server.applications.app2.virtual-server1

例 8–10 アプリケーションの属性の表示

この例では、アプリケーション hello のすべての属性に関する情報を取得します。

asadmin> get --monitor server.applications.hello.*
server.applications.hello.server.activatedsessionstotal = 0
server.applications.hello.server.activejspsloadedcount = 1
server.applications.hello.server.activeservletsloadedcount = 1
server.applications.hello.server.activesessionscurrent = 1
server.applications.hello.server.activesessionshigh = 1
server.applications.hello.server.errorcount = 0
server.applications.hello.server.expiredsessionstotal = 0
server.applications.hello.server.maxjspsloadedcount = 1
server.applications.hello.server.maxservletsloadedcount = 0
server.applications.hello.server.maxtime = 0
server.applications.hello.server.passivatedsessionstotal = 0
server.applications.hello.server.persistedsessionstotal = 0
server.applications.hello.server.processingtime = 0.0
server.applications.hello.server.rejectedsessionstotal = 0
server.applications.hello.server.requestcount = 0
server.applications.hello.server.sessionstotal = 
server.applications.hello.server.totaljspsloadedcount = 0
server.applications.hello.server.totalservletsloadedcount = 0

例 8–11 特定の属性の表示

この例では、インスタンス server の jvm 属性 runtime.vmversion-current に関する情報を取得します。

asadmin> get --monitor server.jvm.runtime.vmversion-current
server.jvm.runtime.vmversion-current = 10.0-b23

総合的な監視統計

目的の統計を表すドット表記名を指定することで、総合的な監視統計を取得できます。たとえば、次のドット表記名では、virtual-server1 の HTTP サービスに対する要求の累積数が表示されます。

server.http-service.virtual-server1.request.requestcount

監視可能なオブジェクトのそれぞれで使用可能な統計を、次の節の表に示します。

EJB 統計

EJB は、「アプリケーションのツリー階層」に示したオブジェクトツリー内に含まれます。次のドット表記名パターンを使用して、アプリケーションの統計を取得します。

server.applications.appname.ejbmodulename.ejbname.bean-cache.statistic

アプリケーションに関して利用可能な統計を、次の節で説明します。

EJB キャッシュの統計

EJB キャッシュの統計では、次のドット表記名パターンを使用します。

server.applications.appname.ejbmodulename.bean-cache.ejbname.statistic

EJB キャッシュに関して利用可能な統計を、次の表に示します。

表 8–5 EJB キャッシュの監視統計


Statistic	データ型	説明
`cachemisses`	RangeStatistic	ユーザー要求に対する Bean がキャッシュ内で見つからなかった回数。
`cachehits`	RangeStatistic	ユーザー要求に対するエントリがキャッシュ内で見つかった回数。
`numbeansincache`	RangeStatistic	キャッシュ内の Beans 数。これは現在のキャッシュサイズです。
`numpassivations`	CountStatistic	非活性化された Bean の数。ステートフルセッション Beans にのみ適用されます。
`numpassivationerrors`	CountStatistic	非活性化中に発生したエラーの数。ステートフルセッション Beans にのみ適用されます。
`numexpiredsessionsremoved`	CountStatistic	クリーンアップスレッドによって削除された期限切れセッションの数。ステートフルセッション Beans にのみ適用されます。
`numpassivationsuccess`	CountStatistic	非活性化が正常に終了した回数。ステートフルセッション Beans にのみ適用されます。

EJB コンテナの統計

EJB コンテナの統計では、次のドット表記名パターンを使用します。

server.applications.appname.ejbmodulename.container.ejbname

EJB コンテナに関して利用可能な統計を、次の表に示します。

表 8–6 EJB コンテナの監視統計


Statistic	データ型	説明
`createcount`	CountStatistic	特定の EJB に対する `create` メソッドの呼び出し回数。
`messagecount`	CountStatistic	特定のメッセージ駆動型 Bean に対して受信されたメッセージの数。
`methodreadycount`	RangeStatistic	`MethodReady` 状態にあるステートフルまたはステートレスセッション Beans の数。
`passivecount`	RangeStatistic	`Passive` 状態にあるステートフルセッション Beans の数。
`pooledcount`	RangeStatistic	プールされた状態にあるエンティティー Bean の数。
`readycount`	RangeStatistic	実行可能状態にあるエンティティー Bean の数。
`removecount`	CountStatistic	特定の EJB に対する `remove` メソッドの呼び出し回数。

EJB メソッドの統計

EJB メソッドの統計では、次のドット表記名パターンを使用します。

server.applications.appname.ejbmodulename.bean-methods.ejbname.statistic

EJB メソッドの呼び出しに関して利用可能な統計を、次の表に示します。

表 8–7 EJB メソッドの監視統計


Statistic	データ型	説明
`executiontime`	CountStatistic	成功または失敗した最後の操作実行時にメソッド実行に費やされた時間 (ミリ秒)。この情報は、EJB コンテナの監視が有効になっている場合に、ステートレスおよびステートフルのセッション Beans とエンティティー Beans に対して収集されます。
`methodstatistic`	TimeStatistic	特定の操作の呼び出し回数。その呼び出しにかかった合計時間など。
`totalnumerrors`	CountStatistic	メソッド実行時に例外が発生した回数。この情報は、EJB コンテナの監視が有効になっている場合に、ステートレスおよびステートフルのセッション Beans とエンティティー Beans に対して収集されます。
`totalnumsuccess`	CountStatistic	メソッドが正常に実行された回数。この情報は、EJB コンテナの監視が有効になっている場合に、ステートレスおよびステートフルのセッション Beans とエンティティー Beans に対して収集されます。

EJB プールの統計

EJB プールの統計では、次のドット表記名パターンを使用します。

server.applications.appname.ejbmodulename.bean-pool.ejbname.statistic

EJB プールに関して利用可能な統計を、次の表に示します。

表 8–8 EJB プールの監視統計


Statistic	データ型	説明
`jmsmaxmessagesload`	CountStatistic	メッセージ駆動型 Bean のサービスを提供するために JMS セッション内に一度にロード可能なメッセージの最大数。デフォルトは 1 です。メッセージ駆動型 Beans 用のプールにのみ適用されます。
`numbeansinpool`	RangeStatistic	関連付けられたプール内の EJB 数。プールの変化に関する情報を提供します。
`numthreadswaiting`	RangeStatistic	未使用 Beans を取得するために待機しているスレッドの数。これは、要求が過剰である可能性を示します。
`totalbeanscreated`	CountStatistic	関連付けられたプール内でデータ収集開始後に作成された Beans の数。
`totalbeansdestroyed`	CountStatistic	関連付けられたプール内でデータ収集開始後に破棄された Beans の数。

タイマーの統計

タイマーの統計では、次のドット表記名パターンを使用します。

server.applications.appname.ejbmodulename.timers.ejbname.statistic

タイマーに関して利用可能な統計を、次の表に示します。

表 8–9 タイマーの監視統計


Statistic	データ型	説明
`numtimerscreated`	CountStatistic	システム内で作成されたタイマーの数。
`numtimersdelivered`	CountStatistic	システムによって配信されたタイマーの数。
`numtimersremoved`	CountStatistic	システムから削除されたタイマーの数。

HTTP サービスの統計

HTTP サービスは、「HTTP サービスのツリー階層」に示したオブジェクトツリー内に含まれます。

HTTP サービスの統計を、次の節で説明します。

「HTTP サービス仮想サーバーの統計」

HTTP サービス仮想サーバーの統計

HTTP サービス仮想サーバーの統計では、次のドット表記名パターンを使用します。

server.http-service.virtual-server.request.statistic

仮想サーバーに関する HTTP サービスの統計を、次の表に示します。

表 8–10 HTTP サービス仮想サーバーの監視統計


Statistic	データ型	説明
`count200`	CountStatistic	状態コードが 200 である応答の数。
`count2xx`	CountStatistic	状態コードが 2xx の範囲内にある応答の数。
`count302`	CountStatistic	状態コードが 302 である応答の数。
`count304`	CountStatistic	状態コードが 304 である応答の数。
`count3xx`	CountStatistic	状態コードが 3xx の範囲内にある応答の数。
`count400`	CountStatistic	状態コードが 400 である応答の数。
`count401`	CountStatistic	状態コードが 401 である応答の数。
`count403`	CountStatistic	状態コードが 403 である応答の数。
`count404`	CountStatistic	状態コードが 404 である応答の数。
`count4xx`	CountStatistic	状態コードが 4xx の範囲内にある応答の数。
`count503`	CountStatistic	状態コードが 503 である応答の数。
`count5xx`	CountStatistic	状態コードが 5xx の範囲内にある応答の数。
`countother`	CountStatistic	状態コードが 2xx、3xx、4xx、および 5xx の範囲外である応答の数。
`errorcount`	CountStatistic	エラー回数の累計値。エラー回数は、応答コードが 400 以上になった場合の回数を表します。
`hosts`	StringStatistic	仮想サーバーのホスト (エイリアス) 名。
`maxtime`	CountStatistic	要求あたりの最長応答時間です。累積値ではなく、応答時間の中で最大の値です。
`processingtime`	CountStatistic	各要求の処理にかかった時間の累積値。処理時間は、要求数全体での要求処理時間の平均値になります。
`requestcount`	CountStatistic	現時点までに処理された要求の累積数。
`state`	StringStatistic	仮想サーバーの状態

Jersey の統計

Jersey は、「アプリケーションのツリー階層」に示したオブジェクトツリー内に含まれます。

Jersey の統計では、次のドット表記名パターンを使用します。

server.applications.jersey-application.jersey.resources.resource-0.hitcount.statistic

Jersey に関して利用可能な統計を、次の表に示します。

表 8–11 Jersey の統計


Statistic	データ型	説明
`resourcehitcount`	CountStatistic	このリソースクラスでのヒット数。
`rootresourcehitcount`	CountStatistic	このルートリソースクラスでのヒット数。

JMS サービスおよびコネクタサービスの統計

JMS サービスとコネクタサービスは、「JMS およびコンテナサービスのツリー階層」に示したオブジェクトツリー内に含まれます。

JMS サービスとコネクタサービスの統計を、次の節で説明します。

コネクタ接続プールの統計 (JMS)

JMS サービスとコネクタサービスの接続プールの統計では、次のドット表記名パターンを使用します。

server.connector-service.resource-adapter-1.connection-pool.statistic

コネクタ接続プールに関して利用可能な JMS サービスとコネクタサービスの統計を、次の表に示します。

表 8–12 コネクタ接続プールの監視統計 (JMS)


Statistic	データ型	説明
`averageconnwaittime`	CountStatistic	接続プールからサービスを受けるまでにかかった平均接続待ち時間。
`connectionrequestwaittime`	RangeStatistic	接続要求の最長待ち時間と最短待ち時間。現在の値は、プールのサービスを最後に受けた要求の待ち時間を示します。
`numconnfailedvalidation`	CountStatistic	開始時刻から前回のサンプリング時刻までの間に検証に失敗した接続プール内の接続の合計数。
`numconnused`	RangeStatistic	現在使用されている合計接続数に加え、過去に使用された接続の最大数 (ハイウォーターマーク) に関する情報も提供します。
`numconnfree`	RangeStatistic	前回のサンプリング時点におけるプール内の未使用接続の合計数。
`numconntimedout`	CountStatistic	開始時刻から前回のサンプリング時刻までの間にタイムアウトしたプール内の接続の合計数。
`numconncreated`	CountStatistic	前回のリセット後に作成された物理接続の数。
`numconndestroyed`	CountStatistic	前回のリセット後に破棄された物理接続の数。
`numconnacquired`	CountStatistic	プールから取得された論理接続の数。
`numconnreleased`	CountStatistic	プールに解放された論理接続の数。
`waitqueuelenght`	CountStatistic	サービスを受けるためにキュー内で待機している接続要求の数。

コネクタ作業管理の統計 (JMS)

JMS サービスとコネクタサービスの作業管理の統計では、次のドット表記名パターンを使用します。

server.connector-service.resource-adapter-1.work-management.statistic

コネクタ作業管理に関して利用可能な JMS サービスとコネクタサービスの統計を、次の表に示します。

表 8–13 コネクタ作業管理の監視統計 (JMS)


Statistic	データ型	説明
`activeworkcount`	RangeStatistic	コネクタによって実行された作業オブジェクトの数。
`completedworkcount`	CountStatistic	完了した作業オブジェクトの数。
`rejectedworkcount`	CountStatistic	Enterprise Server によって拒否された作業オブジェクトの数。
`submittedworkcount`	CountStatistic	コネクタモジュールによって送信された作業オブジェクトの数。
`waitqueuelength`	RangeStatistic	実行される前にキュー内で待機している作業オブジェクトの数。
`workrequestwaittime`	RangeStatistic	作業オブジェクトが実行されるまでの最長待ち時間と最短待ち時間。

JRuby の統計

JRuby は、「JRuby のツリー階層」に示したオブジェクトツリー内に含まれます。

JRuby に関して利用可能な統計を、次の節で説明します。

JRuby コンテナの統計

JRuby コンテナの統計では、次のドット表記名パターンを使用します。

server.containers.jruby.applications.jruby-application.statistic

JRuby コンテナに関して利用可能な統計を、次の表に示します。

表 8–14 JRuby コンテナの統計


Statistic	データ型	説明
`environment`	StringStatistic	JRuby アプリケーション環境。
`appname`	StringStatistic	Ruby アプリケーション名。
`contextpath`	StringStatistic	Ruby アプリケーションのコンテキストパス。
`jrubyversion`	StringStatistic	JRuby のバージョン。
`rubyframework`	StringStatistic	Ruby アプリケーションフレームワーク。

JRuby ランタイムの統計

JRuby ランタイムの統計では、次のドット表記名パターンを使用します。

server.containers.jruby.applications.jruby-application.runtime.statistic

JRuby ランタイムに関して利用可能な統計を、次の表に示します。

表 8–15 JRuby ランタイムの統計


Statistic	データ型	説明
`activeruntimes`	CountStatistic	現在アクティブなランタイムの数。
`appname`	StringStatistic	Ruby アプリケーション名。
`hardmaximum`	CountStatistic	アクティブなランタイムの最大数。
`hardminimum`	CountStatistic	アクティブなランタイムの最小数。

JRuby HTTP サービスの統計

JRuby HTTP サービスの統計では、次のドット表記名パターンを使用します。

server.containers.jruby.applications.jruby-application.http.statistic

JRuby HTTP サービスに関して利用可能な統計を、次の表に示します。

表 8–16 JRuby HTTP サービスの統計


Statistic	データ型	説明
`address`	StringStatistic	サーバーアドレス。
`appname`	StringStatistic	Ruby アプリケーション名。
`averageprocessingtime`	CountStatistic	平均要求処理時間 (ミリ秒)。
`contextpath`	StringStatistic	Ruby アプリケーションのコンテキストパス。
`count2xx`	CountStatistic	状態コードが 2xx の範囲内にある応答の数。
`count200`	CountStatistic	状態コードが 200 である応答の数。
`count3xx`	CountStatistic	状態コードが 3xx の範囲内にある応答の数。
`count302`	CountStatistic	状態コードが 302 である応答の数。
`Count304`	CountStatistic	状態コードが 304 である応答の数。
`count4xx`	CountStatistic	状態コードが 4xx の範囲内にある応答の数。
`count400`	CountStatistic	状態コードが 400 である応答の数。
`count401`	CountStatistic	状態コードが 401 である応答の数。
`count403`	CountStatistic	状態コードが 403 である応答の数。
`count404`	CountStatistic	状態コードが 404 である応答の数。
`count5xx`	CountStatistic	状態コードが 5xx の範囲内にある応答の数。
`count503`	CountStatistic	状態コードが 503 である応答の数。
`countother`	CountStatistic	状態コードがその他の値である応答の数。
`errorcount`	CountStatistic	状態コードが 400 より大きい応答の数。
`requests/seconds`	CountStatistic	1 秒あたりの要求数。

JVM の統計

JVM は、「JVM のツリー階層」に示したオブジェクトツリー内に含まれます。

Java プラットフォームの仮想マシン (Java^TM 仮想マシン、または JVM マシン) に関して利用可能な統計を、次の節で説明します。

JVM クラス読み込みシステムの統計

JVM クラス読み込みシステムの統計では、次のドット表記名パターンを使用します。

server.jvm.class-loading-system.statistic

Java SE では、JVM から追加の監視情報を取得できます。監視レベルを「低」に設定すると、この追加情報の表示が有効になります。監視レベルを「高」に設定すると、さらにシステム内の各ライブスレッドに関する情報も表示されます。Java SE で利用可能な追加監視機能の詳細は、『Monitoring and Management for the Java Platform』を参照してください。この文書は、http://java.sun.com/javase/6/docs/technotes/guides/management/ で入手できます。

Java SE 監視ツールについては、http://java.sun.com/javase/6/docs/technotes/tools/#manage を参照してください。

Java SE の JVM で利用可能なクラス読み込み関連の統計を、次の表に示します。

表 8–17 Java SE のクラス読み込みに関する JVM の監視統計


Statistic	データ型	説明
`loadedclasscount`	CountStatistic	JVM 内に現在読み込まれているクラスの数。
`totalloadedclasscount`	CountStatistic	JVM の実行開始後に読み込まれたクラスの合計数。
`unloadedclasscount`	CountStatistic	JVM の実行開始後に JVM から読み込み解除されたクラスの数。

Java SE の JVM で利用可能なスレッド関連の統計を、次の図に示します。

表 8–18 Java SE に関する JVM の監視統計 - スレッド


Statistic	データ型	説明
`allthreadids`	StringStatistic	すべてのライブスレッド ID のリスト。
`currentthreadcputime`	CountStatistic	CPU 時間の測定が有効になっている場合は、現在のスレッドに対する CPU 時間 (ナノ秒)。CPU 時間の測定が無効になっている場合は、-1 が返されます。
`daemonthreadcount`	CountStatistic	ライブデーモンスレッドの現在の数。
`monitordeadlockedthreads`	StringStatistic	監視デッドロックが発生しているスレッド ID のリスト。
`peakthreadcount`	CountStatistic	JVM 起動後またはピーク値リセット後におけるライブスレッドのピーク数。
`threadcount`	CountStatistic	ライブデーモンスレッドと非デーモンスレッドの現在の数。
`totalstartedthreadcount`	CountStatistic	JVM が起動されて以来、作成されたスレッド、起動されたスレッド、作成および起動されたスレッドの合計数。

JVM コンパイルシステムの統計

JVM コンパイルシステムの統計では、次のドット表記名パターンを使用します。

server.jvm.compilation-system.statistic

Java SE の JVM のコンパイルに関して利用可能な統計を、次の表に示します。

表 8–19 Java SE のコンパイルに関する JVM の監視統計


Statistic	データ型	説明
`name-current`	StringStatistic	現在のコンパイラの名前。
`totalcompilationtime`	CountStatistic	コンパイルに費やされた時間の累計 (ミリ秒)。

JVM ガベージコレクタの統計

JVM ガベージコレクタの統計では、次のドット表記名パターンを使用します。

server.jvm.garbage-collectors.statistic

Java SE の JVM のガベージコレクションに関して利用可能な統計を、次の表に示します。

表 8–20 Java SE のガベージコレクタに関する JVM の監視統計


Statistic	データ型	説明
`collectioncount`	CountStatistic	実行されたコレクションの合計回数。
`collectiontime`	CountStatistic	コレクションに費やされた時間の累計 (ミリ秒)。

JVM メモリーの統計

JVM メモリーの統計では、次のドット表記名パターンを使用します。

server.jvm.memory.statistic

Java SE の JVM のメモリーに関して利用可能な統計を、次の表に示します。

表 8–21 Java SE のメモリーに関する JVM の監視統計


Statistic	データ型	説明
`committedheapsize`	CountStatistic	JVM 用としてコミットされたヒープメモリーのサイズ (バイト)。
`committednonheapsize`	CountStatistic	JVM 用としてコミットされた非ヒープメモリーのサイズ (バイト)。
`initheapsize`	CountStatistic	JVM が最初に要求したヒープのサイズ。
`initnonheapsize`	CountStatistic	JVM が最初に要求した非ヒープ領域のサイズ
`maxheapsize`	CountStatistic	メモリー管理用として使用可能なヒープメモリーの最大サイズ (バイト)。
`maxnonheapsize`	CountStatistic	メモリー管理用として使用可能な非ヒープメモリーの最大サイズ (バイト)。
`objectpendingfinalizationcount`	CountStatistic	ファイナライズを保留しているオブジェクトの概算数。
`usedheapsize`	CountStatistic	現在使用されているヒープのサイズ。
`usednonheapsize`	CountStatistic	現在使用されている非ヒープ領域のサイズ。

JVM オペレーティングシステムの統計

JVM オペレーティングシステムの統計では、次のドット表記名パターンを使用します。

server.jvm.operating-system.statistic

Java SE の JVM マシンのオペレーティングシステムに関して利用可能な統計を、次の表に示します。

表 8–22 Java SE のオペレーティングシステムに関する JVM の統計


Statistic	データ型	説明
`arch-current`	StringStatistic	オペレーティングシステムのアーキテクチャー。
`availableprocessors`	CountStatistic	JVM が使用できるプロセッサの数。
`name-current`	StringStatistic	オペレーティングシステムの名前。
`version-current`	StringStatistic	オペレーティングシステムのバージョン。

JVM ランタイムの統計

JVM ランタイムの統計では、次のドット表記名パターンを使用します。

server.jvm.runtime.statistic

Java SE の JVM ランタイムに関して利用可能な統計を、次の表に示します。

表 8–23 Java SE のランタイムに関する JVM の監視統計


Statistic	データ型	説明
`classpath-current`	StringStatistic	システムクラスローダーがクラスファイルの検索時に使用するクラスパス。
`inputarguments-current`	StringStatistic	JVM に渡される入力引数 (`main` メソッドへの引数は含まない)。
`managementspecversion-current`	StringStatistic	JVM で実装される管理仕様のバージョン。
`name-current`	StringStatistic	実行中の JVM を表す名前
`specname-current`	StringStatistic	JVM 仕様の名前。
`specvendor-current`	StringStatistic	JVM 仕様のベンダー。
`specversion-current`	StringStatistic	JVM 仕様のバージョン。
`uptime`	CountStatistic	JVM の稼働時間 (ミリ秒)。
`vmname-current`	StringStatistic	JVM 実装の名前。
`vmvendor-current`	StringStatistic	JVM 実装のベンダー。
`vmversion-current`	StringStatistic	JVM 実装のバージョン。

ネットワークの統計

ネットワークは、「ネットワークのツリー階層」に示したオブジェクトツリー内に含まれます。

ネットワークの統計を、次の節で説明します。

ネットワークキープアライブの統計

ネットワークキープアライブの統計では、次のドット表記名パターンを使用します。

server.network.type-of-listener.keep-alive.statistic

ネットワークキープアライブに関して利用可能な統計を、次の表に示します。

表 8–24 ネットワークキープアライブの統計


Statistic	データ型	説明
`countconnections`	CountStatistic	キープアライブモードの接続の数。
`counttimeouts`	CountStatistic	タイムアウトしたキープアライブ接続の数。
`secondstimeouts`	CountStatistic	キープアライブのタイムアウト値 (秒)。
`maxrequests`	CountStatistic	1 つのキープアライブ接続で許可されている要求の最大数。
`countflushes`	CountStatistic	閉じられたキープアライブ接続の数。
`counthits`	CountStatistic	キープアライブモードの接続で受信した要求の数。
`countrefusals`	CountStatistic	拒否されたキープアライブ接続の数。

ネットワーク接続キューの統計

ネットワーク接続キューの統計では、次のドット表記名パターンを使用します。

server.network.type-of-listener.connection-queue.statistic

ネットワーク接続キューに関して利用可能な統計を、次の表に示します。

表 8–25 ネットワーク接続キューの統計


Statistic	データ型	説明
`countopenconnections`	CountStatistic	開いている接続またはアクティブな接続の数。
`countoverflows`	CountStatistic	キューがいっぱいになったために接続を格納できなかった回数。
`countqueued`	CountStatistic	キュー内に現在存在している接続の数。
`countqueued15minutesaverage`	CountStatistic	キューに格納されている接続数の過去 15 分間における平均値。
`countqueued1minuteaverage`	CountStatistic	キューに格納されている接続数の過去 1 分間における平均値。
`countqueued5minutesaverage`	CountStatistic	キューに格納されている接続数の過去 5 分間における平均値。
`counttotalconnections`	CountStatistic	受け付けられた接続の合計数。
`counttotalqueued`	CountStatistic	キューに格納された接続の合計数。
`maxqueued`	CountStatistic	接続キューの最大サイズ。
`peakqueued`	CountStatistic	キュー内に同時に存在していた接続の最大数。
`tickstotalqueued`	CountStatistic	接続がキュー内で費やした合計ティック数 (未サポート)。

ネットワークファイルキャッシュの統計

ネットワークファイルキャッシュの統計では、次のドット表記名パターンを使用します。

server.network.type-of-listener.file-cache.statistic

ネットワークファイルキャッシュに関して利用可能な統計を、次の表に示します。

表 8–26 ネットワークファイルキャッシュの統計


Statistic	データ型	説明
`contenthits`	CountStatistic	キャッシュファイルコンテンツのヒット数。
`contentmisses`	CountStatistic	キャッシュファイルコンテンツの失敗数。
`heapsize`	CountStatistic	現在のキャッシュサイズ (バイト)。
`hits`	CountStatistic	キャッシュ検索のヒット数。
`infohits`	CountStatistic	キャッシュファイル情報のヒット数。
`infomisses`	CountStatistic	キャッシュファイル情報の失敗数。
`mappedmemorysize`	CountStatistic	キャッシュ用に割り当てられたメモリーのサイズ (バイト)。
`maxheapsize`	CountStatistic	キャッシュ用のヒープ領域の最大サイズ (バイト)。
`maxmappedmemorysize`	CountStatistic	キャッシュ用の最大メモリーマップサイズ (バイト)。
`misses`	CountStatistic	キャッシュ検索に失敗したデータタイプの数。
`opencacheentries`	CountStatistic	現在開いているキャッシュエントリの数。

ネットワークスレッドプールの統計

ネットワークスレッドプールの統計では、次のドット表記名パターンを使用します。

server.network.type-of-listener.thread-pool.statistic

ネットワークスレッドプールに関して利用可能な統計を、次の表に示します。

表 8–27 ネットワークスレッドプールの統計


Statistic	データ型	説明
`corethreads`	CountStatistic	スレッドプールに含まれるスレッドのコア数。
`currentthreadcount`	CountStatistic	リスナースレッドプール内に現在存在している要求処理スレッドの数。
`currentthreadsbusy`	CountStatistic	要求処理用リスナースレッドプール内で現在使用されている要求処理スレッドの数。
`maxthreads`	CountStatistic	スレッドプールで許可されているスレッドの最大数。
`totalexecutedtasks`	CountStatistic	スレッドプールで実行されたタスクの合計数。

ORB の統計 (接続マネージャー)

ORB は、「ORB のツリー階層」に示したオブジェクトツリー内に含まれます。

ORB の統計では、次のドット表記名パターンを使用します。

server.orb.transport.connectioncache.inbound.statistic
server.orb.transport.connectioncache.outbound.statistic

ORB の接続マネージャーに関して利用可能な統計を、次の表に示します。

表 8–28 ORB の監視統計 (接続マネージャー)


Statistic	データ型	説明
`connectionsidle`	CountStatistic	ORB への接続のうち、アイドル状態の接続の合計数。
`connectionsinuse`	CountStatistic	ORB への接続のうち、使用中の接続の合計数。
`totalconnections`	BoundedRangeStatistic	ORB への接続の合計数。

リソースの統計 (接続プール)

接続プールリソースを監視することで、実行時にパフォーマンスの測定やリソースの使用状況の取得を行えます。接続は負荷が大きく、アプリケーションでは頻繁にパフォーマンスのボトルネックとなります。接続プールの解放状況と新しい接続の作成状況、および特定のプールから接続を取得するために待機中であるスレッドの数を監視することが重要です。

接続プールリソースは、「リソースのツリー階層」に示したオブジェクトツリー内に含まれます。

接続プールの統計では、次のドット表記名パターンを使用します。

server.resources.connection-pool.statistic

接続プールの統計を、次の表に示します。

表 8–29 リソースの監視統計 (接続プール)


Statistic	データ型	説明
`averageconnwaittime`	CountStatistic	成功した接続要求あたりの平均待ち時間。
`connrequestwaittime`	RangeStatistic	前回のサンプリング以降の、接続要求の最長待ち時間と最短待ち時間 (ミリ秒)。現在の値は、プールで処理された直前の要求の待ち時間を示します。
`numconnfailedvalidation`	CountStatistic	開始時刻から前回のサンプリング時刻までの間に検証に失敗した接続プール内の接続数。
`numconnused`	RangeStatistic	現在使用されている接続数と、過去に使用された接続の最大数 (ハイウォーターマーク) に関する情報。
`numconnfree`	RangeStatistic	前回のサンプリング時点におけるプール内の未使用の接続の数。
`numconntimedout`	CountStatistic	開始時刻から前回のサンプリング時刻までの間にタイムアウトしたプール内の接続の数。
`numconncreated`	CountStatistic	前回のリセット後にプールによって作成された物理接続の数。
`numconndestroyed`	CountStatistic	前回のリセット後に破棄された物理接続の数。
`numconnacquired`	CountStatistic	前回のサンプリング以降に、プールから取得された論理接続の数。
`numconnreleased`	CountStatistic	前回のサンプリング以降に、プールに戻された接続の数。
`numconnnotsuccessfullymatched`	CountStatistic	マッチング中に拒否された接続の数。
`numconnsuccessfullymatched`	CountStatistic	マッチングに成功した接続の数。
`numpotentialconnleak`	CountStatistic	潜在的な接続リークの数。
`waitqueuelength`	CountStatistic	キュー内で処理されるのを待機している接続要求の数。

セキュリティーの統計

セキュリティーは、「セキュリティーのツリー階層」に示したオブジェクトツリー内に含まれます。

セキュリティーに関して利用可能な統計を、次の節で説明します。

EJB セキュリティーの統計

EJB セキュリティーの統計では、次のドット表記名パターンを使用します。

server.security.ejb.statistic

EJB セキュリティーに関して利用可能な統計を、次の表に示します。

表 8–30 EJB セキュリティーの監視統計


Statistic	データ型	説明
`policyconfigurationcount`	CountStatistic	ポリシー構成の数。
`securitymanagercount`	CountStatistic	EJB セキュリティーマネージャーの数。

Web セキュリティーの統計

Web セキュリティーの統計では、次のドット表記名パターンを使用します。

server.security.web.statistic

Web セキュリティーに関して利用可能な統計を、次の表に示します。

表 8–31 Web セキュリティーの監視統計


Statistic	データ型	説明
`websecuritymanagercount`	CountStatistic	セキュリティーマネージャーの数。
`webpolicyconfigurationcount`	CountStatistic	ポリシー構成オブジェクトの数。

レルムセキュリティーの統計

レルムセキュリティーの統計では、次のドット表記名パターンを使用します。

server.security.realm.statistic

レルムセキュリティーに関して利用可能な統計を、次の表に示します。

表 8–32 レルムセキュリティーの監視統計


Statistic	データ型	説明
`realmcount`	CountStatistic	レルムの数。

スレッドプールの統計

スレッドプールは、「スレッドプールのツリー階層」に示したオブジェクトツリー内に含まれます。

スレッドプールに関して利用可能な統計を、次の節で説明します。

スレッドプールの監視統計

スレッドプールの統計では、次のドット表記名パターンを使用します。

server.thread-pool.thread-pool.statistic

スレッドプールに関して利用可能な統計を、次の表に示します。

表 8–33 スレッドプールの監視統計


Statistic	データ型	説明
`averagetimeinqueue`	BoundedRangeStatistic	キュー内の要求が処理されるまでの平均待ち時間 (ミリ秒)。
`averageworkcompletiontime`	BoundedRangeStatistic	割り当てが完了するまでの平均時間 (ミリ秒)。
`currentbusythreads`	CountStatistic	ビジースレッドの数。
`currentnumberofthreads`	BoundedRangeStatistic	要求処理スレッドの現在の数。
`numberofavailablethreads`	CountStatistic	使用可能なスレッドの数。
`numberofworkitemsinqueue`	BoundedRangeStatistic	キューで待機している作業項目の現在の数。
`totalworkitemsadded`	CountStatistic	前回のサンプリング以降に、作業キューに追加された作業項目の合計。

Java SE に関する JVM の統計 - スレッド情報

Java SE の JVM で利用可能な ThreadInfo 関連の統計を、次の図に示します。

表 8–34 Java SE に関する JVM の監視統計 - スレッド情報


Statistic	データ型	説明
`blockedcount`	CountStatistic	このスレッドが `BLOCKED` 状態に入った合計回数。
`blockedtime`	CountStatistic	このスレッドが `BLOCKED` 状態に入ったあと経過した時間 (ミリ秒)。スレッド競合監視が無効になっている場合は、-1 が返されます。
`lockname`	StringStatistic	このスレッドが獲得をブロックされている監視ロック、またはこのスレッドが `Object.wait` メソッド経由で通知されるのを待っている監視ロックの文字列表現。
`lockownerid`	CountStatistic	このスレッドのブロック対象オブジェクトの監視ロックを保持しているスレッドの ID。
`lockownername`	StringStatistic	このスレッドのブロック対象オブジェクトの監視ロックを保持しているスレッドの名前。
`stacktrace`	StringStatistic	このスレッドに関連付けられているスタックトレース。
`threadid`	CountStatistic	スレッドの ID。
`threadname`	StringStatistic	スレッドの名前
`threadstate`	StringStatistic	スレッドの状態。
`waitedtime`	CountStatistic	スレッドが `WAITING` 状態に入ったあと経過した時間 (ミリ秒)。スレッド競合監視が無効になっている場合は、-1 が返されます。
`waitedcount`	CountStatistic	スレッドが `WAITING` 状態または `TIMED_WAITING` 状態になった合計回数。

トランザクションサービスの統計

トランザクションサービスを使用すると、クライアントはトランザクションサブシステムをフリーズして、トランザクションをロールバックしたり、フリーズ時点で処理中であったトランザクションを特定することができます。トランザクションサービスは、「トランザクションサービスのツリー階層」に示したオブジェクトツリー内に含まれます。

トランザクションサービスの統計では、次のドット表記名パターンを使用します。

server.transaction-service.statistic

トランザクションサービスに関して利用可能な統計を、次の表に示します。

表 8–35 トランザクションサービスの監視統計


Statistic	データ型	説明
`activecount`	CountStatistic	現在アクティブなトランザクションの数。
`activeids`	StringStatistic	現在アクティブなトランザクションの ID。それらの各トランザクションは、トランザクションサービスのフリーズ後にロールバックすることができます。
`committedcount`	CountStatistic	コミットされたトランザクションの数。
`rolledbackcount`	CountStatistic	ロールバックされたトランザクションの数。
`state`	StringStatistic	トランザクションがフリーズされたかどうかを示します。

Web の統計

Web モジュールは、「Web のツリー階層」に示したオブジェクトツリー内に含まれます。

利用可能な Web の統計を、次の節で説明します。

Web モジュールサーブレットの統計

Web モジュールサーブレットの統計では、次のドット表記名パターンを使用します。

server.applications.web-module.virtual-server.servlet.statistic
server.applications.application.web-module.virtual-server.servlet.statistic

利用可能な Web モジュールサーブレットの統計を、次の表に示します。

表 8–36 Web モジュールサーブレットの統計


Statistic	データ型	説明
`errorcount`	CountStatistic	応答コードが 400 以上になった場合の累計件数。
`maxtime`	CountStatistic	Web コンテナの要求待ち状態の最大継続時間。
`processingtime`	CountStatistic	各要求の処理に要した時間の累計値。この処理時間は、要求処理時間を要求数で割って得られた平均値です。
`requestcount`	CountStatistic	その時点までに処理された要求の合計数。
`servicetime`	CountStatistic	応答時間の総計 (ミリ秒)。

Web JSP の統計

Web JSP の統計では、次のドット表記名パターンを使用します。

server.applications.web-module.virtual-server.statistic
server.applications.application.web-module.virtual-server.statistic

利用可能な Web JSP 統計を、次の表に示します。

表 8–37 Web JSP の監視統計


Statistic	データ型	説明
`jspcount-current`	RangeStatistic	アクティブな JSP ページの数。
`jsperrorcount`	CountStatistic	JSP ページの呼び出しでトリガーされたエラーの合計数。
`jspreloadedcount`	CountStatistic	再読み込みされた JSP ページの合計数。
`totaljspcount`	CountStatistic	これまでに読み込まれた JSP ページの合計数。

Web 要求の統計

Web 要求の統計では、次のドット表記名パターンを使用します。

server.applications.web-module.virtual-server.statistic
server.applications.application.web-module.virtual-server.statistic

利用可能な Web 要求統計を、次の表に示します。

表 8–38 Web 要求の監視統計


Statistic	データ型	説明
`errorcount`	CountStatistic	エラー回数の累計値。エラー回数は、応答コードが 400 以上になった場合の回数を表します。
`maxtime`	CountStatistic	要求あたりの最長応答時間です。累積値ではなく、応答時間の中で最大の値です。
`processingtime`	CountStatistic	平均要求処理時間 (ミリ秒)。
`requestcount`	CountStatistic	現時点までに処理された要求の累積数。

Web サーブレットの統計

Web サーブレットの統計では、次のドット表記名パターンを使用します。

server.applications.web-module.virtual-server.statistic
server.applications.application.web-module.virtual-server.statistic

利用可能な Web サーブレットの統計を、次の表に示します。

表 8–39 Web サーブレットの監視統計


Statistic	データ型	説明
`activeservletsloadedcount`	RangeStatistic	現在読み込まれているサーブレットの数。
`servletprocessingtimes`	CountStatistic	サーブレット処理時間の累積値 (ミリ秒)。
`totalservletsloadedcount`	CountStatistic	Web モジュールに読み込まれたサーブレットの累積数。

Web セッションの統計

Web セッションの統計では、次のドット表記名パターンを使用します。

server.applications.web-module.virtual-server.statistic
server.applications.application.web-module.virtual-server.statistic

利用可能な Web セッションの統計を、次の表に示します。

表 8–40 Web セッションの監視統計


Statistic	データ型	説明
`activatedsessionstotal`	CountStatistic	アクティブ化されたセッションの合計数。
`activesessionscurrent`	RangeStatistic	現在のアクティブセッションの数。
`activesessionshigh`	CountStatistic	現在のアクティブセッションの最大数。
`expiredsessionstotal`	CountStatistic	期限切れセッションの合計数。
`passivatedsessionstotal`	CountStatistic	パッシブ化されたセッションの合計数。
`persistedsessionstotal`	CountStatistic	持続化されたセッションの合計数。
`rejectedsessionstotal`	CountStatistic	拒否されたセッションの合計数。
`sessionstotal`	CountStatistic	作成されたセッションの合計数。

Enterprise Server の監視データを表示するための JConsole の設定

Java SE には、MBean Server に接続し、サーバーに登録されている MBean を表示するためのツールが用意されています。JConsole は一般的な JMX コネクタクライアントであり、標準 Java SE ディストリビューションの一部として利用できます。Enterprise Server で使用できるように JConsole を設定すると、Enterprise Server は JMX コネクタのサーバー側となり、JConsole は JMX コネクタのクライアント側となります。

JConsole を Enterprise Server に接続する

Java SE 6 では、Platform MBean Server を含めること、および仮想マシンを設定するための管理対象 Bean (MBean) を含めることにより、仮想マシンの管理と監視を拡張します。

すべての MBean を表示するために、Enterprise Server にはシステム JMX コネクタサーバーという標準 JMX コネクタサーバーの構成が用意されています。Enterprise Server の起動時に、この JMX コネクタサーバーのインスタンスが起動します。規格に準拠する JMX コネクタクライアントはすべて、JMX コネクタサーバーを使用してサーバーに接続できます。

デフォルトでは、Enterprise Server はセキュリティー保護されていないシステム JMX コネクタサーバーを使用するように設定されています。この設定で問題がある場合は、JMX コネクタを削除できます。ただし、address を locahost に設定することにより、特定の IP アドレス (たとえば、ループバックアドレス) へのアクセスが制限される場合があります。

ドメインを起動します。

手順については、「ドメインの起動」を参照してください。

JDK_HOME /bin/jconsole の形式を使用して、JConsole を起動します。

次に例を示します。
/usr/java/bin/jconsole
JConsole の「Connect to Agent」ウィンドウが表示されます。

「リモート」タブをクリックし、ホスト名とポート番号を入力します。

JConsole には常にリモートで接続してください。リモート以外で接続した場合は、MBean が自動的に読み込まれません。

「接続」をクリックします。

「Remote Process」テキストボックスに、JMX サービス URL を指定します。

次に例を示します。

service:jmx:rmi:///jndi/rmi://localhost:8686/jmxrmi

JMX サービス URL は、サーバーによって起動時に発行され、次のような形式になります。

[#|2009-12-03T10:25:17.737-0800|INFO|glassfishv3.0|
javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=20;
_ThreadName=Thread-26;|JMXStartupService: Started JMXConnector, JMXService 
URL = service:jmx:rmi://localhost:8686/jndi/rmi://localhost:8686/jmxrmi|#]

ただし、ほとんどの場合は、簡単に host:port (192.168.1.150:8686 など) を入力するだけで十分です。長いサービス URL は必要ありません。

注 –

localhost の代わりに別のホスト名を指定することもできます。jmx-connector の構成が変更されている場合は、デフォルトのポート番号 (8686) が変更されている場合があります。

「接続」をクリックします。

JConsole ウィンドウの各種タブに、MBean、JVM 情報などが表示されます。監視に利用できる MBean のほとんどは、amx および java.lang ドメインにあります。

参照

JConsole の詳細は、http://java.sun.com/javase/6/docs/technotes/guides/management/jconsole.html を参照してください。

第 9 章ライフサイクルモジュールの管理

この章では、Sun GlassFish^TMEnterprise Server v3 環境でライフサイクルモジュールを管理する手順について説明します。

ここでは、次のテーマを取り上げます。

本章で説明するタスクを管理コンソールから実行する手順については、管理コンソールのオンラインヘルプを参照してください。

ライフサイクルモジュールについて

「ライフサイクルモジュール」は初期化サービスとも呼ばれ、Enterprise Server 環境内で短期的または長期的な Java ベースタスクを実行する手段として利用できます。これらのモジュールはサーバーの起動時に自動的に開始され、サーバーのライフサイクルのさまざまな段階で通知を受け取ります。ライフサイクルモジュールの設定済みのプロパティーは、サーバーの初期化中にプロパティーとして渡されます。

ライフサイクルモジュールのすべてのクラスとインタフェースは、as-install /glassfish/modules/glassfish-api.jar ファイルに格納されています。

ライフサイクルモジュールは次の Enterprise Server イベントを待機し、イベントに応じてタスクを実行します。

「初期化」。サーバーは構成を読み取り、組み込みサブシステム (セキュリティーサービスやロギングサービス) を初期化して、コンテナを作成します。
「起動」。サーバーは配備されたアプリケーションを読み込んで初期化します。
「実行可能」。サーバーは要求の処理を開始します。
「シャットダウン」。サーバーはアプリケーションをシャットダウンして停止します。
「終了」。サーバーはコンテナ、組み込みサブシステム、およびサーバー実行環境を終了します。

これらのイベントは LifecycleEvent クラスで定義されます。ライフサイクルモジュールの作成については、『Sun GlassFish Enterprise Server v3 Application Development Guide』の第 13 章「Developing Lifecycle Listeners」を参照してください。

注 –

is-failure-fatal 設定が true に設定されている場合は (デフォルトでは false)、ライフサイクルモジュールで障害が発生したときにサーバーの初期化または起動が中止されます。ただし、シャットダウンまたは終了は実行されます。

ライフサイクルモジュールの設定

ここでは、次のテーマを取り上げます。

ライフサイクルモジュールを作成する

ライフサイクルモジュールを作成するには、リモートモードで create-lifecycle-module サブコマンドを使用します。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

create-lifecycle-module(1) サブコマンドを使用して、新しいライフサイクルモジュールを作成します。

サブコマンドのオプションとプロパティーについては、このマニュアルページに記載されています。

サーバーを再起動して、変更を有効にします。

「ドメインの再起動」を参照してください。

例 9–1 ライフサイクルモジュールの作成

この例では、customSetup というライフサイクルモジュールを作成します。

asadmin> create-lifecycle-module --classname "com.acme.CustomSetup" 
--classpath "/export/customSetup" --loadorder 1 --failurefatal=true 
--description "this is a sample customSetup" 
--property rmi="Server\=acme1\:7070":timeout=30 customSetup
Command create-lifecycle-module executed successfully

参照

コマンド行に asadmin help create-lifecycle-module と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

ライフサイクルモジュールを一覧表示する

既存のライフサイクルモジュールを一覧表示するには、リモートモードで list-lifecycle-modules サブコマンドを使用します。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-lifecycle-modules(1) サブコマンドを使用して、ライフサイクルモジュールを一覧表示します。

例 9–2 ライフサイクルモジュールの一覧表示

この例では、既存のライフサイクルモジュールを一覧表示します。

asadmin> list-lifecycle-modules
WSTCPConnectorLCModule
Command list-lifecycle-modules executed successfully

参照

コマンド行に asadmin help list-lifecycle-modules と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

ライフサイクルモジュールを更新する

set サブコマンドを使用して、既存のライフサイクルモジュールを更新します。

get(1) サブコマンドを使用して、ライフサイクルモジュールの更新可能なプロパティーを一覧表示します。

次に例を示します (シングルモード)。

asadmin get "*" | grep sampleLCM
applications.application.sampleLCMmodule.availability-enabled=false
applications.application.sampleLCMmodule.directory-deployed=false
applications.application.sampleLCMmodule.enabled=true
applications.application.sampleLCMmodule.name=sampleLCMmodule
applications.application.sampleLCMmodule.object-type=user
applications.application.sampleLCMmodule.property.class-name=example.lc.SampleModule
applications.application.sampleLCMmodule.property.classpath=/build/lcm.jar
applications.application.sampleLCMmodule.property.is-failure-fatal=false
applications.application.sampleLCMmodule.property.isLifecycle=true

set(1) サブコマンドを使用して、ライフサイクルモジュールを更新します。

サーバーを再起動して、変更を有効にします。

「ドメインの再起動」を参照してください。

例 9–3 ライフサイクルモジュールの更新

この例では、classpath プロパティーを更新します。

sadmin> set applications.application.sampleLCMmodule.
property.classpath=/build/lcm_new.jarapplications.application.
sampleLCMmodule.property.classpath=/build/lcm_new.jarCommand set executed successfully.

参照

コマンド行に asadmin help set と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

ライフサイクルモジュールを削除する

ライフサイクルモジュールを削除するには、リモートモードで delete-lifecycle-module サブコマンドを使用します。

サーバーが実行されていることを確認します。

リモートサブコマンドには、実行中のサーバーが必要です。

list-lifecycle-modules(1) サブコマンドを使用して、現在のライフサイクルモジュールを一覧表示します。

delete-lifecycle-module(1) サブコマンドを使用して、ライフサイクルモジュールを削除します。

例 9–4 ライフサイクルモジュールの削除

この例では、customSetup というライフサイクルモジュールを削除します。

asadmin> delete-lifecycle-module customSetup
Command delete-lifecycle-module executed successfully

参照

コマンド行に asadmin help delete-lifecycle-module と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

第 10 章 Enterprise Server の拡張

この章では、配備された Sun GlassFish^TM Enterprise Server v3 の拡張および更新に関するタスクを、更新ツールを使用して実行する手順を説明します。pkg コマンドを使用する手順もこの章で説明します。Enterprise Server には、pkg コマンドの使用方法を説明するリファレンスページが用意されています。

ここでは、次のテーマを取り上げます。

この章のタスクを管理コンソールを使用して実行する場合の手順は、管理コンソールオンラインヘルプの更新ツールの項目で説明します。スタンドアロンの更新ツールにも、オンラインヘルプが用意されています。更新ツールの詳細は、http://wikis.sun.com/display/IpsBestPractices/Screenshots を参照してください。

アドオンコンポーネントについて

Enterprise Server は、機能をモジュール形式で提供するように設計されています。したがって、必要な機能だけをインストールして、必要がない機能のインストールは省略することができます。「OSGi モジュール」は、バンドルとも呼ばれ、配備した Enterprise Server にアドオン機能を提供します。サーバーの再起動を必要とせず、実行時にアドオンコンポーネントを追加または削除することができます。

時間の経過とともに、新しいアドオンコンポーネントが開発され、既存のコンポーネントは変更されていきます。Enterprise Server では、配備したサーバー上のソフトウェアを更新できるように、一連の Image Packaging System (IPS) ツールが提供されています。更新ツールを次の方法で使用して、新しいアドオンコンポーネンや更新されたアドオンコンポーネントをインストールできます。

グラフィカルな Enterprise Server 管理コンソールで選択して起動します。
コマンド行から開始できるスタンドアロンのグラフィカルツールとして起動します。コマンドの形式は、as-install-parent /bin/updatetool です。
コマンド行ユーティリティー (pkg コマンド) として起動します。グラフィカルな更新ツールで実行できるほとんどのタスクを実行できます。pkg コマンドを使用する主な理由は次のとおりです。
- アップデートスクリプトを作成する際の基礎として使用する
- モニター、グラフィックカード、またはキーボードが接続されていないシステム (ヘッドレスシステム) で、システムを操作する手段として使用する

グラフィカルなバージョンの更新ツールには、どちらにも詳細なオンラインヘルプが用意されています。

コンポーネントの追加

この節では、pkg コマンドを使用して、配備済みの Enterprise Server に Enterprise Server アドオンコンポーネントをインストールする手順について説明します。

アドオンコンポーネントをインストールする

pkg コマンドを使用して、アドオンコンポーネントをシステムにインストールできます。複数のバージョンのパッケージを使用できる場合は、指定しないかぎり最新のバージョンが適用されます。pkg コマンドは、as-install-parent/bin ディレクトリに格納されています。

注 –

pkg コンポーネント、updatetool コンポーネント、またはコマンド行から呼び出すその他の有効なコンポーネントが、配備済みの Enterprise Server にまだインストールされていない場合は、コンポーネントをインストールするかどうかを確認するメッセージが表示されます。「Y」を入力すると、コンポーネントがインストールされます。

始める前に

追加コンポーネントをインストールする前に、Enterprise Server v3 が完全に配備されている必要があります。インストールの手順については、『Sun GlassFish Enterprise Server v3 Installation Guide 』を参照してください。

インストール済みのコンポーネントを一覧表示します。

pkg list

次のような情報が表示されます。

NAME (AUTHORITY)                              VERSION         STATE      UFIX
glassfishv3-common                            0-1             installed  ----
glassfishv3-ejb                               0-1             installed  u---
glassfishv3-nucleus                           0-1             installed  ----
glassfishv3-web                               0-1             installed  ----
grails                                        1.0-1.0         installed  ----
jersey                                        0.7-0.1         installed  u---
jmaki                                         1.8.0-1.0       installed  ----
jruby                                         1.1.1-1.0       installed  ----
metro                                         1.2-1           installed  u---
pkg                                           0.1.4-6.564     installed  u---
python2.4-minimal                             2.4.4-6.564     installed  u---
updatetool (glassfish.org)                    2.0-6.564       installed  u---
wxpython2.8-minimal                           2.8.7.1-6.564   installed  u---

使用可能なパッケージをすべて表示します。

pkg list -a

リポジトリから次のような情報が表示されます。

NAME (AUTHORITY)                              VERSION         STATE      UFIX
glassfishv3-common                            0-1             known      u---
glassfishv3-common                            0-1             known      u---
glassfishv3-common                            0-1             installed  ----
glassfishv3-ejb                               0-1             known      u---
glassfishv3-ejb                               0-1             known      u---
glassfishv3-ejb                               0-1             known      u---
glassfishv3-ejb                               0-1             installed  u---
glassfishv3-ejb                               0-1             known      ----
glassfishv3-nucleus                           0-1             known      u---
glassfishv3-nucleus                           0-1             known      u---
glassfishv3-nucleus                           0-1             installed  ----
glassfishv3-web                               0-1             known      u---
glassfishv3-web                               0-1             known      u---
glassfishv3-web                               0-1             installed  ----
grails                                        1.0-1.0         installed  ----
javadb                                        0-1             known      u---
javadb                                        0-1             known      u---
javadb                                        0-1             known      ----
jersey                                        0.7-0.1         installed  u---
jersey                                        0.7-0.2         known      u---
jersey                                        0.7-0.3         known      u---
jersey                                        0.8-0.1         known      ----
jmaki                                         1.8.0-1.0       installed  ----
jruby                                         1.1.1-1.0       installed  ----
metro                                         1.2-1           installed  u---
metro                                         1.2-2           known      u---
metro                                         1.2-3           known      ----
pkg                                           0.1.4-6.564     installed  u---
pkg                                           0.1.5-8.724     known      ----
python2.4-minimal                             2.4.4-6.564     installed  u---
python2.4-minimal                             2.4.4-8.724     known      ----
updatetool                                    2.0-6.564       installed  u---
updatetool                                    2.0-8.724       known      ----
wxpython2.8-minimal                           2.8.7.1-6.564   installed  u---
wxpython2.8-minimal                           2.8.7.1-8.724   known      ----

as-install ディレクトリに移動します。

使用可能なパッケージのリストから、パッケージをインストールします。

pkg install package-name という構文を使用します。次に例を示します。
pkg install javadb
コンポーネントの最新のバージョンがインストールされ、次のような情報が表示されます。
```
DOWNLOAD                                     PKGS       FILES     XFER (MB)
javadb                                       0/1      61/200     2.10/7.26 

PHASE                                        ACTIONS
Install Phase                                222/222 
```

変更内容を適用するために、Enterprise Server を再起動します。

「ドメインの再起動」を参照してください。

参照

pkg コマンドを使用する際の完全な構文とオプションは、as-install/pkg/man/ ディレクトリにあるリファレンスページで説明されています。これらのリファレンスページは、man コマンドでは表示されません。代わりに、more または cat などのコマンドを使用してください。

インストール済みのコンポーネントの更新

この節では、Enterprise Server のコンポーネントをインストールしたあとに、これらのコンポーネントを更新する次の手順について説明します。

インストール済みのコンポーネントを更新する

更新されたバージョンのコンポーネントをインストールする場合は、変更されたファイルだけがダウンロードおよびインストールされます。更新されたパッケージで削除されているファイルは、更新プロセス中に削除されます。

使用可能な更新があるインストール済みのパッケージだけを一覧表示します。

pkg list -u

次のような情報が表示されます。

NAME (AUTHORITY)                              VERSION         STATE      UFIX
glassfishv3-ejb                               0-1             installed  u---
jersey                                        0.7-0.1         installed  u---
metro                                         1.2-1           installed  u---
pkg                                           0.1.4-6.564     installed  u---
python2.4-minimal                             2.4.4-6.564     installed  u---
updatetool (glassfish.org)                    2.0-6.564       installed  u---
wxpython2.8-minimal                           2.8.7.1-6.564   installed  u---

新しいバージョンのパッケージをインストールします。

pkg install package-name という構文を使用します。次に例を示します。

pkg install metro

次のような情報が表示されます。

DOWNLOAD                                     PKGS       FILES     XFER (MB)
Completed                                    1/1         5/5     0.49/0.49 

PHASE                                        ACTIONS
Removal Phase                                    2/2 
Update Phase                                     7/7 
Install Phase                                    2/2

変更内容を適用するために、Enterprise Server を再起動します。

「ドメインの再起動」を参照してください。

参照

pkg コマンドを使用する際の完全な構文とオプションは、as-install /pkg/man/ ディレクトリにあるリファレンスページで説明されています。これらのリファレンスページは、man コマンドでは表示されません。代わりに、more または cat などのコマンドを使用してください。

イメージ内のすべてのインストール済みコンポーネントを更新する

Enterprise Server では、単一のシステムで複数のインストールイメージを保守できます。インストールイメージを更新するときに、イメージ内にあるすべてのコンポーネントは、新しいバージョンを利用できる場合、そのバージョンに更新されます。更新されたバージョンのコンポーネントをインストールするときに、変更されたファイルだけがダウンロードおよびインストールされます。更新されたパッケージで削除されているファイルは、更新プロセス中に削除されます。

イメージのすべてのパッケージをインストールします。

pkg install image-name の構文を使用します。次に例を示します。

pkg image-update

次のような情報が表示されます。

DOWNLOAD                                     PKGS       FILES     XFER (MB)
Completed                                    6/6     729/729   21.59/21.59 

PHASE                                        ACTIONS

Removal Phase                                887/887 
Update Phase                                 253/253 
Install Phase                                584/584

変更内容を適用するために、Enterprise Server を再起動します。

「ドメインの再起動」を参照してください。

参照

インストール済みのコンポーネントの削除

使用していないコンポーネントをシステムから削除する場合は、uninstall コマンドを使用します。コンポーネントを以前のバージョンに戻す必要がある場合は、現在のバージョンをアンインストールしたあとに、バージョン番号を指定して以前のバージョンをインストールする必要があります。

インストール済みのコンポーネントをアンインストールする

始める前に

インストール済みのコンポーネントを削除する前に、削除するコンポーネントに依存関係がないことを確認します。

インストール済みのコンポーネントをすべて表示します。

pkg list

NAME (AUTHORITY)                              VERSION         STATE      UFIX
glassfishv3-common                            0-1             installed  ----
glassfishv3-ejb                               0-1             installed  u---
glassfishv3-nucleus                           0-1             installed  ----
glassfishv3-web                               0-1             installed  ----
grails                                        1.0-1.0         installed  ----
jersey                                        0.7-0.1         installed  u---
jmaki                                         1.8.0-1.0       installed  ----
jruby                                         1.1.1-1.0       installed  ----
metro                                         1.2-1           installed  u---
pkg                                           0.1.4-6.564     installed  u---
python2.4-minimal                             2.4.4-6.564     installed  u---
updatetool (glassfish.org)                    2.0-6.564       installed  u---
wxpython2.8-minimal                           2.8.7.1-6.564   installed  u---

システムから削除するコンポーネントをアンインストールします。

pkg uninstall package-name の構文を使用します。次に例を示します。
pkg uninstall jruby

変更内容を適用するために、Enterprise Server を再起動します。

「ドメインの再起動」を参照してください。

参照

コンポーネントをアンインストールして古いバージョンに戻す

インストールしたコンポーネントが正しく動作しない場合は、コンポーネントを古いバージョンに戻すことができます。古いバージョンのコンポーネントを復元するには、現在のバージョンのコンポーネントをアンインストールしたあと、元に戻す古いバージョンをインストールします。

始める前に

現在のバージョンのコンポーネントをアンインストールする前に、古いバージョンのコンポーネントがリポジトリにあることを確認する必要があります。

古いバージョンのコンポーネントがまだ使用可能であることを確認します。
pkg list -a

インストール済みのコンポーネントを一覧表示します。
pkg list

置換対象の現在インストールされているコンポーネントをアンインストールします。

pkg uninstall package-name の構文を使用します。次に例を示します。
pkg uninstall jersey

古いバージョンのコンポーネントをインストールします。

pkg install package-name —version version-number の構文を使用します。次に例を示します。
pkg install jersey -version 0.7-0.2

古いバージョンがインストールされたことを確認します。
pkg list

パート I ランタイム管理

第 2 章 管理の概要

asadmin ユーティリティーの使用

asadmin ユーティリティーのパス

asadmin ユーティリティーの構文

asadmin ユーティリティーのサブコマンド

asadmin ユーティリティーのオプションとサブコマンドのオプション

asadmin ユーティリティーのサブコマンドのオペランド

シングルモードで asadmin ユーティリティーのサブコマンドを実行する

例 2–1 シングルモードでの asadmin ユーティリティーのサブコマンド実行

例 2–2 シングルモードでの asadmin ユーティリティーオプションとサブコマンドの指定

例 2–3 シングルモードでの asadmin ユーティリティーオプションとサブコマンドオプションの指定

asadmin ユーティリティーまたはサブコマンドのヘルプ情報を表示する

例 2–4 asadmin ユーティリティーのヘルプ情報の表示

例 2–5 asadmin ユーティリティーサブコマンドのヘルプ情報表示

参照

マルチモードセッションを開始する

例 2–6 asadmin ユーティリティーオプションによるマルチモードセッション開始

例 2–7 サブコマンド multimode によるマルチモードセッションの開始

例 2–8 マルチモードセッションでのサブコマンドの実行

既存のマルチモードセッションからのマルチモードセッション開始

参照

マルチモードセッションを終了する

ファイルから asadmin の一連のサブコマンドを実行する

例 2–9 ファイルからの asadmin の一連のサブコマンドの実行

参照

システムプロパティーの管理

システムプロパティーを作成する

例 2–10 システムプロパティーの作成

参照

システムプロパティーを一覧表示する

例 2–11 システムプロパティーの一覧表示

参照

システムプロパティーを削除する

例 2–12 システムプロパティーの削除

参照

リソースの管理

XML ファイルからリソースを追加する

例 2–13 リソースの追加

参照

さまざまなシステム要素の一覧表示

Enterprise Server のバージョンを表示する

例 2–14 バージョン情報の表示

参照

アプリケーションを一覧表示する

例 2–15 アプリケーションの一覧表示

参照

コンテナを一覧表示する

例 2–16 コンテナの一覧表示

参照

モジュールを一覧表示する

例 2–17 モジュールの一覧表示

参照

サブコマンドを一覧表示する

例 2–18 サブコマンドの一覧表示

参照

タイマーを一覧表示する

例 2–19 タイマーの一覧表示

コンポーネントの状態を表示する

例 2–20 コンポーネントの状態の表示

REST インタフェースによる Enterprise Server の管理

REST URL による Enterprise Server の管理

図 2–1 ドメインを管理する REST リソースの Web ページ

REST リソースメソッドによる Enterprise Server の管理

ツリー内のノードがサポートするメソッドおよびメソッドパラメータを判定する

例 2–21 ツリー内のノードがサポートするメソッドおよびメソッドパラメータの判定

ツリー内のノードのデータを取得する

例 2–22 ツリー内のノードのデータの取得

ツリーにノードを追加する

例 2–23 ツリーへのノードの追加

ツリー内のノードを更新する

例 2–24 ツリー内のノードの更新

ツリーからノードを削除する

例 2–25 ツリーからのノードの削除

CRUD 以外の操作用の子リソース

REST インタフェースのセキュリティー保護

リソースの表現形式

JSON リソースの表現

メソッドリストのメソッドの JSON 表現

メッセージパラメータまたはクエリーパラメータの JSON 表現

第 2 章管理の概要

`asadmin` ユーティリティーの使用

`asadmin` ユーティリティーのパス

`asadmin` ユーティリティーの構文

`asadmin` ユーティリティーのサブコマンド

`asadmin` ユーティリティーのオプションとサブコマンドのオプション

`asadmin` ユーティリティーのサブコマンドのオペランド

シングルモードで `asadmin` ユーティリティーのサブコマンドを実行する

例 2–1 シングルモードでの `asadmin` ユーティリティーのサブコマンド実行

例 2–2 シングルモードでの `asadmin` ユーティリティーオプションとサブコマンドの指定

例 2–3 シングルモードでの `asadmin` ユーティリティーオプションとサブコマンドオプションの指定

`asadmin` ユーティリティーまたはサブコマンドのヘルプ情報を表示する

例 2–4 `asadmin` ユーティリティーのヘルプ情報の表示

例 2–5 `asadmin` ユーティリティーサブコマンドのヘルプ情報表示

例 2–6 `asadmin` ユーティリティーオプションによるマルチモードセッション開始

例 2–7 サブコマンド `multimode` によるマルチモードセッションの開始

ファイルから `asadmin` の一連のサブコマンドを実行する

例 2–9 ファイルからの `asadmin` の一連のサブコマンドの実行

第 3 章ドメインの管理