 |
|
ツールガイド 05/22/03 08:41:32 |
exteNd Debuggerでは、Javaコードの実行を制御および監視することにより、Javaアプリケーションのランタイムエラーを検出することができます。ローカルホストマシン、または分散マシンからリモートで、サーバ側のオブジェクト(J2EEアプリケーションなど)およびクライアント側のオブジェクトをデバッグすることが可能です。
注記: デフォルトでは、Workbench内からデバッガを起動すると、exteNd Debuggerが起動されます。異なるデバッガを使用したい場合は、そのデバッガがWorkbench内から起動されるように指定できます。詳細については、 デバッガの指定を参照してください。
Debuggerを使用する前に、次の用語を確認しておく必要があります。
exteNd Debuggerには、Javaアプリケーションの問題を診断するための複数の機能があります。
多数の機能が表示されているサンプルDebuggerウィンドウは、次のとおりです。
|
オブジェクト |
説明 |
|---|---|
|
サーバオブジェクト |
配備されたJ2EEアプリケーションにある次のオブジェクト: サーバ上で実行している他のJavaアプリケーション |
exteNd Debuggerを使用すると、ローカルホスト上または分散ネットワークでリモートに実行中のJavaアプリケーションをトラブルシューティングできます。プロセスは、ローカルマシンまたはリモートマシンのいずれかでデバッグされるように設定できますが、同じセッションで両方に対して設定することはできません。
次の例のように、リモートデバッグが必要な場合が多々あります。
ネットワーク上のあるマシンではJavaアプリケーションがエラーなしで実行されるが、他のマシンではエラーが生じる場合。このような場合、問題のあるリモートシステム上でアプリケーションを実行するときにデバッグする必要があります。
Debuggerには、次の操作を行うことによってコードを実行する方法が存在します。
Javaアプリケーションのソースコードに ブレークポイントを設定して管理する
ソースコードの問題を個別に特定できるようにするために、Debuggerには、プログラムの実行の任意の点で 変数、 コールスタック、および スレッドステータスを検査するためのビューアがあります。
各デバッグセッションには独自の固有な作業が必要ですが、アプリケーションのトラブルシューティングの際には、通常は次のワークフローに従います。
サーバで実行しているアプリケーションのデバッグに使用する方法は、クライアントアプリケーションのデバッグに使用する方法とは異なります。これらの方法については、次の2つの節で説明します。
サーバで実行しているオブジェクト(J2EEアプリケーションなど)をデバッグする場合は、Debuggerからアプリケーションを起動するのではなく、アプリケーションをサーバで起動してから、そのアプリケーションにDebuggerを接続します。WorkbenchによりサポートされているJ2EEアプリケーションサーバで実行中のアプリケーションは、デバッグすることが可能です。
場合によっては、サーバオブジェクトをデバッグする前に、アプリケーションサーバをデバッグモードで起動する必要があります。この節では、デバッグするためにNovell exteNd アプリケーションサーバおよびBEA WebLogicを起動する手順について説明します。
これらのサーバおよび他のアプリケーションサーバのデバッグモードでの起動の詳細については、サーバのマニュアルを参照してください。
注記: 次の手順は、SilverStream eXtend アプリケーションサーバおよびNovell exteNd アプリケーションサーバの両方に適用されます。
デバッグするためにNovell exteNd アプリケーションサーバを起動する
+debugは、デフォルトのデバッグアドレスagsrvを使用して、ローカルデバッグするためにサーバを起動します。ローカルデバッグに対しては、次のバリエーションを指定できます。
+debugremoteは、デフォルトのデバッグポート9901を使用して、リモートデバッグするためにサーバを起動します。
+debug:port=port_numは、デフォルトのデバッグポート9901の代わりにport_numを使用して、リモートデバッグするためにサーバを起動します。このオプションは、ポート9901が使用できない場合に使用します。
例 次のコマンドラインでは、ローカルデバッグするためにアプリケーションサーバ exteNdが起動されます。
ServerInstallDir\bin\SilverServer +debug
次のコマンドラインでは、リモートデバッグするためにexteNd アプリケーションサーバが起動されます。
ServerInstallDir\bin\SilverServer +debugremote
次のように、サーバを起動するためのコマンドラインにオプションを太字で追加することによって、startWebLogic.cmdファイルを修正します。
"%JAVA_HOME%\bin\java" -hotspot -ms64m -mx64m -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n -Djava.compiler=NONE -classpath ...
起動時に、サーバによって次のようなデバッグアドレスが表示されます。
Listening for transport dt_socket at address: address
この値は、Debuggerを起動するときに使用します(次の説明を参照)。
Debuggerは、Workbench内からまたはコマンドラインから起動できます。
［Edit］>［Launch Debugger］の順に選択します。
ローカルサーバ上のアプリケーションをデバッグする場合は、［Shared Memory Debugging］をオンにして、デバッグアドレスを入力します。
リモートサーバ上のアプリケーションをデバッグする場合は、［Remote Socket Debugging］をオンにして、マシン名およびデバッグポートを指定します。
注記: WebLogicで実行しているアプリケーションをデバッグする場合は、ローカルのWebLogicサーバ上にアプリケーションがある場合でも、［Remote Socket Debugging］をオンにし、マシン名(ローカルの場合はlocalhost)、および起動時にサーバによって報告されたアドレス(ポート)を指定します。
ローカルサーバ上のアプリケーションをデバッグする場合は、次のように入力します。
SilverDebugger -attach localhost debug_address
リモートサーバ(またはローカルのWebLogicサーバ)上のアプリケーションをデバッグする場合は、次のように入力します。
SilverDebugger -attach machine_name:debug_port
次のシナリオでは、WorkbenchのWebアプリケーションチュートリアルで作成されたJ2EEアプリケーションであるProverbFinalのデバッグ方法を説明します。このシナリオには、ローカルアプリケーションサーバ上のアプリケーションのデバッグが示されています(このアプリケーションは、Workbenchプロジェクトとして提供されています。詳細については、Workbenchヘルプのチュートリアルを参照してください)。
ServerInstallDir\bin\SilverServer +debug
WorkbenchでProverbFinalプロジェクトを開きます。
このプロジェクトは、WorkbenchInstallDir\docs\tutorial\ProverbFinalにあります。これは、完成したアプリケーションです。
このシナリオでは、アプリケーションは、チュートリアル提供のCloudscapeデータベースであるProverbsCloudに配備されました。
WorkbenchからDebuggerを起動したときに開いていたファイルがある場合は、自動的にそのファイルがDebuggerで開きます。他のファイルもDebuggerで開いてデバッグできます。
ここでは、TodayAction.javaが開きました。このコードは、今日のことわざの表示を誰かが要求したときに実行されます。
アプリケーションサーバは、デフォルトのデバッグアドレスを使用して起動されたため、agsrvがデバッグアドレスとして指定されます。
Debuggerが開き、ファイルが表示されます。
カーソルを行の上に置き、Debuggerツールバーの［Toggle Breakpoint］アイコン(次の図を参照)をクリックすることによって、コードの行にブレークポイントを設定します。
アプリケーションを実行するには、ブラウザを開き、次のURLを指定します。
http://localhost/ProverbsCloud/ProverbFinal/index.jsp
［Today\xd5 s Proverb］をクリックします。この操作によって、TodayAction.javaのコードが呼び出されます。実行は停止し(ブラウザではページの処理が完了していないことがわかります)、Debuggerウィンドウが更新されます。
実行矢印がブレークポイントにあることを確認できます。
デバッグが終了したら、［Continue］アイコン(次の図を参照)をクリックして実行を続行します。
ページでは、実行が完了します。
前のサンプルデバッグセッションで示した方法を使用すると、J2EEアプリケーションをデバッグできます。EJBおよびサーブレットは、前に説明した方法と同様にデバッグします。つまり、EJBまたはサーブレットのソースコードをDebuggerで開き、1つまたは複数のブレークポイントを設定してから、アプリケーションを実行します。
JSPソースページの検索 実行用にサーブレットに変換されコンパイルされたJSPページをデバッグするには、サーバによってJSPページから作成されたJavaソースファイルを検索してDebuggerで開き、ブレークポイントを設定する必要があります。異なるJ2EEサーバでは、異なった方法でソースファイルを検索します。exteNd アプリケーションサーバおよびWebLogicに関する情報は、次のとおりです。
他のサーバに関する情報については、各マニュアルを参照してください。
例 Debuggerで表示できるJSPソースページの例は、次のとおりです。
ここでは、today.jspから生成されたJavaソースファイルで実行が停止しています。
J2EEアプリケーションのデバッグ、およびアプリケーションサーバで実行している他のアプリケーションのデバッグに加えて、Debuggerを使用してクライアントJavaアプリケーションをデバッグすることもできます。
クライアントアプリケーションは、次のいずれかの方法でデバッグできます。
アプリケーションは、Workbench内からまたはコマンドラインから起動できます。
Workbenchからクライアントアプリケーションを起動する
Workbenchで、アプリケーションを定義するプロジェクトを開きます。
プロジェクトのクラスパスが正しくセットアップされていることを確認します。
［Edit］>［Launch Debugger］の順に選択します。
SilverDebugger [options] class class_arguments
アプリケーションを起動するためのSilverDebugger引数は、次のとおりです。
たとえば、JDKに付属のデモ版のNotepadアプリケーションをデバッグするには、次のコマンドを入力します(InstallDirは、c:\jdk1.3\demo\jfc\Notepadなど、デモ版のアプリケーションのインストールディレクトリです)。
SilverDebugger -sourcepath InstallDir\src -sourcefile InstallDir\src\Notepad.java -classpath InstallDir\Notepad.jar Notepad
Debuggerがデスクトップで開き、指定したJavaソースファイルが表示されます。
メニューから［Tools］>［Continue］の順に選択するか、またはDebuggerウィンドウのツールバーにある［Continue］アイコン(次の図を参照)をクリックします。
アプリケーションがデスクトップで開き、最初に現れたブレークポイントで実行が停止します。
アプリケーションを起動した後、そのアプリケーションにDebuggerを接続することができます。この操作を実行するには、デバッグするためだけにアプリケーションを起動する必要があります。
実行中のJavaアプリケーションにDebuggerを接続する
Javaアプリケーションをローカルホストまたはリモートマシンで起動します。
アプリケーションをローカルホストで起動する
java -Xdebug -Xnoagent -Xrunjdwp:transport=dt_shmem,server=y,suspend=n -classpath classpath classname
JVMによって、「デバッグアドレス」が返されます。例は次のとおりです。
この例では、JVMによってjavadebugがデバッグアドレスとして返されます。このオプションtransport=dt_shmemでは、ローカルデバッグに必要な共有メモリトランスポートが指定されます。
デバッグアドレスは、 Step 2でDebuggerに渡す必要があるので記録しておいてください。
アプリケーションをリモートネットワークマシンで起動する
java -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n -classpath classpath classname
JVMによって、「デバッグポート番号」が返されます。例は次のとおりです。
この例では、JVMによって3340がデバッグポートとして返されます。このオプションtransport=dt_socketでは、リモートデバッグに必要なソケットベースのトランスポートが指定されます。
デバッグポート番号は、 Step 2でDebuggerに渡す必要があるので記録しておいてください。
Workbench内からまたはコマンドラインからDebuggerを起動します。
Workbench内からDebuggerを起動する
ローカルでデバッグする場合は、［Shared Memory Debugging］をオンにし、JVMによって返された「デバッグアドレス」を指定します。リモートでデバッグする場合は、［Remote Socket Debugging］をオンにし、JVMによって返された「デバッグポート」を指定します。
コマンドラインからDebuggerを起動する
Debuggerがデスクトップで開きます。
SilverJ2EEClientに対するデバッグ これは、exteNd アプリケーションサーバに対するデバッグと同様の手順で行います。適切なデバッグ起動オプション( サーバの起動の説明を参照)を使用してSilverJ2EEClientを起動した後、結果として得られるデバッグアドレス(デフォルトはagjrn)またはデバッグポート(デフォルトは9901)にDebuggerを接続します。
Debuggerの起動後、ソースコードの問題を孤立および診断できるようにするためにプログラム実行を管理する方法がいくつかあります。
ブレークポイントは、実行を停止して制御をDebuggerに移す場所をコード内の行で指定するために使用します。コードによって実行が停止され、Debuggerに制御が移されたら、Debuggerコマンドを実行し、コールスタック、スレッドステータス、および変数値を表示することができます。
ブレークポイントは、コード内の個別の行でのみ設定できます。複数のステートメントが1行に含まれている場合は、行の最初のステートメントでのみブレークポイントを設定できます。後続のステートメントにブレークポイントを設定するには、行を分割して、各ステートメントが1行に表示されるようにする必要があります。
注記: ブレークポイントは、サーバ名およびクラス名別に保存されます。そのため、同じサーバ上にある同じような名前のオブジェクトでは、ブレークポイントを共有します。
ローカルクラス、または外部ソースからロードされたクラスに対して、ブレークポイントをコードで設定および削除するには、いくつかの方法があります。ソースコードがDebuggerで見つからない場合は、パスを入力するように指示されます( ソースコードがDebuggerで見つからない場合の説明を参照)。
この節では、ソースコードでブレークポイントを設定および削除する手順について説明します。
［Toggle Breakpoint］を使用してコードにブレークポイントを設定する
メニューから［ Tools］>［Toggle Breakpoint］の順に選択するか、またはDebuggerツールバーにある［Toggle Breakpoint］アイコン(次の図を参照)を選択します。
ブレークポイントインジケータ
は、左側の余白で、指定した行の隣に表示されます。
［Edit］メニューを使用してコードにブレークポイントを設定する
メニューから［ Edit］>［Show Line Numbers］の順に選択します。
これによって、ブレークポイントの場所が指定しやすくなります。
メニューから［Edit］>［Breakpoints］の順に選択します。
［Manage Breakpoints］ダイアログボックスが開きます。
ダイアログボックスに、設定したブレークポイントがすべてリストされます。
|
ブレークポイントの挿入場所 |
操作手順 |
|---|---|
|
ローカルのJavaクラス |
|
|
ロードされたクラス |
新しいブレークポイントが、［Manage Breakpoints］ダイアログボックスに表示されます。
［Toggle Breakpoints］を使用して個別のブレークポイントを削除する
メニューから［Edit］>［Breakpoints］の順に選択します。
［Manage Breakpoints］ダイアログボックスが開きます。
［Manage Breakpoints］ダイアログボックスのリストからブレークポイントが消えます。
ソースコードからブレークポイントが消えます。
メニューから［Tools］>［Clear All Breakpoints］の順に選択するか、またはDebuggerツールバーにある［Clear All Breakpoints］アイコン(次の図を参照)をクリックします。
Javaアプリケーションのソースコード本文でのブレークポイントの設定に加えて、標準のJavaの例外、または特定の動作を処理するために作成した例外に、ブレークポイントを設定することもできます。
この機能を使用すると、アプリケーションの実行時に予期せずスローされた例外のソースを特定できます。例外にブレークポイントを設定してからアプリケーションを実行すると、Debuggerは、例外がスローされた場所で停止し、デバッグしているクラスにソースコードがある場合は、問題のあるソースコードがDebuggerによって表示されます。ソースコードがDebuggerで見つからない場合は、パスを入力するように指示されます( ソースコードがDebuggerで見つからない場合の説明を参照)。
メニューから［Edit］>［Breakpoints］の順に選択します。
［Manage Breakpoints］ダイアログボックスが開きます。
［Exception］タブを選択して、［Add］をクリックします。
［Add Exception Breakpoint］ダイアログボックスが開きます。
ブレークする例外クラスの完全修飾名を入力するか、または［Browse］をクリックしてロード済みの例外のリストから例外を選択します。
［OK］をクリックして、［Manage Breakpoints］ダイアログボックスに戻ります。
新しいブレークポイントがリストされます。
Debuggerでは、コードおよび例外のブレークポイントを有効にしたり無効にしたりすることができます。無効になったブレークポイントは、グレーのアイコン(次の図を参照)で表示されます。
メニューから［Edit］>［Breakpoints］の順に選択します。
［Manage Breakpoints］ダイアログボックスが開きます。
アクティブにするブレークポイントをクリックし、［Enable］または［Disable］をクリックします。
複数のブレークポイントを選択するには、<Ctrl>キーまたは<Shift>キーを押しながら各ブレークポイントをクリックします。
選択したブレークポイントは、プログラム実行を続行する際に有効または無効になります。
使用するコマンド プログラムがブレークポイントで停止した場合は、Debuggerの［Continue］コマンドまたは［Run to Cursor］コマンドを使用して実行を続行できます。
行われること プログラムがブレークポイントに達すると、Debuggerウィンドウがアクティブになり、実行される行を示す矢印(「実行ポインタ」と呼ばれる)がコードの左側の余白に表示されます。
実行ポインタに加え、Debuggerでは、 ローカル変数およびインスタンス変数のリストが表示され、 コードを段階的に実行するコマンドが有効になります。
メニューから［Tools］>［Continue］の順に選択するか、またはDebuggerウィンドウのツールバーにある［Continue］アイコン(次の図を参照)をクリックします。
Debuggerでは、次のブレークポイントに達するまでソースコードを実行します。
カーソルは、実行可能なステートメントを含む行に配置する必要があります。
メニューから［Tools］>［Run to Cursor］の順に選択するか、またはDebuggerウィンドウのツールバーにある［Run to Cursor］アイコン(次の図を参照)をクリックします。
［Run to Cursor］によって、現在の実行場所から、カーソルが配置されている場所に達するまで、コードが実行されます。ブレークポイントが設定されていて、カーソルが置かれている行よりも前にブレークポイントを含む行が実行された場合、［Run to Cursor］により、そのブレークポイントの行で実行が停止されます。
注記: 実行されない行にカーソルを置くと(たとえば、if条件がfalseと評価された場合で、ifステートメント内のコードの最初の行にカーソルがあるとき)、［Run to Cursor］を実行した場合の結果は、［Continue］コマンドを選択した場合と同じになります。
exteNd Debuggerには、次の3つのステップコマンドが含まれています。
|
コマンド |
実行内容 |
詳細 |
|---|---|---|
|
［Step Over］ |
現在の行 |
現在の行にメソッド呼び出しが含まれている場合、そのメソッドが実行されます。Debuggerは、実行された行のすぐ後の行で停止します。 |
|
［Step In］ |
現在の行 |
現在の行にメソッド呼び出しが含まれている場合、Debuggerは、呼び出されたメソッドの最初の行で停止します。そうでない場合は、Debuggerは、実行された行のすぐ後の行で停止します。 入力されたメソッドのソースコードがDebuggerで見つからない場合は、パスを入力するように指示されます( ソースコードがDebuggerで見つからない場合の説明を参照)。 |
|
［Step Out］ |
現在のメソッドの残り |
Debuggerは、現在のメソッドを呼び出したステートメントのすぐ後のステートメントで停止します。 |
特定の操作のソースコードがDebuggerで見つからない場合は、ソースファイルへのパスを入力するように指示されます。パスを入力するか、またはプロンプトを閉じ、指示に従って 実行を続行するか、あるいは現在のメソッドから ステップアウトします。
ステップコマンドを実行した後
スレッドを一時停止および再開したとき
Debuggerには、プログラムの実行中にコールスタックを検査できるようにするビューアがあります。コールスタックビューアでは、スタックの各メソッドの名前が、ソースファイルおよび行番号とともに表示されます。
コールスタックビューアでメソッドをダブルクリックすると、Debuggerでソースファイルが開き、メソッドを呼び出す行が選択されます。ソースファイルがDebuggerで見つからない場合は、パスを入力するように指示されます( ソースコードがDebuggerで見つからない場合の説明を参照)。
コールスタックビューアでは、次の場合にコールスタックを更新します。
Debuggerには、プログラムの実行中にスレッドのステータスを検査できるようにするビューアがあります。スレッドビューアでは、グループ別に整理されたスレッドが表示され、各スレッドの名前が識別子および状態とともに表示されます。
デッドロックや無限ループなど、スレッドの同期化で発生した問題を孤立させる場合は、 スレッドを一時停止および再開することができます。
スレッドビューアでは、次の場合にスレッドステータスを更新します。
スレッドは、プログラムの実行中にさまざまな状態で表示されることがあります。
スレッドに無限ループまたはデッドロックが現れた場合は、スレッドを一時停止してそのコールスタックを表示することによって、問題を孤立させることができます。一時停止しない限り、スレッドのコールスタックは表示できません。
|
一時停止するスレッド |
操作手順 |
|---|---|
|
すべてのスレッド |
|
|
個別のスレッド |
スレッドビューアで、実行中または待機中のスレッドをダブルクリックします。 |
選択したスレッドのコールスタックが、コールスタックビューアに表示されます。
コールスタックのメソッドをダブルクリックし、Debuggerでコードを表示します。
待機中のスレッドをダブルクリックすると、そのスレッドを待機状態にしたメソッドがコールスタックビューアに表示されます。
選択したメソッドのソースコードがDebuggerで見つからない場合は、パスを入力するように指示されます( ソースコードがDebuggerで見つからない場合の説明を参照)。
|
再開するスレッド |
操作手順 |
詳細 |
|---|---|---|
|
ブレークポイントで一時停止されたすべてのスレッド |
次のいずれかの方法で、アプリケーションの実行を再開します。 |
|
|
ソースコード内でカーソルによって示される 特定の場所までアプリケーションを実行する |
||
|
個別のスレッド |
一時停止されているスレッドをスレッドビューアでダブルクリックします。 |
|
Debuggerには、プログラムの実行がブレークポイントで停止した場合にローカル変数およびインスタンス変数を検査できるようにするビューアが用意されています。変数ビューアでは、変数名、タイプ、および値が表示されます。
Debuggerで、メニューから［View］>［Variables］の順に選択します。
変数を表示するペインがDebuggerウィンドウに表示されます。
ローカル変数を表示するには［locals］をクリックし、現在のオブジェクトのインスタンス変数を表示するには［this］をクリックします。
|
キーストローク |
説明 |
|---|---|
|
Ctrl+C |
クリップボードにコピー |
|
Ctrl+G |
行番号に移動 |
|
Ctrl+F |
検索/置換 |
|
F5 |
続行 |
|
F10 |
ステップオーバー |
|
F11 |
ステップイン |
|
Shift+F11 |
ステップアウト |
|
Ctrl+F10 |
カーソルまで実行 |
|
|
ツールガイド 05/22/03 08:41:32 |
Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC, a wholly owned subsidiary of Novell, Inc. All rights reserved.
