Eclipseプラグインのサービス

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 中級

Jan Kratky, Lead, Workbench strategy for IBM internal tooling, FIT Team, IBM China Development Lab　

2003年 7月 08日

この記事ではEclipseプラグインを利用してお客様から報告された問題を分析する方法について説明します。この方法の中で、最も強力な機能はリモートホスト上のEclipseインスタンスから、実行中のEclipseインスタンスに接続してデバッグを実行するものです。今回の記事でご紹介する方法は、WebSphere Studio Application Developer やWebSphere Studio Site DeveloperのようなEclipse 2.xベースのすべての製品においても有効に活用することができます。

みなさんがEclipseプラグインを書けば、顧客にEclipseプラグインを提供することができます。するとおそらく、顧客はその代価を支払うことでしょう！そして遅かれ早かれ、顧客は問題を報告して来ます。時には、症状の報告だけで何が起こっているかを説明することができるでしょう。他の場合では、そのバグはユーザーのシステム構成や、プラグインを正しいバージョンで実際に実行しているかの再確認など、もっと多くの情報を必要とするような困難な状況を引き起こすこともあります。最悪の場合、みなさんの環境でその問題を再現することができず、実際に何が起こっているかを把握するため、ユーザーのマシンへ直接アクセスする必要があるでしょう。

朗報としては、ワークベンチ・ツールおよびプラグインのメタデータへアクセスする方法を少し知っていれば、顧客がプラグインに対して報告してくるあらゆる問題について分析することが可能です。この記事をお読みになれば、以下のことを理解されることでしょう。

• インストールされているプラグイン、機能、バージョン情報など顧客のワークベンチ構成について広く情報を得る方法
• ワークベンチ・エラーが記録される場所
• 特有のプラグインへの固有なメタデータがある場所
• みなさんのワークベンチで顧客の環境をデバッグする方法

ワークベンチ構成

Eclipseでは、実行中のワークベンチ・インスタンスの構成を簡単に抽出する方法を提供しています(図1を参照してください)。

1. ワークベンチのメイン・ツールバーから Helpメニューを開いてください。
2. About ...を選択してください(メニュー項目の文字列は常に「About」から始まります。しかし、「About IBM WebSphere Studio Application Developer」や「About IBM WebSphere Studio Site Developer」などのように、製品固有の文字列が含まれるかもしれません。これは使用しているワークベンチによります)。
3. 表示されるダイアログで、 Configuration Detailsボタンを押してください。

「Configuration Details」という名前のファイルが、エディターエリアに開かれます。このファイルは次の情報を含んでいます。

• ワークベンチのJRE実行環境下の全てのJavaシステム・プロパティ
• インストール済みの機能やプラグインの一覧、および各バージョン
• Install/Update Manager のログ
• ワークベンチのエラーログの全文

おそらく、みなさんは顧客に全てのログのコピーを送ってもらうことを望むことでしょう。幸い、ファイルシステムにログを保存することは簡単です。

1. Configuration Detailsファイルを開いているエディターが最前面にありフォーカスがあたっていることを確認してください。
2. ワークベンチのメイン・ツールバーから Fileメニューを選択してください。
3. メニューから Save Configuration Details As...を選択してください。

この記事の参考文献のリンクから実際のconfiguration fileの例をダウンロードすることができます。

図1のAbout...ダイアログでは、Feature Details とPlug-in Detailsというさらに2つのボタンがあることに注目してください。これらのボタンのどちらかを押すと、plug-insまたはfeaturesの構成、およびそれらのバージョンがダイアログに表示されます。プラグインが実際にインストールされているか、また間違いのないバージョンでインストールされているかをすぐに知りたければ、顧客にConfiguration Detailsファイルを送ってもらうのではなく、最初にこのダイアログでリストをチェックしてくれるように依頼してもよいでしょう。

上に戻る

ワークベンチのエラーログ

エラーログには、ワークベンチやプラグイン・コードが記録することにしたメッセージと例外が時系列で記録されています(新しいメッセージはファイルの最後にあります)。ワークベンチは、すべてのuncaugh exceptionを自動的にエラーログに記録します。

