このセクションでは、任意の Java アプリケーションのモニタリングを構成する方法について説明します。Event Monitoring ツールを適切に構成して (直接的または間接的に) Java アプリケーションを呼び出すテストを含むテストスイートの先頭に配置すると、発生する Java イベントを受信し、視覚化できます。

このセクションの内容:

SOAtest は、Parasoft Jtest との統合によって、Java の実行時エラー検出と Java イベントモニタリングの機能を提供します。Java の広範なテストと解析のプラクティスを容易にします。

SOAtest の実行時エラー検出あるいは Java イベントモニタリング機能を使用する前に、必ず 1) Jtest がインストール済みであること、および 2) SOAtest の "Jtest Connect" ライセンスオプションが有効であることを確認してください。「ライセンス」を参照してください。

Jtest にアクセスするには、Parasoft 担当者にお問い合わせください。製品をまたがる機能を利用するには、Jtest と SOAtest を以下のいずれかの方法でインストールしている必要があります。

Jtest および SOAtest のプラグインが同じ Eclipse インスタンスにインストールされている。
Jtest および SOAtest が p2 更新サイトアーカイブによってインストールされている (詳細については「Eclipse p2 更新サイトからのインストール」を参照)。

Java アプリケーションをモニタリングする理由

実装済みの Java アプリケーションをモニタリングすると、機能テストの実行中にアプリケーションの内部的な振る舞いを可視化できます。これによって、テストが失敗した場合に原因を突き止めるのが容易になるほか、回帰テストにおけるユースケースの検証条件を拡張することができます。システムが返すメッセージや ESB を通じてモニタリングされた中間的なメッセージ/ステップの検証に加えて、呼び出された Java アプリケーション内のイベントの検証を実行できます。たとえば、期待されるパラメーターを使用して EJB メソッドの呼び出しまたは他のシステムのリモート呼び出しが行われているかを検証できます。

アプリケーションの設定

アプリケーションをモニタリングするには、Parasoft のモニタリングエージェントを使用してアプリケーションをインストゥルメントする必要があります。それには、次の操作を行います。

[Jtest_install_dir]/plugins/com.parasoft.xtest.jtest_[version]/resources/ にある insure.jar および insureimpl.jar をインストゥルメント対象のアプリケーションと共にサーバー上のディレクトリにコピーします。
サーバーが実行中の場合、サーバーを停止します。
起動スクリプトで、既存の Java 引数に -javaagent コマンドを追加します。詳細については「javaagent コマンドの詳細」を参照してください。
サーバーを再起動します。

サーバーは通常と同じように起動します。ただし、指定したパッケージクラスがインストゥルメントされる点が異なります。すると、指定された接頭辞を持つパッケージ内のオブジェクトがインスタンス化されたり、メソッドが呼び出されるたびに、SOAtest (他の開発者/QA のデスクトップマシンで実行されていても構いません) が Event Monitor でイベント通知を受信できます。

javaagent コマンドの詳細

基本

すべての場合で、以下の呼び出しパラメーターが必要です。

モニタリングするプログラムとの応答に使用するポート番号を指定します。5050 から 5099 の値を指定してください。

パラメーター	説明
soatest	モニタリングを構成するために必要です。
port=[port_number]	モニタリングするプログラムとの応答に使用するポート番号を指定します。5050 から 5099 の値を指定してください。
instrument= [class_name.method_name(jni _sig)]	チェックする完全修飾メソッドの接頭辞を指定します。たとえば com.abc.util.IOUtil.method と指定すると、 IOUtil.java 中のメソッドで、 method で開始するすべてのメソッドがインストゥルメントされます。com.abc. と指定すると、それらのメソッドがインストゥルメントされるほか、完全修飾名が com.abc. で開始するクラスのすべてのメソッドもインストゥルメントされます。特定のクラス名、またはワイルドカードを使用して特定のパッケージ内の任意のクラスを指定できます。詳細については下記の注意を参照してください。
trace=[class_name.method_na me(jni_sig)]	トレース対象のメソッド呼び出しのフィルターを指定します。詳細については下記の注意を参照してください。

