アプリケーション実行時にApcoordinatorの例外が発生しましたが、原因がわかりません。
Apcoordinatorが発生させる例外のメッセージには、「UJIxxx」の形式のエラーコードが付けられています。 例外の原因を特定するには、“メッセージ集”を参照してエラーの内容を確認してください。
別の例外が原因となってApcoordinatorが例外を発生させる場合もあります。 この場合には、以下の方法によって、原因となった元の例外を調べる ことができます。
ログの確認
以下のログに記録されている例外の情報を確認してください。
アプリケーションがApcoordinatorのログ機能を使ってログの出力先を設定している場合は、そのログ。
アプリケーションサーバー(サーブレットコンテナ、EJBコンテナなど)のログ。
例外の発生箇所によっては、Apcoordinatorがcatchした例外が上記のログに出力されます。 また、 アプリケーションサーバーが例外をcatchしている場合は、アプリケーションサーバーのログに出力されている場合があります。
WebアプリケーションでEJB呼び出し関連の例外が発生している場合は、 EJBで発生した例外が原因の場合があります。 EJBが出力しているログや、EJBコンテナのログも確認してください。
ラップされている例外の取得
Apcoordinatorが発生する例外のうち、com.fujitsu.uji.log.NestedException インターフェイスを実装したものは元の例外をラップしており、NestedExceptionのgetRootCauseメソッドで元の例外を取得できます。
アプリケーション開発時には、以下のように一時的に処理を追加することで、 元の例外を再帰的に取り出して標準エラー出力に出力できます。
例外が発生しているメソッドが特定できている場合は、メソッド内の処理をtry, catchで囲って以下のようにプログラムします。
try {
...
} catch (Throwable t) {
for( ; ; ) {
t.printStackTrace();
if(!(t instanceof com.fujitsu.uji.log.NestedException)) {
break;
}
System.err.println("root cause:");
t = ((com.fujitsu.uji.log.NestedException)t).getRootCause();
}
}例外が発生しているメソッドが特定できない場合は、 ビジネスクラス、セションクラス、アプリケーションクラスのいずれかに handleExceptionメソッドを追加して元の例外のスタックトレースを出力する処理を実行します。 例外が発生しているビジネスクラスが特定できている場合、そのビジネスクラスのhandleExceptionを、特定できていない場合は、セションクラスかアプリケーションクラスの handleExceptionを使用します。
handleExceptionを追加するクラスがcom.fujitsu.uji.Postprocessorインターフェイスを実装していない場合は、そのクラスで実装するインターフェイスにPostprocessorを追加します。ビジネスクラスにhandleExceptionを追加する場合で、そのビジネスクラスがcom.fujitsu.uji.GenericHandlerを継承している場合は、すでにPostprocessorが実装済みですのでPostprocessorの追加は不要です。
以下のようにhandleExceptionメソッドを追加します。
public Object handleException(DispatchContext context, Throwable th) throws Throwable {
Throwable t = th;
for( ; ; ) {
t.printStackTrace();
if(!(t instanceof com.fujitsu.uji.log.NestedException)) {
break;
}
System.err.println("root cause:");
t = ((com.fujitsu.uji.log.NestedException)t).getRootCause();
}
throw th;
}標準エラーはアプリケーションサーバーのワークユニットのログに出力されます。