エラーログのテキストは、前のセクションで生成したConfiguration Detailsファイルに含まれています。Eclipseには、エラーログについてのグラフィカルなビューであるError Logビューが提供されています。このError Logビューは、PDE Runtimeビューのカテゴリー下に存在しています。(ビューを開くには、Window >Show Viewを選択してください)。エラーログのエントリーがテーブルに列として表示されます。最新のエントリーは最上列に表示されます。列を選択し、右クリックでPropertiesを選択することで、エントリーの詳細を見ることができます。プロパティ・ダイアログにおいては、個々のログ・エントリーの詳細はStatus Detailsページに表示されます。図2を参照してください。

エラーログ・ファイルはワークスペースのルートに対して、.metadata/.logとしてファイルシステム上に存在します。ワークスペースのルートは、ワークベンチのインストールディレクトリーにworkspaceという名のフォルダーとして配置されます(これがEclipseのデフォルト・ワークスペースの場所です)。しかし、ユーザーは、ファイルシステム上の任意のフォルダーにワークスペースのルートを設定することも可能です。

上に戻る

プラグイン・レジストリー

Configuration Detailsファイルは、ワークベンチのインスタンスにインストールされている機能およびプラグインを列挙しています。しかし、個々のプラグインが稼動中であるかどうかまでは示していません。

プラグインはゆっくりとロードされます。すなわち、コードが必要とされるまで、プラグインのコードはメモリーにロードされません。その結果、プラグインがインストールされているものの、何らかの理由で起動されないという状況が発生するかもしれません。これは、ワークベンチがプラグインのロードを試みた際にエラーが発生したか、単にプラグインの機能へまだアクセスされていないかのいずれかを意味しています。

Plug-In Registry ビューはインストール済みのプラグインを列挙し、各プラグインが稼動中であるかどうかを表わしています。このビューを開くためには、Window >Show Viewを選択してください。ビューはPDEランタイムのカテゴリー下に存在しています。

プラグインは名前で順序付けられています(プラグインIDではなく、名前が表示されます)。「runner」アイコンがプラグイン・アイコンに重ねて表示される場合、プラグインは稼動中です。

図3では、サンプルのワークベンチのPlug-in Registry ビューを示しています。「Apache Axis」という名前のプラグインのアイコンに「running」の飾りが付いているように、表示されているすべてのプラグインが稼動中ではないことに注意してください。

プラグインが稼動中(あるいは非稼働中でも)の場合、Plug-in Registry ビューは自動的に更新されません。現在のプラグインの使用可能かどうかといった状態を知るためには、ビューのタイトル・バーにあるRefreshボタンを押してください。そうでなければ、ビューは最初に表示された時の状態を表示し続けることになります。

上に戻る

プラグイン・メタデータ

プラグインは通常、それ自体に特有なメタデータを保持しています。このメタデータは、プロパティ・ファイル、XMLファイル、独自のバイナリフォーマットといった任意の形式をとります。メタデータが判読可能な形式である場合、直接メタデータ・ファイルを調べる事は有効かもしれません。

プラグイン・メタデータはワークスペースのルートに対して、.metadata/.pluginsディレクトリー下のファイルシステム上に存在します。.pluginsディレクトリー内には、それ自身がメタデータを保持している各プラグインのフォルダーがあります。それぞれのフォルダーの名前は対応するプラグインのIDと同じです。プラグイン用のメタデータはフォルダー内に存在します。

プラグインの作成者はプラグインのインストール・フォルダーにあるデフォルトpreferences.iniファイルを使用することにしているかもしれません。インストール・フォルダーとはプラグインIDからなり、インストールが行われたプラグイン・ディレクトリーに位置します。(一般に、このディレクトリーは、ワークベンチをインストールしたルート配下に存在しますが、プラグインをインストールする場所は設定可能であることを心に留めておいてください)。

ここで説明した場所に、プラグインがメタデータを保持することが、ワークベンチの慣習となっていることに注目してください。しかし、プラグインの作成者がこの慣習を無視して、システムのtempディレクトリーのような別の場所にメタデータを格納する可能性にも注意を払っておくべきです。

上に戻る

リモート・ワークベンチのデバッグ