クラスのインストゥルメントは、クラスのすべてのメソッドボディに適用されます。それによって、たとえばクラスが呼び出すメソッドやメソッドが返す値などを可視化できます。

トレースは、可視化するコードの呼び出し元をインストゥルメントすることで実現されます。呼び出し先はインストゥルメントされません。

たとえば、自分のコードが呼び出しているサードパーティのメソッドをトレースし、別のサードパーティのコードから呼び出されているものはトレースしない場合、自分のコードをインストゥルメントし、サードパーティのコードへの呼び出しをトレースします。

具体的には、次の処理が実行されます。

instrument=com.acme.util と指定すると、com.acme.util に一致するすべてのクラスがインストゥルメントされます。それらのクラスのすべてのメソッドがインストゥルメントされます。次のコードの writeData メソッドがインストゥルメントされます。

package com.acme.util; 
class IOUtil {
       int writeData(DataOutputStream dos, Data data) {
           dos.write(data._int); 
           dos.write(data._float);
       }
}

instrument=com.acme.util,trace=java.ioと指定すると、com.acme.util のコードから java.io への呼び出しが可視化されます。インストゥルメントによって、モニタリング対象のコードからどの java.io が呼び出されたかをチェックするために writeData() メソッドに呼び出しが追加されます。

以下は任意パラメーターです。

パラメーター	説明
trace_to_xml	複雑な Java オブジェクトを XML 表現にシリアライズするよう指定します。このオプションを省略した場合、プリミティブ型および Objects 型の toString() メソッドの値だけが返されます。 Event Monitor を使用する場合、このパラメーターを指定することを強く推奨します。実行時エラー検出だけを行う場合は、このパラメーターは適用されません。
xmlsizelimit=[integer_value]	XML の最大バイト数を指定します。オプションが指定されていない場合のデフォルト値は 100000 です。 trace_to_xml オプションが指定されている場合にだけ適用されます。
xmlcolsizelimit=[integer_value]	Java オブジェクトの XML 表現を生成する際、表示する collection/map/array 要素の最大数を指定します。デフォルトでは最初の 100 個の要素が表示されます。 trace_to_xml オプションが指定されている場合にだけ適用されます。
xmldeeplimit=[integer_value]	Java オブジェクトの XML 表現を生成する際、データ構造に含めるフィールドの最大の深さを指定します。デフォルトでは 8 階層までのフィールドが含められます。 trace_to_xml オプションが指定されている場合にだけ適用されます。
xmlexcl=[classes_or_fields]	シリアライズから除外するクラスまたはフィールドです。':' 区切りで記述します (例: xmlexcl=com.acme.A:com.acme.B._field)。 trace_to_xml オプションが指定されている場合にだけ適用されます。
xmlinc=[classes_or_fields]	常に XML シリアライズに含めるクラスまたはフィールドです。':' 区切りで記述します (例: xmlinc=com.acme.A:com.acme.B._field)。 xmlexcl よりも xmlinc が優先されます。つまり、xmlinc に一致したものは、xmlexcl にも一致する場合でも、常に表示されます。パターンがクラス名に一致した場合、1) そのクラスまたは派生クラスのフィールドはシリアライズから除外されます。 2) そのクラスまたは派生クラスのメソッドの引数および戻り値の型は XML にシリアライズされません。デフォルトでは、以下の型のクラスが除外されます。 .......................... trace_to_xml オプションが指定されている場合にだけ適用されます。
xmlsecondslimit=[seconds]	デフォルトでは、trace_to_xml を使用する場合、モニタリングされた複合 Java オブジェクトを XML 表現に変換するときに 10 秒までしか使用しません。これは、非常に大きなオブジェクトをモニターする場合にあまりに処理が遅くなるのを防ぐためです。この制限に達すると、SOAtest イベントはオブジェクトの XML 表現の代わりに次のメッセージを表示します。 SKIPPED: converting to XML takes too long: 10 seconds しきい値を 10 秒以外の値に変更するには、xmlsecondslimit フラグを使用します。例: xmlsecondslimit=20 大きなオブジェクトがある場合、xmlecl オプションを使用して関心の対象外のフィールドを除外し、XML のサイズを小さくするなど、しきい値に到達しないようにする方が良いやりかたです。
trace_exceptions[=exception_c lass_prefix]	作成、スロー、キャッチされた例外に関するイベントのトレースを表示します。 _details を追加すると、イベントの詳細 (イベントが発生したときのスタックトレース) が追加されます。
terse	コンソールに簡潔な出力を表示します (スタックトレースには1 要素だけが含まれます)。

