1.0 概要
2.0 既知の問題
2.1 Web 開発環境
2.2 WebSphere Application Server のデバッグ
2.3 JavaScript デバッガー
2.4 SQL ストアード・プロシージャーのデバッガー
2.5 テスト・ツールとデプロイメント・ツール (サーバー・ツール)
2.6 Java 開発ツール (JDT) デバッガー
2.7 各国語の制限
2.8 SQL ストアード・プロシージャー・デバッガー (Linux)
2.9 SQLJ デバッガー
WebSphere Studio 内のデバッガーは、Web アプリケーション、サーバー・サイドの JavaScript、Java、SQLJ、SQL ストアード・プロシージャー、コンパイル言語などのデバッグに必要なツールを提供します。この README ファイルは、WebSphere Studio デバッガーに関する既知の問題および制限について説明しています。
JSP デバッグ:
- JSP ファイルは WebSphere Application Server でのテスト中にデバッグすることが可能です。 Tomcat サーバーでのテスト中は、デバッガーは JSP ブレークポイントで停止しません。
- JSP ファイルの以下のタグの中にブレークポイントを設定することができます。
- フォームの JSP スクリプトレット: <% %>
- フォームの JSP 式: <%= %>
- フォームの JSP 宣言: <%! %>
- jsp:useBean、jsp:getProperty、および jsp:setProperty タグ
- カスタム・タグ
- 以下のタグ・セットにはブレークポイントは設定できません。
- HTML コード
- JSP ディレクティブ
- その他のすべての標準 JSP タグ (jsp:include、jsp:forward、など)
- 従来のバージョンの WebSphere Studio から現行バージョンにワークスペースをマイグレーションする 場合、JSP ブレークポイントを削除して再作成する必要があります。
- EJB ホーム・メソッドでは、段階的デバッグ・モードは失敗する: WebSphere Application Server デバッグ・アダプターを使用してデバッグ・セッションを起動すると、段階的なデバッグ・モードは EJB ホーム・メソッドで停止しません。これらのメソッドをデバッグする場合はブレークポイントを使用してください。
- Java から JavaScript へのステップ・リターンはサポートされない: Java から JavaScript コードへ戻る必要があるときはブレークポイントを使用してください。
- JSP のデバッグ:
- 実行可能コードを含まない JSP については段階的なデバッグ作業はできません。
- デバッグ・セッションを起動するために WebSphere Application Server デバッグ・アダプターを使用すると、JSP 変数と JSP 式を検査したり表示することはできません。
- JSP では、「この行まで実行 (Run to line)」はサポートされていません。
- JSP ブレークポイントの設定は時間がかかります。多くの JSP ブレークポイントがあるときには、 デバッガーの初期化により多くの時間がかかることを考慮してください。
- JSP 宣言ブロック内の静的変数のブレークポイントは機能せず、他のブレークポイントで問題を起こす場合があります。
- hit count、condition、selected thread、および VM suspend policy などのブレークポイント・プロパティーは JSP のブレークポイントではサポートされていません。
- デバッガー・エディターには Java ブレークポイントを設定しない: Java ブレークポイントは、デバッガー・エディターではなく、Java エディターに設定しなければなりません。
- 「ソース・ファイルの変更デバッグ (Change Source File Debug)」ビューのポップアップ・メニュー項目の使用: スタック・フレーム上の「ソース・ファイルの変更 (Change Source File)」ポップアップ・メニュー項目を使用して表示されたソース・ファイルを変更すると、 エディターで新しいファイルを開くことができない場合があります。 これを回避するには、別のスタック・フレームをクリックし、そのあと元のスタック・フレームをもう一度クリックしてください。これでエディターに新しいファイルが開かれるはずです。
- デバッグ・コンソール: デバッグ・コンソールでは、タイプをオープンするハイパーリンクは機能しません。
- ホット・スワップの後のスタック・フレーム・ラベル: ホット・コードを置き 換えた後で、一部のスタック・フレームのラベルは以下のようになります。
<unknown receiving type>(<unknown declaring type>).<unknown method name>(<unknown arguments>) line: not available <unknown line number>この場合、別のパースペクティブに切り替えることによって正しいラベルを取得し、 次にデバッグ・パースペクティブに戻すことができます。
- JavaScript オブジェクトは、そのコンストラクターが完了するまで、検査の目的で使用できない: ユーザーはコンストラクターの実行を段階的に実行することはできますが、構成が完了 (コンストラクターを終了) するまでは、構成されているオブジェクトを検査できません。
- トップ・スタック・フレーム以下のステップ・フレームとスタック・フレーム: JavaScript では、トップ・スタック以外のスタック・フレームのステップオーバーおよびステップ・リターンはサポートされていません。
- JSP の include: JSP の include では JavaScript のデバッグはサポートされていません。
- 再帰的関数から外に出る: 再帰的 JavaScript 関数をデバッグ中、再帰的関数から外に出ると、実行レベルのトップに戻ります。
- writer または inputStream の変数が組み込まれているオブジェクトは拡張しない: ユーザーは、JavaScript オブジェクトを調べるときに、writer または inputStream の変数が組み込まれているオブジェクトを拡張しないように注意してください。 この操作を行うと、デバッガーが応答しなくなります。
- テスト環境: JavaScript デバッグは、WebSphere V5 テスト環境で使用した場合、機能しません。この問題は、APAR #PQ73036 で修正済みです。
- Data Definition ビュー内でデータベースをインポートまたは削除すると、設定したブレークポイントが失われる場合がある: Data Definition ビュー内のフォルダーにデータベースをインポートする前に、SQL ストアード・プロシージャーをデバッグし、そしてデータベースをインポートすると、ユーザーの作成した行ブレークポイントはいずれも失われます。データベースを一度インポートすると、デバッガーはそのフォルダーをソースの表示に使います。インポートしたデータベース情報を削除すると、次回に SQL ストアード・プロシージャーをデバッグするときにブレークポイント情報も失います。これによって、データベースを最初にインポートしたときに失ったブレークポイントをリストアすることはできません。
この問題を避けるため、ストアード・プロシージャーのデバッグを開始する前にデータベースをインポートすることをお勧めします。
- Java ストアード・プロシージャーのデバッグはサポートされていません: エディターで、Java ストアード・プロシージャーのソース・コードにブレークポイントを追加することはできます。 しかし、Java ストアード・プロシージャーのデバッグがサポートされていないため、これらのブレークポイントは無視されます。
- 区切りストアード・プロシージャー名: SQL ストアード・プロシージャー・ デバッガーでは、区切りスキーマまたはプロシージャー名を持つストアード・プロシージャー に対するサポートは限定されています。そのようなプロシージャーは、データ定義ビューの コンテキスト・メニューからではなく、「構成の開始 (Launch Configuration)」ダイアログ から起動する必要があります。
- 複数のアクティブ SQL ストアード・プロシージャー・デバッガー・セッションの同時オープン・サポート: 本製品のバージョン 5.0 では、複数のアクティブ SQL ストアード・プロシージャー・デバッガー・セッションを一度に開くことはできません。この制限は、バージョン 5.0.1 以降には適用されません。
- FOR BIT DATA 引き数を含むストアード・プロシージャー: FOR BIT DATA 属性の引き数を持つストアード・プロシージャーは、WebSphere Studio SQL ストアード・プロシージャー・デバッガーでデバッグすることはできません。
- 早期提供バージョンの製品で作成された起動構成は現行製品で認識できない可能性があります: この製品の早期提供バージョンをインストールしてストアード・プロシージャーのデバッガーの起動構成を作成した場合、それを製品の現行バージョンで使用すると、その起動構成の設定は認識されない可能性があります。早期提供バージョンで保管された起動構成設定は、製品の現行バージョンでオープンされると、デフォルト値に戻される場合があります。
サーバーをデバッグ・モードで実行する場合は、以下の点を考慮してください。
- サーバーの開始と実行は、非デバッグ・モードでの実行より遅い場合がある。
- WebSphere Application Server では JSP ページのコンパイルに相当に長い時間を要する。
Java 開発ツールについての既知の問題および制限に関しては、Java 開発ツール (JDT) のリリース情報および ワークベンチ (IDE) リリース情報を参照してください。 これらの資料には、本製品とともにインストールされるメインの製品 README からリンクがあります。
- 双方向 (BiDi) の制限: ネイティブ・コード・ページ以外のコード・ページでエンコードされた JSP をデバッグ中にデバッガー・エディターを使うことはできません。
- コンパイル済み言語デバッガー:
- シングル・バイト (SBCS) システムの場合、 コンパイル済み言語デバッガーは、0x7F を超える文字を含むプログラム名や、それらの文字を含むプログラム・パラメーターの 受け渡しをサポートしていません。
- debuggee 名および debuggee 引き数での NL 文字の使用は サポートされていません。
ローカル・データベースで SQL ストアード・プロシージャーのデバッグを行う場合、エラー番号 SQL1224N を受け取る場合があります。
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command. SQLSTATE=55032
これは、Linux カーネルにおける問題です (Linux カーネル Bugzilla bug #351)。以下に、Call Level Interface (CLI) の代わりに、DB2 の TCPIP 接続方式 (ループバックとして) を使用する回避方法を示します。この手順では、デバッガーで以前と同じデータベース別名を使用することができます。
- リモート DB2 クライアントのポートが設定されていない場合は、/etc/services に TCP/IP ポートを作成してください (例、db2cdb2inst1 50000/tcp # DB2 connection service port)。リモート DB2 クライアント用の既存のポートを使用することができます。
以下のステップ 2 〜 7 では、DB2 インスタンス所有者としてログインする必要があります。
- TCP/IP 通信プロトコルの接続マネージャーを開始するよう、データベース・マネージャーを構成します。既にこれが行われているか不明の場合には、次のコマンドを実行します。
db2set db2comm出力にキーワード tcpip が含まれていなければ、次のコマンドを入力して、tcpip を組み込むよう db2comm レジストリー変数を更新する必要があります。
db2set db2comm=<existing protocol names>,tcpipdb2comm レジストリー変数によって、データベース・マネージャーが開始された場合に使用可能にするプロトコルの接続マネージャーが決定されます。この変数は、キーワードをコンマで区切ることにより、複数の通信プロトコルに設定することができます。例、db2set db2comm=tcpip,appc
db2comm レジストリー・パラメーターで指定されたプロトコルの接続マネージャーを開始するには、db2start コマンドを再度実行する必要があります。以下のステップ 7 で DB2 を再始動するので、ここで実行する必要はありません。
.- SVCENAME データベース・マネージャーの構成パラメーターを、/etc/services (ステップ 1) で定義された接続サービス名により更新します。
SVCENAME の現在の設定をチェックするには、次のコマンドを入力します。
db2 get dbm cfg | grep -i svcenameSVCENAME の設定を更新する必要がある場合には、次のコマンドを入力します。
db2 update dbm cfg using svcename <connection service name><connection service name> には大文字小文字の区別があり、/etc/services に配置されたサービス・ポートの名前に一致する必要があります (例、db2 update dbm cfg using svcename db2cdb2inst1)。
データベース・マネージャー構成の更新は、次回 db2start コマンドを実行するまで有効になりません。これは、以下のステップ 7 で行います。
- 次のコマンドを入力して、ループバック・ノードをカタログします。
db2 catalog tcpip node <nodename> remote 127.0.0.1 server <connection service name><nodename> は、カタログするノードのローカル別名です。これは、ワークステーション上の任意の名前で、ノードの識別に使用されます (例、db2 catalog tcpip node mynode remote 127.0.0.1 server db2cdb2inst1)。
catalog コマンドが正しく機能したかを確認するには、次のコマンドを実行します。
db2 list node directoryこのコマンドのサンプル出力は、次のとおりです (ブランク行は便宜上省略してあります)。
Node Directory
Number of entries in the directory = 1
Node 1 entry:
Node name = MYNODE
Comment =
Protocol = TCPIP
Hostname = 127.0.0.1
Service name = db2cdb2inst1- 次のようにデータベースをカタログします。各コマンドの結果を追跡するには、以下のコマンドを参照して、サンプル出力を作成してください。
- db2 catalog db <database name> as <database alias>
- db2 uncatalog db <database name>
- db2 catalog db <database alias as <database name> at node <nodename>
例
db2 catalog db WAS as WASLOOP
db2 uncatalog db WAS
db2 catalog db WASLOOP as WAS at node MYNODE注:
- データベース別名は、任意の名前にすることができますが、データベース名と同じにすることはできません。
- データベースを正しくカタログしない場合には、エラー番号 SQL1334N を受け取ります。
- ストアード・プロシージャーをデバッグするデータベースごとに、ステップ 5a〜5c を繰り返します。
ステップ 5a〜5c のサンプル出力
ステップ 5a の前に、ローカル・データベース WAS が作成済みです。コマンド db2 list db directory の出力は、次のとおりです。
System Database Directory
Number of entries in the directory = 1
Database 1 entry:
Database alias = WAS
Database name = WAS
Local database directory = /home/ctsui
Database release level = 9.00
Comment =
Directory entry type = Indirect
Catalog node number = 0ステップ 5a の後の db2 list db directory の出力は、次のとおりです。
System Database Directory
Number of entries in the directory = 2
Database 1 entry:
Database alias = WAS
Database name = WAS
Local database directory = /home/ctsui
Database release level = 9.00
Comment =
Directory entry type = Indirect
Catalog node number = 0
Database 2 entry:
Database alias = WASLOOP
Database name = WAS
Local database directory = /home/ctsui
Database release level = 9.00
Comment =
Directory entry type = Indirect
Catalog node number = 0ステップ 5b の後の db2 list db directory の出力は、次のとおりです。
System Database Directory
Number of entries in the directory = 1
Database 1 entry:
Database alias = WASLOOP
Database name = WAS
Local database directory = /home/ctsui
Database release level = 9.00
Comment =
Directory entry type = Indirect
Catalog node number = 0ステップ 5c の後の db2 list db directory の出力は、次のとおりです。
System Database Directory
Number of entries in the directory = 2
Database 1 entry:
Database alias = WAS
Database name = WASLOOP
Node name = MYNODE
Database release level = 9.00
Comment =
Directory entry type = Remote
Catalog node number = -1
Database 2 entry:
Database alias = WASLOOP
Database name = WAS
Local database directory = /home/ctsui
Database release level = 9.00
Comment =
Directory entry type = Indirect
Catalog node number = 0
catalog db コマンドが正しく機能したかを確認するには、次の 2 つのコマンドを実行します (サンプル出力は以下のとおりです)。
db2 connect to wasloop
db2 connect to wasdb2 connect to wasloop により接続情報が印刷され、db2 connect to was で SQL1403N が示されます。
db2 connect to wasloop のサンプル出力:
Database Connection Information
System Database DirectoryDatabase server = DB2/6000 6.1.0
SQL authorization ID = CTSUI
Local database alias = WASLOOPdb2 connect to was のサンプル出力:
SQL1403N The username and/or password supplied is incorrect. SQLSTATE=08004- 認証手段をクライアント認証 に更新します。次のコマンドを入力します。
db2 update dbm cfg using authentication client
コマンドが正しく機能したかを確認するには、次のコマンドで新しい設定を表示します。
db2 get dbm cfg
サンプル出力:
....
Database manager authentication (AUTHENTICATION) = CLIENT
....- DB2 を再始動して、ディレクトリー・キャッシュをリフレッシュします。例、
db2stop
db2start- WAS の場合、admin.config ファイルを更新する必要はありません。Websphere アプリケーションの場合、既存のデータ・ソース構成を変更する必要はありません。
- データベースを除去するには、次の作業を行います。
- db2 attach to <nodename> user <userid> using <password>
- db2 drop db <database name>
例、db2 attach to MYNODE user myid using mypasswd
db2 drop db WAS
J9 JVM を使用したデバッグの間にホット・スワップを行う場合、呼び出しスタックに SQLJ メソッドが存在すると、「スタックの廃止メソッド (Obsolete methods on the stack)」ダイアログが表示されます。ホット・スワップのクラスが SQLJ の場合、クラスが JVM に再ロードされますが、クラスのメソッドの次回の呼び出しまで新しいコードの実行は表示されません。
SQLJ クラスをホット・スワップする場合、現在のデバッグ・セッション中はこのクラスで SQLJ ブレークポイントは機能しません。
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.