Eclipseプラグイン・コードが提供している最も強力なツールは、顧客のワークベンチがリモート・マシン上で実行中の場合でさえ、デバッグができるEclipseデバッガの能力です。ネットワーク・アクセスが可能なマシン上において、ワークベンチ・インスタンス上で生じる問題をデバッグするためにデバッグ・パースペクティブを使用することができます。リモート・ワークベンチは、オープン・ソケットを通してそのデバッグ情報を表示します(リスト1は、デバッグ・ソケットを開くために指定する必要があるEclipse起動引数を示しています)。一度顧客のワークベンチへデバッガをアタッチしたら、ブレークポイントをセットし、変数および実行スタックを調べることで、Eclipseデバッガの力を有効に活用することができます。(Eclipse Javaデバッガの使用に関する詳細については、ワークベンチのヘルプにおいて参照できます。ワークベンチのHelp >Help Contentsメニューからアクセスしてください)。

重要:ワークベンチのワークスペース内のソース・コードは、顧客がインストールしたプラグインのバージョン構築用に使用されたコードと一致していなければなりません。この先へ進む前に、顧客がインストールしたコードを判断し、みなさんのワークスペースのコードが顧客のコードと一致していることを確認しなければなりません。

ソース・コードが正しいレベルであることを確認したならば、顧客は、リモート・デバッガによるアタッチを可能にするために、リスト1に示される引数を備えたワークベンチを起動しなければなりません。

                
eclipse.exe -vmargs -Xdebug -Xnoagent \
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

addressに割り当てられた値に注目してください。これは、リモート・デバッガによるアタッチを可能にしているポート番号です。上の例の引数では、ポート番号は8000です。顧客はファイアウォールの後ろにいるかもしれず、またソケット接続をするためにはポートを設定する必要があるかもしれないことを認識しておいてください。

server=yの指定は、起動しているVMがソケット接続を待つということを示しています。suspend=nの指定は、Javaクラスの実行の継続を許可します。suspend=yの指定では(あるいは、yはデフォルト値なので、suspend指定全体を省略することにより)、メインクラスをロードする前にすぐに実行を停止するということを起動しているVMに伝えます。

では、ワークベンチから、顧客のセッションにデバッガをアタッチします。

1. デバッグ・パースペクティブに切り替えます( Window > Open Perspective)。
2. メインのワークベンチ・メニューから、 Run > Debug...を選択してください。(あるいは、ワークベンチ・ツールバーにある Debug ボタンのドロップダウン・メニューから、 Debug...を選択してください。)。
3. 起動設定ダイアログで、左のビューより Remote Java Application エントリーを選択してください。
4. Newボタンをクリックしてください。 Connect, Source, Commonという3つのタブで構成されている、新しいリモート起動設定が作成されます。
5. Connectタブの Projectフィールドには、起動時の参照(ソースの参照)として使用するプロジェクトを入力するか、参照指定してください。リモート・ワークベンチのデバッグに関しては、プロジェクトを指定する必要がありません。
6. Connectタブの Hostフィールドには、Javaプログラムを実行中のホストのIPアドレスかドメイン名を入力してください。プログラムがワークベンチと同じマシン上で実行中の場合は、 localhostを入力してください。
7. Connectタブの Portフィールドには、リモートVMが接続を受け付けているポートを入力してください。この例においては、値は8000です。リスト1の引数でリモート・ワークベンチを起動する際は、指定するポートを一致させてください。
8. Allow termination of remote VM フラグは、Terminateコマンドがデバッガ中に使用可能かどうかを決めるトグルです。接続しているVMを終了させたい場合は、このオプションを選択してください。普通は、選択する必要はありません。
9. Debugをクリックしてください。指定のアドレスやポートでVMへの接続を試みます。また、その結果はDebugビューに表示されます。指定のアドレスでVMに接続することができない場合、エラーメッセージが表示されます。

これで、顧客のワークベンチに接続することができます。ユーザーにワークベンチで任意のアクションを行なってもらうと、顧客のワークベンチの状態がデバッグ・セッションに反映されます。

この方法でデバッグをする際、WinVNCやLotus Sametimeによって提供されているようなリモート・コントロールの機能を使用して、顧客のデスクトップを直接操作したいと思われるでしょうが、これにより、顧客のワークベンチ上で自分でアクションを開始することができます。