Eclipse またはアプリケーションサーバーから実行しているアプリケーション

独自のクラスローダー (Eclipse、JBoss、Tomcat など) を定義するアプリケーションは、ブートクラスパスに insure.jar を追加する必要があります。これらのアプリケーションをモニターするには、起動 VM 引数に次を追加します。

-javaagent:"<path_to_jar>\insure.jar=soatest,port=<port>",trace_to_xml,instrument=<my.pack-age.prefix>,trace=<my.package.prefix> -Xbootclasspath/a<path_to_jar>\insure.jar

たとえば、次のように指定します。

-javaagent:"/home/user/parasoft/insure.jar=soatest,port=5060",trace_to_xml,instru-
ment=com.mycompany.onlinestore,trace=com.mycompany.onlinestore -Xbootclasspath/a:/home/user/parasoft/insure.jar

ほかの ( スタンドアロンの) Java アプリケーションの場合

ほかの ( スタンドアロンの) Java アプリケーションの場合、ブートのクラスパスに insure.jar を追加する必要はありません。たとえば、次のように指定します。

java -javaagent:"C:\Program Files\Parasoft\insure.jar=soatest,port=5050",trace_to_xml,instru-ment=com.mycompany.myapp,trace=com.mycompany.myapp

SOAtest の設定

Event Monitor ツールをダブルクリックしてツール構成パネルを開きます。
[イベントソース] タブでプラットフォームとして [Instrumented Java Application] を選択し、サーバーが実行されているホスト名および Parasoft エージェントのランタイムのポート番号 (デフォルト値は 5050) を指定します。

ヒント

アプリケーションを初めてモニタリングエージェント共に起動する場合、レポートされたイベントを調査する前に、テストまたはシナリオを試験的に実行することを推奨します。これによって、さまざまなインストゥルメントおよび初期化プロセスが確実に実行されます。また、より現実的なデータを取得するのにも役立ちます。初回の実行にかかる時間は、その後の実行にかかる時間よりも大幅に長い場合があり、タイムアウトやその他の副作用が発生する可能性があります。その後の実行のほうが、モニター対象のシステムの現実的な振る舞いをより忠実に反映しています。
イベントはリモートエージェントから非同期的に受信されます。イベントと、そのイベントをトリガーしたテストアクションの間に直接的な相関関係はありません。SOAtest の Event Monitor は、受信したすべてのイベントを時系列で表示するため、テストイベントと Java モニタリングイベントの順序が前後して表示される場合があります。[各テスト実行終了後のポーリング遅延時間] オプションの値を増やすと、そのような事態が起こる可能性を少なくできます。ただし、それによってテストの実行時間が長くなります (Event Monitor が各呼び出しの後にテスト実行を中断するため)。[モニター実行の最大継続時間] の値がテストスイート全体の実行時間に対して適切であることを確認してください。環境やシステムが異なると、これらのパラメーターの最適なしきい値も異なる可能性があるため、ケースバイケースで調整する必要があるでしょう。
ベストプラクティスの 1 つは、比較的広い範囲のパッケージ/クラスでインストゥルメントとトレースを開始し、徐々に範囲を狭めていくことです。インストゥルメントが多いほど、アプリケーションの実行は遅くなり、トレースされるパッケージ/クラスが多いほど、過剰にイベントが返されます。これら 2 つのパラメーターを調整し、ユーザーにとって意味のある種類のイベントだけを取得するようにできます。
trace_to_xml オプションを使用すると、Event Monitor でオブジェクトの非常に大きな XML コンテンツ表現が取得される場合があります。場合によってはメガバイトの規模になり、100,000 バイトの制限 (xmlsizelimit オプションで調整可能です) に達する可能性があります。その場合、前に説明したさまざまな xml* パラメーターを使用して対象のコンテンツを制御し、データ量を抑制することを検討してください。