| Oracle Application Development Framework開発者ガイド 10g（10.1.3.0） B40012-02 |
|
 戻る |
 次へ |
この章では、ユーザー・インタフェース・プロジェクトをデバッグするプロセスについて説明します。また、デバッグのブレークポイントを設定する際に使用できる、Oracle ADFモデルAPIのメソッドについても説明します。
この章の内容は次のとおりです。
WebアプリケーションとOracle ADFとの対話のデバッグは、他のデバッグ・タスクと同様に、特定の要因を切り分けするプロセスです。ただし、Webアプリケーションの場合は一般に、このプロセスでJavaソース・コードのコンパイルが行われません。このため、Webページにはコンパイル用のJavaソース・コードは含まれません。実際には、アプリケーションを実行して使用してみるまで、問題が存在しているかわからないことがあります。たとえば、次のような障害は実行時に初めて現れます。
ページが見つからないというサーブレット・エラー
ページは見つかるが、コンポーネントがデータなしで表示される
メソッド・コールまたは組込み操作（「Next」や「Previous」など）の実行後、ページにデータが表示されない
ページは表示されるが、メソッド・コールまたは組込み操作をまったく実行できない
ページは表示されるが、予期しない検証エラーが発生する
データを表示できない、またはメソッド・コールを実行できない場合、WebページのコンポーネントとOracle ADFモデル・レイヤーの間の対話に原因があります。ADFライフサイクル処理中にランタイム・エラーが観測されると、モデルの準備、値の更新、アクションの起動、データのレンダリングという一連の処理の完了が失敗します。
幸い、WebアプリケーションとOracle ADFの対話における失敗は、アプリケーションにより定義された宣言情報か、ページのOracle ADFバインディング・コンテナのランタイム・オブジェクトにアクセスするEL式の中にある、修正が容易な単純なエラーが原因であることがほとんどです。
このため、Oracle ADFのデータ・バインド済アプリケーションでランタイム障害が観測された場合は、その原因として考えられる宣言情報とEL式を調べる必要があります。次の各項では、宣言ファイルの編集について説明します。
アプリケーションの実行中に使用できる（デバッグ・セッション全部を起動する必要のない）最も便利な診断ツールは、ADF Loggerです。Oracle ADFモデル・レイヤーAPIからランタイム・トレース・メッセージを取得するには、JDeveloperでこのJ2EEロギング・メカニズムを使用します。ADFロギングが有効になっている場合、JDeveloperにより、メッセージ・ログ・ウィンドウ内にアプリケーション・トレースが表示されます。このトレースには、アプリケーション・エラーの原因をすぐに特定できるランタイム・メッセージが含まれます。詳細なトレース・メッセージが表示されるようにADF Loggerを構成するには、16.4項「一般的なOracle ADFモデルのデバッグ・セッションの概要」を参照してください。
エラーを容易に特定できない場合は、JDeveloperのデバッグ・ツールを使用して、アプリケーションの実行と、Oracle ADFページのライフサイクルの様々なフェーズをステップ実行できます。このプロセスによって、エラーが発生した正確な箇所を切り分けできます。デバッグ・ツールを使用すると、アプリケーションの実行をOracle ADF API内の特定のメソッドで一時停止し、Oracle ADFバインディング・コンテナが持つデータを調べ、それを本来の期待されるデータと比較することができます。Oracle ADFモデル・レイヤーのデバッグについては、16.5項「Oracle ADFモデル・レイヤーのデバッグ」を参照してください。
EL式をデバッグする際に、ヘルプが必要な場合があります。ELは多数の便利な例外に関して十分にサポートされているわけではありませんが、JSFトレース・メッセージを有効にして、変数解決を調べることができます。JSFトレース・メッセージを使用するには、16.6項「EL式のトレース」を参照してください。
JDeveloperで、Webページを作成し、ADFデータ・コントロールを使用してADFバインディング定義を作成するとき、編集するOracle ADF宣言ファイルは、Oracle ADFにより定義されたXMLスキーマに準拠している必要があります。XML構文エラーが発生すると、JDeveloper XMLコンパイラによって即時に構造ウィンドウ内にエラーが表示されます。JDeveloperの「表示」メニューから「構造」を選択して、XMLエディタで編集するOracle ADFファイルに対して構造ウィンドウを開きます。
現在、JDeveloperコンパイラではEL式の解決機能に制約があります。Webページ内のEL式は、Web環境における様々なランタイム・オブジェクト（WebページのOracle ADFバインディング・コンテナなど）と直接対話します。現在、EL式内のエラーは実行時にしか観測できません。このため、オブジェクト・アクセス式に入力エラーが1つ存在していても、コンパイラでは検出されませんが、実行時にバインディング・コンテナと対話できず、ページにデータが表示されないことでそれが明らかになります。ラインタイム・エラーのデバッグの詳細は、16.3項「単純なOracle ADFランタイム・エラーの修正」を参照してください。
|
ヒント: JDeveloperの式ビルダーは、オブジェクト、マネージドBeanおよびプロパティのリストを提供することでEL式の作成を支援するダイアログです。式ビルダーでは、ADFバインディング・オブジェクトとその有効なプロパティが階層リストで表示されます。式に使用するオブジェクトやプロパティをこのリストから選択できるため、ADFデータ・バインドされたEL式を作成または編集するときに特に便利です。入力エラーを未然に防ぐために、式ビルダーを使用することをお薦めします。詳細は、5.6.2項「式ビルダーの使用方法」を参照してください。 |
例16-1に、ページ定義ファイルに含まれた単純なコンパイル・エラーを示します。"false"となるべきところが"fase"に、"IsQueriable="false"/>"となるべきところが"IsQueriable="false"/"（終了の山カッコがない）となっています。
例16-1 2つのエラーが含まれたサンプル・ページ定義ファイル
<?xml version="1.0" encoding="UTF-8" ?>
<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel"
version="10.1.3.35.62" id="browseusersPageDef"
Package="oracle.srdemo.view.pageDefs"
EnableTokenValidation="fase"
...>
<parameters/>
<executables>
<variableIterator id="variables">
<variable Type="java.lang.String" Name="findUsersByName_name"
IsQueriable="false"/
前述のエラーに対する構造ウィンドウは、図16-1のように表示されます。
アプリケーションのコンパイルを試行すると、コンパイラ・ウィンドウにも同様のエラーが表示されます（図16-2）。
スキーマ検証エラーを修正するには、構造ウィンドウまたはコンパイラ・ウィンドウのいずれかで、エラーをダブルクリックしてファイルを開きます。ファイルがXMLエディタ内に開かれ、修正の必要がある行が強調表示されます。
エラーを修正すると、構造ウィンドウから即時にエラーが削除されます。オプションで、変更済のファイルを再コンパイルするためのmake操作を使用してプロジェクトを再コンパイルし、空のコンパイラ・ウィンドウを確認することもできます。
Oracle ADFモデル・レイヤーの障害は、JDeveloperコンパイラによって検出されません。ページのデータ表示およびメソッド実行の動作がOracle ADFページ定義ファイルの宣言に依存していることが、この一因です。Oracle ADFモデル・レイヤーは、実行時にこれらの宣言ファイルを使用して、Oracle ADFバインディング・コンテナのオブジェクトを作成します。
スキーマ検証のみでなく、Webページを定期的に実行およびテストして、次の条件が存在していないことを確認すると効果的です。
データ・モデル・プロジェクトとユーザー・インタフェース・プロジェクトの間のプロジェクト依存関係が無効になっている。
デフォルトでは、データ・モデル・プロジェクト内のデータ・コントロールにアクセスするWebページを作成すると、プロジェクト間の依存関係が有効になります。しかし、アプリケーションを実行しようとしたときに依存関係が無効化されて再び有効化されないと、実行時に次の内部サーブレット・エラーが生成されます。
oracle.jbo.NoDefException: JBO-25002: 型nullの定義model.DataControls.dcxが見つかりません。
このエラーを修正するには、ユーザー・インタフェース・プロジェクトを右クリックして「プロジェクト・プロパティ」を選択し、ダイアログで「依存性」を選択します。パネル内に<ModelProjectName>.jprオプションが表示されていることを確認してください。
DataBindings.cpxファイルの場所が変更されたのに、web.xmlファイルが依然としてそのファイルの元のパスを参照している。
デフォルトでは、JDeveloperにより、ユーザー・インタフェース・プロジェクト用のパッケージにDataBindings.cpxファイルが追加されます。（たとえば、アプリケーションのリファクタなどによって）ファイルの場所が変更された場合、実行時に次の内部サーブレット・エラーが生成されます。
oracle.jbo.NoXMLFileException: JBO-26001: コンテナ/oracle/<path>/DataBinding.cpxに対するXMLファイルが見つかりません。
このエラーを修正するには、web.xmlファイルを開き、<context-param>要素CpxFileName内のパスを編集します。
ページ定義ファイルの名前が変更されたのに、DataBindings.cpxファイルが依然として元のページ定義ファイル名を参照している。
JDeveloperではIDE内でのこれらのファイルの名前変更は許可されていませんが、JDeveloperの外部でページ定義ファイルの名前が変更された場合、DataBindings.cpxファイル内の参照が更新されていないと、実行時に次の内部サーブレット・エラーが生成されます。
oracle.jbo.NoDefException: JBO-25002: 型フォーム・バインディング定義の定義oracle.<path>.pageDefs.<pagedefinitionName>が見つかりません。
このエラーを修正するには、DataBindings.cpxファイルを開き、<pageMap>要素と<pageDefinitionUsages>要素内のページ定義ファイル名を編集します。
Webページ・ファイル（.jspまたは.jspx）の名前が変更されたが、DataBindings.cpxファイルが依然として同じWebページの元のファイル名を参照している。
ページ・コントローラでは、ページのURLを使用して、Webページ用のADFバインディング・コンテナの作成に使用する適切なページ定義を決定します。URLからのページの名前がDataBindings.cpxファイルの<pageMap>要素と一致しない場合、実行時に次の内部サーブレット・エラーが生成されます。
javax.faces.el.PropertyNotFoundException: プロパティ<propertyname>のテスト中にエラーが発生しました。
このエラーを修正するには、DataBindings.cpxファイルを開き、<pageMap>要素内のWebページ・ファイル名を編集します。
WebページのEL式でバインディングの名前が変更されたが、ページ定義ファイルが依然として元のバインディング・オブジェクト名を参照している。
Webページに期待どおりの情報が表示されない可能性があります。このエラーを修正するには、ページ定義ファイル内のバインディング名と、表示されていないページ部分に対応するEL式とを比較します。不一致は値バインディングで発生する可能性が最も高く、その結果として、コンポーネントがデータなしで表示されます。イテレータ・バインディング名で不一致が発生した場合、エラーはもっと軽微になり、不一致の原因を特定するためにさらに詳細なデバッグが必要になることがあります。
ページ定義ファイル内のバインディングの名前変更または削除が行われたが、EL式が依然として元のバインディング・オブジェクト名を参照している。
デフォルトのエラー処理メカニズムによりADFバインディング・コンテナからのランタイム・エラーが捕捉されるため、このタイプのエラーは非常に簡単に検出できます。たとえば、ページ定義ファイル内の（findUsersByNameIterという名前の）イテレータ・バインディング名が変更されたが、ページが依然として元の名前を参照している場合、Webページに次のエラーが表示されます。
JBO-25005: 型イテレータ・バインディング定義のオブジェクト名findUsersByNameIterが無効です。
このエラーを修正するには、Webページで名前をクリックして「ページ定義に移動」を選択し、EL式内に使用する適切なバインディング名を見つけます。
式ピッカー・ダイアログを使用せずに手動でEL式を記述し、無効なオブジェクト名またはプロパティ名が入力されている。
このエラーは見つけにくいことがあります。エラーが含まれているEL式によって、サーブレットのエラー・メッセージが表示されることと、表示されないことがあります。たとえば、ランタイム結果を持たないバインディング・プロパティ（ラベル名の表示など）においてエラーが発生した場合、ページは正常に機能しますが、ラベルは表示されません。しかし、メソッドを実行するバインディングにおいてエラーが発生した場合は、内部サーブレット・エラーjavax.faces.el.MethodNotFoundException: <methodname>が表示されます。また、メソッド式にプロパティ名を間違って入力した場合は、サーブレット・エラーjavax.faces.el.PropertyNotFoundException: <propertyname>が表示されます。これらの例外のデバッグに役立つJSFトレース・メッセージの表示の詳細は、16.6項「EL式のトレース」を参照してください。
前述の一般的なエラーのリストを調べても、ランタイム・エラーの特定と解決ができない場合は、原因を特定するためにJDeveloper内部のデバッグを開始できます。このプロセスでは、Oracle ADFページ・ライフサイクルの各フェーズでアプリケーションの実行が一時停止され、そのライフサイクルで受け取られたデータが調査され、それが期待されるデータか否かが判断されます。アプリケーションのデータを検査するには、ソース・コードのブレークポイントとデータ・ウィンドウを使用します（16.4項「一般的なOracle ADFモデルのデバッグ・セッションの概要」を参照）。
Webページまたはその対応するページ定義ファイル内でエラーが簡単に見つからない場合、JDeveloperのデバッグ・ツールを使用して、アプリケーションの障害の発生箇所を調べることができます。具体的に言えば、WebページとOracle ADFモデル・レイヤーの対話をデバッグする目標は、Oracle ADFページ・ライフサイクルの実行にブレークポイントを設定してアプリケーションを一時停止し、実行時にロードされるデータを調べることにあります。Oracle ADFモデル・レイヤーのオブジェクトに期待されるデータが含まれていない場合、これを観測することで、考えられる原因の特定につながります。
一般に、デバッグのプロセスは次のとおりです。
アプリケーションを実行し、欠落しているデータや不完全なデータ、無視されるアクションとメソッド、正しく実行されていないアクションとメソッド、あるいはその他の予期しない結果があるか調べます。
ADFログを有効にしてOracle ADFモデル・メッセージをJDeveloperのログ・ウィンドウに送信するデバッグ構成を作成します。詳細は、16.4.2項「Oracle ADFデバッグ構成の作成」を参照してください。
「ナビゲート」メニューから（または[Ctrl]を押しながら[-]を押して）「Javaクラスに移動」を選択し、ダイアログを使用して、処理が失敗しているエントリ・ポイントを表すOracle ADFクラスを見つけます。
|
ヒント: JDeveloperにより、アプリケーション・ナビゲータ内で現在フォーカスのあるユーザー・インタフェース・プロジェクトからのクラスが特定されます。ワークスペースに複数のユーザー・インタフェース・プロジェクトが含まれている場合は、デバッグの対象となるプロジェクトに現在フォーカスがあることを確認してください。 |
Javaエディタでクラス・ファイルを開き、メソッドの文をトレース実行できるOracle ADFメソッド・コールを見つけます。
目的のメソッドにブレークポイントを設定し、デバッガを実行します。
アプリケーションがブレークポイントで停止したら、データ・ウィンドウを使用して、現在のコンテキストのローカル変数および引数を調べます。
アプリケーションを一時停止するブレークポイントをキー・ポイント上に設定した後は、JDeveloperのデータ・ウィンドウにデータを表示できます。WebページとOracle ADFモデル・レイヤーの対話を効率的にデバッグするには、次のことを理解する必要があります。
Oracle ADFページのライフサイクルと、起動されるメソッド・コール
アプリケーションの処理過程でOracle ADFモデル・レイヤーに含まれる必要のあるローカル変数および引数
Oracle ADFの処理（16.5項「Oracle ADFモデル・レイヤーのデバッグ」を参照）を理解しておくことは、ブレークポイントを選択的に設定し、アプリケーションによりロードされたデータを調べ、エラーの要因を特定するための手がかりとなります。
|
注意: JSF Webページでは、ページのコンポーネントとデータの間の対話を管理するためにバッキングBeanを使用している場合もあります。バッキングBeanをデバッグするには、他のJavaクラス・ファイルの場合と同様に、ブレークポイントを設定します。 |
実際のデバッガを使用する前でも、フレームワークの診断ロギングを有効化してアプリケーションを実行すると、問題の発生時に何が起きたかを確認するのに役立ちます。診断ロギングを有効化するには、Javaシステム・プロパティjbo.debugoutputをconsoleという値に設定します。また、ADFLoggerという値にすると、標準のJ2SE Logger実装を通じて診断をルーティングできます。この実装は、OC4J j2ee-logging.xmlファイルを使用する一般的な方法で制御できます。
JDeveloper内部でのアプリケーションの実行時にこのシステム・プロパティを設定する最も簡単な方法は、プロジェクト・プロパティを編集することです。「実行/デバッグ」パネルで実行構成を選択し、「編集」をクリックしてその実行構成を編集します。次に、文字列-Djbo.debugoutput=consoleを「Javaオプション」フィールドに追加します。
ADF Facesでは、デバッグ・セッションの実行時にロギング機能を提供するために、JavaロギングAPI（java.util.logging.Logger）を使用します。Javaロギングは、Javaプラットフォーム（JDK 1.4以上）で使用可能な標準的なAPIです。主要な要素は、http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/overview.htmlの『Java Logging Overview』を参照してください。
標準的なJavaロギングが使用されるため、j2ee-logging.xmlファイルを編集して、ログ・ウィンドウに表示される診断レベルを制御できます。
JDeveloper内部でデバッグ・セッションを実行する場合は、JDeveloperに組み込まれているOC4Jを使用します。変更の対象となるJDeveloperインストールのファイルは次の場所にあります。
<JDev_Install>/jdev/system/oracle.j2ee.10.1.3.xx.xx/embedded-oc4j/config
同様に、Oracle Application Serverでリモート・デバッグ・セッションを実行する場合、次の場所にあるファイルを変更できます。
<OAS_Home>/j2ee/<OC4J_INSTANCE>/config
また、スタンドアロンOC4J上でリモート・デバッグ・セッションを実行する場合は、次の場所にあるファイルを変更できます。
<OC4J_Home>/j2ee/home/config
j2ee-logging.xmlファイル内のADFパッケージ・レベル・ロギングを編集する手順:
Oracle ADFのロギング・レベルを変更する場合は、構成ファイルの<logger>要素を編集します。
|
注意: デフォルトでは、Oracle ADFのすべてのパッケージのレベルはINFOに設定されています。ただし、詳細なロギング診断を行う場合には、level="FINE"に設定することをお薦めします。 |
パッケージoracle.adf.view.facesおよびoracle.adfinternal.view.facesの場合は、次の要素を編集します。
<logger name="oracle.adf" level="INFO"/><logger name="oracle.adfinternal" level="INFO"/>
Oracle ADFモデル・レイヤー・パッケージの場合は、次の要素を編集します。
<logger name="oracle.adf" level="INFO"/><logger name="oracle.jbo" level="INFO"/>
あるいは、デバッグ・セッションを開始する際に選択できるデバッグ構成をJDeveloper内に作成することもできます。
Oracle ADFモデルのデバッグ構成を作成する手順:
アプリケーション・ナビゲータで、ユーザー・インタフェース・プロジェクトをダブルクリックします。
「プロジェクト・プロパティ」ダイアログで「実行/デバッグ」をクリックし、（たとえば、ADF debuggingという名前の）新しい実行構成を作成します。
新しい実行構成をダブルクリックして、プロパティを編集します。
「実行構成の編集」ダイアログの「起動設定」で、デフォルトのojvm仮想マシンに対して次のJavaオプションを入力します。
-Djbo.debugoutput=adflogger -Djbo.adflogger.level=FINE
詳細な診断メッセージを表示する場合は、level=FINEに設定することをお薦めします。
初めに、異なる種類のブレークポイントとそれらの作成場所について理解する必要があります。
デバッガのブレークポイント・ウィンドウを表示するには、JDeveloperのメイン・メニューで「表示」→「デバッガ」→「ブレークポイント」の順にメニューを選択します。または、オプションで[Ctrl]+[Shift]+[R]というキー・アクセラレータを使用します。
ブレークポイント・ウィンドウ内の任意の場所で右クリックして、メニューから「新規ブレークポイント」メニュー選択項目を選択し、新規のブレークポイントを作成できます。作成するブレークポイントの種類は、「ブレークポイント型」ドロップダウン・リストで制御します。有効な選択項目は、次のとおりです。
例外: 該当クラス（またはサブクラス）の例外がスローされると、ブレークが発生します。
このオプションは、例外の発生する場所はわからないが、例外の種類（java.lang.NullPointerException、java.lang.ArrayIndexOutOfBoundsException、oracle.jbo.JboExceptionなど）はわかっている場合に効果的です。チェック・ボックス・オプションにより、該当クラスの例外が捕捉された場合と捕捉されない場合のどちらでブレークを実行するかを制御できます。「参照」ボタンを使用して、例外の完全修飾クラス名を検索できます。「例外クラス」コンボ・ボックスには、最近使用した例外ブレークポイント・クラスが保存されています。これはブレークポイント・ウィンドウでブレークポイントを作成する場合の、デフォルトのブレークポイント型であることに注意してください。
ソース: 特定のパッケージに含まれるクラスの特定のソース行が実行されると、ブレークが発生します。
新規ブレークポイント・ウィンドウでソース・ブレークポイントを作成することはほとんどありません。その理由は、メニューの「ナビゲート」→クラスに移動（アクセラレータの[Ctrl]+[Shift]+[-]）を使用して、目的の行番号までスクロールし（または「ナビゲート」→「指定行に移動」（アクセラレータの[Ctrl]+[G]）を使用）、ブレークを実行する行の左側のブレークポイント・マージンをクリックする方がはるかに簡単であるためです。この方法は、新規ソース・ブレークポイントを作成することと同じですが、パッケージ、クラスおよび行番号を手動で入力せずに済みます。
メソッド: 特定のクラスの1つのメソッドが起動されると、ブレークが発生します。
これは、問題のデバッグ中にコール・スタックで表示される、特定のメソッドにブレークポイントを設定するのに便利です。ソースがある場合は当然そのクラスのどの場所でもソース・ブレークポイントを設定できますが、この種類のブレークポイントでは、クラスのソースがない場合でもデバッガでブレークできます。
クラス: 特定のクラスのいずれかのメソッドが起動されると、ブレークが発生します。
このオプションは、問題に関連するクラスのみがわかっており、ブレーク対象のメソッドが正確にわからない場合に便利です。また、この種類のブレークポイントでもソースは必要ありません。「参照」ボタンを使用して、ブレークを実行するクラスの完全修飾名を簡単に検索できます。
監視ポイント: 特定のフィールドがアクセスまたは変更されると、ブレークが発生します。
このオプションは、（setterまたはgetterメソッドが毎回使用されるかわりに）クラス内部のコードにより、複数の異なる場所から直接メンバー・フィールドが変更される状況で問題を検出する場合に非常に便利です。フィールドが変更された場合に、即座にデバッガを停止できます。このタイプのブレークポイントを作成するには、クラスのソースのメンバー・フィールドにカーソルを置いて右クリックし、「監視ポイントの設定」メニュー項目を選択します。
ブレークポイントを作成した後、該当するブレークポイントでポップアップ・メニューの「編集」を選択すると、ブレークポイント・ウィンドウでブレークポイントを編集できます。
ブレークポイントの編集時には、次の便利な機能を使用できます。
ブレークポイントをグループ化する論理的なブレークポイント・グループ名を、同じブレークポイント・グループ名を持つ他のブレークポイントに関連付けることができます。ブレークポイント・グループにより、1回の操作でブレークポイントのセット全体を有効化または無効化することが簡単になります。
ブレークポイントに到達した場合に実行するデバッガ・アクションを関連付けることができます。デフォルトのアクションでは、問題を調査できるようデバッガを停止するだけですが、ビープ音の追加、ログ・ファイルへのログの書込み、およびブレークポイント・グループの有効化や無効化も可能です。
条件に一致した場合にのみデバッガを停止するように、ブレークポイントに条件式を関連付けることができます。リリース10.1.3では、これらの式は事実上次のようなブール式になります。
expr ==value
expr.equals("value")
expr instanceoffully.qualified.ClassName
|
注意: デバッガ監視ウィンドウを使用して、最初に式を評価してその式が有効であるか確認します。 |
JDeveloperデバッガには、見落とされがちですが優れた機能として、任意のクラスのデバッガ・ウィンドウに表示されるメンバーをフィルタできる機能があります。デバッガのデータ・ウィンドウで任意の項目にカーソルを置いて右クリックし、ポップアップ・メニューの「オブジェクト設定」を選択すると、デバッガに表示するメンバーと（状況によってはより重要となる）表示しないメンバーをカスタマイズできるダイアログが表示されます。
これらの設定は、クラス・タイプごとに指定します。これにより、デバッガのデータ・ウィンドウでスクロールを要する量が大幅に減少します。この機能は、クラスの一部のメンバーにのみ関心がある場合のデバッグ作業において特に便利です。
問題を特定できず、自分だけでは問題を解決できない場合、通常は次のステップとして誰か別のユーザーに支援を求めることになります。OTNのJDeveloperフォーラムに問題を投稿するか、Metalinkでサービス・リクエストを提出するかにかかわらず、投稿にスタック・トレース情報を含めると、支援者が問題の発生場所を正確に特定する際に非常に役立ちます。
JDeveloperのスタック・ウィンドウでは、この情報を簡単にやり取りできます。デバッガが一時停止したときに、スタック・ウィンドウで、現在行に到達するまでのメソッド・コールのスタックとしてプログラム・フローを参照できます。スタック・ウィンドウの背景部分で右クリックし、「設定」メニューを選択することで、行番号情報や、デフォルトで表示するクラスおよびメソッド名を含めるようスタック・ウィンドウを設定できます。また、別の便利なポップアップ・メニュー・オプションである「エクスポート」を使用すると、現在のスタック情報を外部のテキスト・ファイルに保存できます。このテキスト・ファイルの内容は、問題の診断を支援するユーザーに対して投稿または送信できます。
Oracle ADFモデルと合せたJSFページの処理は、次の2つのクラスにより制御されます。
oracle.adf.controller.faces.lifecycle.FacesPageLifecycleクラス
oracle.adf.controller.v2.lifecycle.PageLifecycleImplクラス
FacesPageLifecycleは、PageLifecycleImplの特定のメソッドを実装して、ADF Facesアプリケーションのカスタマイズしたエラー処理動作を提供します。ただし、一般にはPageLifecycleImplにブレークポイントを設定します。これは、このクラスが、Oracle ADFバインディング・コンテキストのオブジェクトを作成するための開始ポイントを提供するためです。
|
ヒント: FacesPageLifecycleクラスは、ADFライフサイクルのフェーズのデフォルト実装を提供します。ブレークポイントを設定するのに適した箇所は、prepareModel()メソッドです。これは、このメソッドがADFライフサイクルの最初のフェーズを開始するためです。Oracle ADFライフサイクルの詳細は、6.2.3項「実行時に行われる処理: JSFおよびADFのライフサイクル」を参照してください。 |
WebページとOracle ADFバインディング・コンテキストのこれらのオブジェクトとの対話が正常に行われると、ページのコンポーネントが適切で完全なデータとともに表示され、メソッドおよびアクションにより目的の結果が生成され、ページが該当する検証エラーとともに正しくレンダリングされます。
実行時、ADFライフサイクルがモデルを準備してWebページを表示できるようになるまでに、いくつかの処理が行われる必要があります。ADFデータ・バインドされたWebページに対する最初のリクエストが発生すると、サーブレットによりOracle ADFサーブレット・フィルタADFBindingFilter（web.xmlファイル内に指定されているフィルタ）が登録されます。メソッドADFBindingFilter.doFilter()はADF処理状態を設定し、メソッドADFBindingFilter.initializeBindingContext()はweb.xmlファイルからCpxFileName初期パラメータを読み取ることによってoracle.adf.model.BindingContextのインスタンスを作成します。
ADFBindingFilter.initializeBindingContext()がコールされた直後のBindingContextは、Oracle ADFモデル・レイヤー・オブジェクトの階層を定義する空のコンテナ・オブジェクトです。ただし、ページのバインディングを作成するためには、コンテナ・オブジェクトとしてBindingContextが存在している必要があります。存在していない場合、コンテナ/oracle/<path>/DataBinding.cpxの次の内部サーブレット・エラーがスローされます。
oracle.jbo.NoXMLFileException: JBO-26001: XMLファイルが見つかりません
Webアプリケーションのバインディング・コンテキストの作成をデバッグする手順:
oracle.adf.model.servlet.ADFBindingFilterクラス内で、chain.doFilter()にブレークを設定し、このメソッドをトレース実行します。
ctx.get(BindingContext.IS_INITIALIZED)に別のブレークを設定し、このメソッドをトレース実行します。
oracle.jbo.uicli.mom.JUMetaObjectManagerクラス内で、chain.getClientProjectExtension()にブレークを設定し、このメソッドをトレース実行します。
一時停止の処理中、データ・ウィンドウで、予測されるパッケージ名を持つファイルに対するslot0を探します。
DataBindings.cpxファイルが見つからない場合は、サーブレット・コンテキスト・パラメータ要素が.cpxファイルの完全修飾名を正しく定義していることを確認し、修飾名パスにより指定された場所にあるプロジェクト内にそのファイルが存在していることを確認します。例16-2に、SRDemoアプリケーションのコンテキスト・パラメータを示します。
|
ヒント: コンテキスト・パラメータのparam-value要素内に指定された名前は、.cpxファイルの完全修飾名である必要があります。 |
ADFBindingFilterによってBindingContextが作成された後、メソッドPageLifeCycle.xXX()はリクエストのWebページURLをメソッドBindingContext.findBindingContainer()に渡して、DataBindings.cpxファイル内の<pageMap>要素からそのWebページに一致するページ定義を見つけます。これはBindingContainerになります。このBindingContainerオブジェクトはランタイム・インスタンス・オブジェクトであり、すべてのバインディングはこのオブジェクト上に作成されます。ページ定義ファイルが見つからない場合は、次の内部サーブレット・エラーがスローされます。
oracle.jbo.NoDefException: JBO-25002: 型フォーム・バインディング定義の定義oracle.<path>.pageDefs.<pagedefinitionName>が見つかりません。
Webページのバインディング・コンテナの作成をデバッグする手順:
oracle.adf.model.BindingContextクラス内で、findBindingContainerIdByPath()にブレークを設定し、このメソッドをトレース実行します。
データ・ウィンドウ内で、バインディング・コンテナに関連付けられたデータ・バインド済Webページの名前を探します。
スマート・データ・ウィンドウで、予測されるデータ・バインド済Webページ・ファイル名と一致するエントリを探します。
データ・ウィンドウ内に、データ・バインド済Webページに一致するページ定義エントリが表示されます。
<pagename>PageDef.xmlファイルが見つからない場合は、DataBindings.cpxファイル内の<pageMap>要素がプロジェクト内のWebページの正しい名前とパスを指定していることを確認します。例16-3に、SRDemoアプリケーションのDataBindings.cpxサンプル・ファイルを示します。<pageMap>要素によってJSFページがそのページ定義ファイルにマップされていることに注意してください。
|
注意: JSFページまたはページ定義ファイルの名前を変更した場合、.cpxファイルは自動的にリファクタされません。新しいページ名を反映するには、手動で.cpx内のページ・マッピングを更新する必要があります。 |
例16-3 Databinding.cpxページ定義のサンプル
<?xml version="1.0" encoding="UTF-8" ?>
<Application xmlns="http://xmlns.oracle.com/adfm/application"
version="10.1.3.34.12" id="DataBindings" SeparateXMLFiles="false"
Package="oracle.srdemo.view" ClientType="Generic">
<pageMap>
<page path="/app/SRList.jspx" usageId="app_SRListPageDef"/>
...>
</pageMap>
<pageDefinitionUsages>
<page id="SRListPageDef" path="oracle.srdemo.view.pageDefs.
app_SRListPageDef"/>
...
</pageDefinitionUsages>
<dataControlUsages>
<dc id="SRDemoFAQ" path="oracle.srdemo.faq.SRDemoFAQ"/>
<dc id="SRAdminFacade" path="oracle.srdemo.model.SRAdminFacade"/>
<dc id="SRPublicFacade" path="oracle.srdemo.model.SRPublicFacade"/>
</dataControlUsages>
</Application>
BindingContextによりBindingContainerが作成された後、Webページにデータが表示される前に、ADFライフサイクルによりモデル準備フェーズとモデル・レンダリング・フェーズが開始される必要があります。バインディングが解決されて、Webページにデータが表示されるまでに、いくつかの処理が行われる必要があります。
ページ・パラメータを設定する必要があります。
名前付きのサービス・メソッドとADFイテレータ・バインディングを実行することにより、イテレータおよびメソッドの実行可能ファイルをリフレッシュする必要があります。
ADFライフサイクルは、BindingContainer.refresh(PREPARE_MODEL)をコールすることにより、モデル準備フェーズを開始します。モデル準備フェーズでは、BindingContainerページ・パラメータが準備されてから評価されます。次に、BindingContainer実行可能ファイルが、pagedef.xmlファイルの<executables>セクション内のエントリの順序と、それらのRefreshおよびRefreshConditionプロパティ（存在する場合）の評価に基づいてリフレッシュされます。実行可能ファイルがイテレータ・バインディング・リフレッシュに到達すると、対応するデータ・コントロールが実行され、それによってサービス・オブジェクト内の1つ以上のコレクションが実行されます。イテレータ・バインディングがリフレッシュに失敗すると、JBO例外がスローされ、データを表示できなくなります。
バインディング・コンテナのすべての実行可能ファイルをデバッグする手順:
oracle.adf.model.binding.DCBindingContainerクラス内で、実行可能ファイルをデバッグするエントリ・ポイントとしてinternalRefreshControl(int, boolean)にブレークを設定します。
ヒント: DCBindingContainer.internalRefreshControl()メソッド内では、条件if (/*execute ||*/ execDef == null || execDef.isRefreshable(this, iterObj, refreshFlag))の結果を確認することにより実行可能ファイルをリフレッシュするかどうかを指定できます。条件がTrueに評価された場合は、実行可能ファイルがリフレッシュされ、処理はinitSourceRSI()に進みます。
oracle.adf.model.binding.DCIteratorBindingクラス内で、callInitSourceRSI()にブレークを設定して処理を停止し、メソッドをトレース実行します。
一時停止の処理中、スタック・ウィンドウ内でcallInitSourceRSI()を探します。スマート・データ・ウィンドウには、予測された結果が表示されるはずです。
Webページにメソッド・イテレータ・バインディングからのデータが表示されない場合は、JUMethodIteratorDef.java内のエントリ・ポイントおよびそのネストされたクラスJUMethodIteratorBindingにドリルダウンしてその実行をデバッグできます。
バインディング・コンテナのメソッド・イテレータ実行可能ファイルをデバッグする手順:
oracle.jbo.uicli.binding.JUMethodIteratorDefクラス内で、メソッド・イテレータ・バインディング実行可能ファイルをデバッグするためのエントリ・ポイントとしてinitSourceRSI()にブレークを設定します。
invokeMethodAction()にブレークを設定して処理を停止し、メソッドをトレース実行します。
initSourceRSI()により行セット・イテレータが返されたら、処理を一時停止し、スマート・データ・ウィンドウ内でmProviderを探します。mProvider変数は、この行セット・イテレータに対してフェッチされたデータソースです。メソッドが正常に返された場合、イテレータまたはBeanにバインドされたコレクションが表示されているはずです。
Webページにアクセッサ・バインディングからの詳細データが表示されない場合は、JUAccessorIteratorDef.java内のエントリ・ポイントにドリルダウンしてその実行をデバッグできます。
バインディング・コンテナのアクセッサ・バインディング実行可能ファイルのみをデバッグする手順:
oracle.jbo.uicli.binding.JUAccessorIteratorDefクラス内で、アクセッサ実行可能ファイルをデバッグするためのエントリ・ポイントとしてinitSourceRSI()にブレークを設定します。
oracle.adf.model.generic.DCGenericDataControlクラス内で、fetchProperty(RowImpl row, String propName)にブレークを設定して、データ・ウィンドウ内を調べる前に処理を停止します。メソッドが、コレクション、イテレータまたはBeanであるプロパティを返しているかどうかを確認します。
initSourceRSI()により行セット・イテレータが返されたら、処理を一時停止し、スマート・データ・ウィンドウ内でcallInitSourceRSI()を探します。その結果、予測されたコレクションが表示されているはずです。
|
ヒント: デバッガが、バインディング・コンテナ内の実行可能ファイルに設定したブレークポイントに到達しない場合、エラーの原因として最も可能性が高いのは、実行可能ファイルのRefreshおよびRefreshCondition属性の定義内容です。属性定義を調べてください。属性値RefreshおよびRefreshConditionの詳細は、A.7.1項「PageDef.xmlの構文」を参照してください。 |
例外を生成した実行可能ファイルが特定されたら、pagedef.xmlファイル内の<executables>要素が適切な属性設定を指定していることを確認します。
モデル準備フェーズ中に実行可能ファイルがリフレッシュされるかどうかは、RefreshおよびRefreshConditionの値（存在する場合）によって決まります。RefreshがprepareModelに設定されているか、値が指定されていない（つまり、デフォルトのifneededが使用される）場合は、RefreshCondition属性値が評価されます。RefreshCondition値が存在しない場合は、実行可能セクションが起動します。RefreshConditionの値が存在する場合は、値が評価され、評価の戻り値がtrueの場合は、実行可能セクションが起動します。値がfalseと評価された場合は、実行可能セクションは起動しません。デフォルト値は常に、実行を強制します。
例16-4に、SRDemoアプリケーションのpagedef.xmlファイルのサンプルを示します。<executables>要素内に、実行可能ファイルが実行順に一覧表示され、そのマスター・バインディング・イテレータの後にアクセッサ・イテレータが指定されていることに注意してください。
例16-4 ページ定義のマスター/ディテール実行可能ファイルのサンプル
<executables>
<methodIterator id="findAllServiceRequestIter"
Binds="findAllServiceRequest.result"
DataControl="SRPublicFacade" RangeSize="10"
BeanClass="oracle.srdemo.model.ServiceRequest"/>
<accessorIterator id="serviceHistoryCollectionIterator" RangeSize="10"
Binds="serviceHistoryCollection"
DataControl="SRPublicFacade"
BeanClass="oracle.srdemo.model.ServiceHistory"
MasterBinding="findAllServiceRequestIter"/>
</executables>
ADFライフサイクルのprepareRenderフェーズでは、バインディングによって表示されるデータが決まり、バインディングのプロパティによってデータが表示される条件が決まります。初めてWebページがレンダリングされるとき、バインディングを指し示す各EL式が、そのページのBindingContainerインスタンスにより解決されます。式の適切な値（format、isEnabled、isViewableなど）に基づいて、バインディングのデータ値がBindingContainerから返されます。バインディングがデータを返すことができない場合、JBO例外がスローされます。
バインディング・コンテナのバインディング解決をデバッグする手順:
oracle.jbo.uicli.binding.JUCtrlValueBindingクラス内で、getInputValue()にブレークを設定し、メソッドをトレース実行します。
getInputValue()によりエラーが返された場合、処理を一時停止し、データ・ウィンドウ内でバインディング名を探します。
引き続きgetInputValue()をトレース実行し、データ・ウィンドウ内で、このバインディングが表す現在の行に対して予測される戻り値を探します。
例外を生成したバインディングが特定されたら、pagedef.xmlファイル内の<bindings>要素が適切な属性設定を指定していることを確認します。例16-5に、SRDemoアプリケーションのpagedef.xmlファイルのサンプルを示します。
例16-5 ページ定義の値バインディングのサンプル
<bindings>
...
<attributeValues id="name" IterBinding="variables">
<AttrNames>
<Item Value="findUsersByName_name"/>
</AttrNames>
</attributeValues>
<attributeValues id="email" IterBinding="findUsersByNameIter">
<AttrNames>
<Item Value="email"/>
</AttrNames>
</attributeValues>
<attributeValues id="lastName" IterBinding="findUsersByNameIter">
<AttrNames>
<Item Value="lastName"/>
</AttrNames>
</attributeValues>
<table id="UserexpertiseAreas" IterBinding="expertiseAreasIterator">
<AttrNames>
<Item Value="expertiseLevel"/>
<Item Value="product"/>
</AttrNames>
</table>
</bindings>
送信の場合も、ライフサイクルでは最初にBindingContainerインスタンスが検索および準備されます。ライフサイクルで、このBindingContainerに対して持続されていた状態トークンが見つかると、この状態トークンを処理するようにBindingContainerに対して要求されます。状態トークンを処理すると、以前のレンダリングのときに保存された変数値がリストアされます。状態トークンの処理をデバッグする必要がある場合、DCIteratorBinding.processFormToken()およびDCIteratorBinding.buildFormToken()にブレークインします。
これ以降、すべてのポストは値バインディングのsetInputValue()を介してバインディングに適用されます。
実行可能ファイルがリフレッシュされると、ページ上のアクションおよびカスタム・メソッドが起動されることがあります。この段階で、対応するアクションまたはメソッドのバインディングがリフレッシュされます。実行可能ファイルもそのターゲット・バインディングも実行されない場合、アクションは無視されます。
アクションおよびメソッドの実行のエントリ・ポイントは、DCDataControl.invokeOperation()メソッドです。この他に、JUCtrlActionBinding.invoke()もエントリ・ポイントとして考えられますが、これは、メソッド・イテレータ・バインディングが暗黙的にメソッドを起動する場合にも使用されます。DCDataControl.invokeOperation()でデバッグを実行すれば、データ・コントロールがメソッドの起動に使用する同じメソッドを使用できます。一部のアダプタ・データ・コントロールでは、ADFにメソッドのコールを任せなくても独自の方法でメソッド名を解析できるため、この方法が推奨されます。
バインディング・コンテナのアクションまたはメソッド起動をデバッグする手順:
oracle.adf.model.binding.DCDataControlクラス内で、アクションまたはメソッド起動をデバッグするエントリ・ポイントとしてinvokeOperation()にブレークを設定します。
一時停止の処理中に、このメソッドをステップ実行して、データ・ウィンドウ内の「instanceName」で、起動されているメソッドが目的のオブジェクトの予測どおりのメソッドであることを確認します。
データ・ウィンドウ内の「args」で、メソッドに渡される各パラメータのパラメータ値が予測どおりの値であることを確認します。下図のパラメータ値では、nullが示されています。
バインディング・コンテナのカスタム・メソッド起動をデバッグする手順:
クラス内で、目的のカスタム・メソッドにブレークポイントを設定します。
oracle.adf.model.generic.DCGenericDataControlクラス内で、invokeMethod()にブレークを設定して、データ・ウィンドウ内を調べる前に処理を停止します。
一時停止の処理中に、このメソッドをステップ実行して、データ・ウィンドウ内の「instanceName」で、起動されているメソッドが目的のオブジェクトの予測どおりのメソッドであることを確認します。
データ・ウィンドウ内の「args」で、メソッドに渡される各パラメータのパラメータ値が予測どおりの値であることを確認します。下図のパラメータ値では、nullが示されています。
無視されているアクションまたはカスタム・メソッドが特定されたら、<executables>要素内の<invokeAction>定義と、pagedef.xmlファイルの<bindings>要素内の対応する<action>および<methodAction>定義が適切な属性設定を指定していることを確認します。
|
ヒント: デバッガが、バインディング・コンテナ内のアクションに設定したブレークポイントに到達しない場合、エラーの原因として最も可能性が高いのは、実行可能ファイルのRefreshおよびRefreshCondition属性の定義内容です。属性定義を調べてください。属性値RefreshおよびRefreshConditionの詳細は、A.7.1項「PageDef.xmlの構文」を参照してください。 |
モデル準備フェーズ中に<invokeAction>実行可能ファイルがリフレッシュされるかどうかは、RefreshおよびRefreshConditionの値（存在する場合）によって決まります。RefreshがprepareModelに設定されているか、値が指定されていない（つまり、デフォルトのifneededが使用される）場合は、RefreshCondition属性値が評価されます。RefreshCondition値が存在しない場合は、実行可能セクションが起動します。RefreshConditionの値が存在する場合は、値が評価され、評価の戻り値がtrueの場合は、実行可能セクションが起動します。値がfalseと評価された場合は、実行可能セクションは起動しません。デフォルト値は常に、実行を強制します。
例16-6に、SRDemoアプリケーションのpagedef.xmlファイル内のアクションおよびカスタム・メソッド・バインディング定義のサンプルを示します。
例16-6 ページ定義の実行可能ファイルおよびアクション・バインディングのサンプル
<executables>
...
<invokeAction Binds="findServiceRequests" id="tableRefresh"
Refresh="ifNeeded"
RefreshCondition="${(userState.refresh) and
(!adfFacesContext.postback)}"/>
...
</executables>
<bindings>
<methodAction id="findServiceRequests"
InstanceName="SRPublicFacade.dataProvider"
DataControl="SRPublicFacade"
MethodName="findServiceRequests" RequiresUpdateModel="true"
Action="999"
ReturnName="SRPublicFacade.methodResults.SRPublicFacade_
dataProvider_findServiceRequests_result">
<NamedData NDName="userIdParam" NDValue="#{userInfo.userId}"
NDType="java.lang.Integer"/>
<NamedData NDName="statusParam" NDValue="#{userState.listMode}"
NDType="java.lang.String"/>
</methodAction>
...
</bindings>
BindingContainerのメソッドvalidate()がコールされると、このBindingContainer内で参照されている各バインディングのvalidateInputValue()がコールされます。入力フィールドに設定されている検証が予測どおりの動作をしない場合、Webページに検証エラー・メッセージは表示されません。
バインディング・コンテナの検証チェック・エラーをデバッグする手順:
oracle.jbo.uicli.binding.JUCtrlValueBindingクラス内で、validateInputValue(Object value)にブレークを設定して、データ・ウィンドウ内を調べる前に処理を停止します。
一時停止の処理中に、データ・ウィンドウ内でslot1を探し、検証が実行されていることを確認します。次の図のnotは、検証が実行されなかったことを示しています。
エラーが発生した検証が特定されたら、値バインディングの検証ルールが適切に定義されていることを確認し、入力フィールド・コンポーネントの<af:validator>タグが、値バインディングにより定義されている属性と同じ属性にバインドされていることを確認します。例16-7に、SRDemoアプリケーションのpagedef.xmlファイル内の検証ルールのサンプルを示します。
ADFモデル検証ルールは属性バインディング上に指定する必要がありますので注意してください。検証ルールの使用方法の詳細は、12.3項「検証の追加」を参照してください。
|
ヒント: ADFモデル・レイヤー検証を処理するには、Facesのvalidatorタグを、関連付けられた属性のvalidatorプロパティにバインドする必要があります。たとえば、次のように入力します。
<af:validator binding="#{bindings.
例16-7に示したサンプル検証ルールを使用する場合、 |
例16-7 ページ定義ファイル内の検証ルールへの参照
<attributeValues id="description" IterBinding="variables" ApplyValidation="true"> <LengthValidationBean xmlns="http://xmlns.oracle.com/adfm/validation" OnAttribute="createProducts_description" DataType="CHARACTER" CompareType="LESSTHAN" ResId="description_Rule_0" Inverse="false" CompareLength="20"/> <AttrNames> <Item Value="createProducts_description"/> </AttrNames> </attributeValues>
ELは、特定の障害を通知することを除いて、十分にはサポートされていません。しかし、例16-8に、リゾルバにより完全に式を評価できないときに表示される可能性のある一般的な例外を1つ示します。
例16-8 式評価のPropertyNotFound例外
javax.faces.el.PropertyNotFoundException: Error setting property 'resultsTable' in bean of type null at com.sun.faces.el.PropertyResolverImpl.setValue (PropertyResolverImpl.java:153)
プロパティ名の入力ミスなど、式の中の問題を探すには、Webページのソース・コードを調べることができます。明らかなエラーが見つからない場合は、<JDeveloper_Install>/jre/libディレクトリ内のlogging.propertiesファイルを、ELリゾルバからのメッセージが表示されるように構成します。
EL式の変数をトレースする手順:
テキスト・エディタで<JDeveloper_Install>/jre/lib/logging.propertiesを開きます。
java.util.logging.ConsoleHandler.level=FINEを設定します。
次の行を追加します。
com.sun.faces.level=FINE
アプリケーションを実行し、JDeveloperのログ・ウィンドウ内に変数解決を表示します。
たとえば、SRDemoアプリケーションでは、backing_SRSearch.javaというバッキングBeanを定義しています。例16-9に示すSRSearch.jspxページでは、ADF表バインディングresultsTableに基づいて、データ・バインドされた表コンポーネントを作成しています。
例16-9 表バインディング内のバッキングBeanへの参照
<af:table rows="#{bindings.findAllServiceRequests1.rangeSize}"
...
binding="#{backing_SRSearch.resultsTable}"
id="resultsTable"
width="100%"
rendered="#{(bindings.hideResultsParam!='true') and
(bindings.findAllServiceRequests1.estimatedRowCount >0)}">
例16-10に、ELトレース・メッセージを有効にしてアプリケーションを実行した場合にJDeveloperのログ・ウィンドウに表示されるメッセージを示します。この場合、リゾルバがバッキングBeanから値バインディングresultsTableを解決できず、ブラウザにPropertyNotFound例外が表示されます。
例16-10 ELトレースを有効化した場合のJDeveloperのログ
02-Dec-2005 09:41:28 com.sun.faces.el.ValueBindingImpl getValue FINE: getValue(ref=backing_SRSearch.resultsTable) 02-Dec-2005 09:41:28 com.sun.faces.application.ApplicationAssociate createAndMaybeStoreManagedBeans FINE: Couldn't find a factory for backing_SRSearch 02-Dec-2005 09:41:28 com.sun.faces.el.VariableResolverImpl resolveVariable FINE: resolveVariable: Resolved variable:null 02-Dec-2005 09:41:28 com.sun.faces.el.ValueBindingImpl getValue FINE: getValue Result:null 02-Dec-2005 09:41:28 com.sun.faces.application.ApplicationAssociate createAndMaybeStoreManagedBeans FINE: Couldn't find a factory for backing_SRSearch 02-Dec-2005 09:41:28 com.sun.faces.el.VariableResolverImpl resolveVariable FINE: resolveVariable: Resolved variable:null 02-Dec-2005 09:41:28 com.sun.faces.el.ValueBindingImpl setValue FINE: setValue Evaluation threw exception: javax.faces.el.PropertyNotFoundException
メッセージ「FINE: Couldn't find a factory for backing_SRSearch」は、バッキングBeanが作成されなかったことを示しています。このエラーを修正するには、faces-config.xmlファイルを調べ、バッキングBeanがリストされているか確認します。例16-11に、ファイルの正しいリストを示します。
例16-11 faces-config.xmlのマネージドBeanの記述
<!-- Page backing beans -->
<managed-bean>
<managed-bean-name>backing_SRSearch</managed-bean-name>
<managed-bean-class>oracle.srdemo.view.backing.SRSearch</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<!--oracle-jdev-comment:managed-bean-jsp-link:1SRSearch.jspx-->
</managed-bean>
要約すると、PropertyNotFound例外が発生した場合、そのプロパティがEL式内に存在するプロパティであれば、Webページの構文に単純なエラーがないか調べます。次に、JSFトレース・メッセージを有効化してアプリケーションを再実行し、変数解決メッセージを調べて解決の糸口を探します。