コードが正しいことを読み取れれば、トレース・メカニズムの代わりにこのテクニックを使用することができます。Eclipse は素晴らしいトレース・フレームワークを提供していますが(参考文献のリンクを参照)、その他のトレース・メカニズムのように、トレース文を作るためにはプラグイン・ソースにコードを挿入する必要があります。この追加されたコードにより、トレース終了後もパフォーマンスに不利益が生じ、また明らかにコードの足跡を残してしまうことになります。更に、トレースは開発者にも左右されます。つまり、必要とするポイントにトレース文が挿入されなかった場合、トレースは全く手助けとはなりません。しかし、リモート・デバッグのテクニックでは、このうちのどれについても心配する必要はありません。これで、十分なソースレベルのデバッグができます。

上に戻る

顧客サービスのための提案手段

この記事では、Eclipse プラグインを用いて顧客の問題を分析するための一連のツールを見てきました。それぞれの開発グループにとって最良の方法でこれらのツールを使用する方法についてはみなさんにおまかせします。顧客サービスへの1つの提案手段は次のようなことです。

1. バグ・レポートから問題を再現することができない場合は、顧客にconfiguration fileのコピーを送ってもらってください。みなさんのプラグイン・バージョンがユーザーのバージョンと同じであることを裏付けるためにこれを使用してください。さらに、証拠となるメッセージのエラーログおよびスタックレースについて念入りに調べてください。
2. プラグインの稼動に関する問題の場合は、顧客のplug-in registry viewを確認することでユーザーに対応してもらうこともできます。
3. プラグインのメタデータの取り扱いにおけるエラーか、ユーザーが特殊な方法でプラグインをセット・アップした場合は、疑わしいと思われるプラグイン固有のメタデータ・ファイルのコピーをユーザーに送ってもらってください。
4. それ以外のエラーの場合は、みなさんのワークスペース内に適切なソースをロードして、リモートで顧客のワークベンチをデバッグしてください。

もちろん、顧客の問題の核心に迫るために、柔軟にケースバイケースで物事を実行しなければなりません。

上に戻る

結論

Eclipseベースのワークベンチは、詳細な構成情報を見ることから顧客がインストールしたもののコード・レベルのデバッグまでの機能を備えた広範囲の保守性を提供しています。

参考文献

• Eclipse Platformコミュニティーへの参加や、Eclipse Platformのダウンロードについては、eclipse.org にアクセスしてください。Eclipse Platformのソース・コードのライセンス形式はCommon Public Licenseです。eclipse.orgでは、用語集、Eclipseプロジェクトの解説、技術的な記事やニュースグループなども用意しています。Eclipse Platformの白書には、Eclipseの主要なコンポーネントと機能の詳しい解説があります。
  
  
• サンプルのconfiguration fileをダウンロードしてください。
  
  
• Eclipse Platform Plug-in SDKのダウンロードについては、Eclipseプロジェクト・ダウンロード・ページをご覧ください。
  
  
• Eclipse用プラグイン・レジストリーを閲覧できます。
  
  
• Eclipseのパフォーマンスを改善する取り組みを参照して、プラグインのロードに関する詳細について学習してください。
  
  
• Eclipse Platformの機能に関する入門記事を読みたい方は、Greg Adams氏とMarc Erickson氏によるdeveloperWorks記事、「Eclipse Platformの利用」をご覧ください。
  
  
• Eclipse Platformによるアプリケーション開発の入門記事を読みたい方は、David Gallardo氏によるdeveloperWorks記事、「Eclipse Platform入門」をご覧ください。
  
  
• 独自のEclipseプラグインの作成に興味がある方は、David Gallardo氏によるdeveloperWorks記事、「Eclipseプラグインの開発」をご覧ください。
  
  
• Eclipseのソース・コードのバージョンを管理する方法については、Pawel Leszek氏によるdeveloperWorks記事、「Eclipse Platformを使用したコードの共有 」を参照してください。これは、CVSのバージョン管理統合インタフェースについて詳細に記述しています。
  
  
• Eclipse platformの組み込みデバッグ機能に関する詳細については、Pawel Leszek氏によるdeveloperWorks記事、「Eclipse Platformを使用したデバッグ」を参照してください。
  
  
• developerWorksでEclipseユーザーのためのより多くの参考文献を見つけてください。
  

著者について

		Jan Kratky氏はJava1.0のリリース以来開発に携わっています。彼はIBMの内部ツールのワークベンチ戦略のリーダーです。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る