2009-04-29 16 views
1

現在、私たちの運用環境から新しいデータセンターにアプリケーションを移行中です。 JavaEE 5、WAS 6.0 JSPの奇妙な問題が含まれています

  • 現在のプロダクション環境:Javaの1.4はJava EE 3、5.1 WAS、JSF 2.1
  • 新データセンター環境:Javaの1.5はJava EE 5は、WAS 6.1、JSF 2.1
当社のアプリケーションはJSF 2.1上に構築されていますAJAX呼び出しの1つに以下のコードが含まれています。
request.getSession().getServletContext().getRequestDispatcher(
        "/results.faces").include(request, response);
ここでは、問題が発生しています。

ケース1:標準仕様のEAR構造
。 EAR - > WAR - > WEB-INF - > lib - > * .jar(すべてのアプリケーション固有のjarはWEB-INF/libの下にあります)。これはうまくいかず、クラスローダーが見つけられないクラスの例外を取得することに力を入れています。また、上記のAJAX呼び出しは失敗します(出力は生成されません)。

ケース2:EARにはルート上のすべてのアプリケーションJARファイルが含まれます(MANIFEST.MFには手動でクラスパスが指定されています)。
この手法は完全に機能し、すべてのJARファイルは問題なくロードされます。さらに、AJAX呼び出しもうまくいきます。

これがなぜ起こっているのでしょうか。

- アシシュ

答えて

1

のJava EEアプリケーションサーバはこのようなものになり、クラスローダの階層持っているので、はい、それはです:最初のブートストラップクラスローダが呼び出されます。次に、EARレベルのクラスローダー、次にWARレベルのクラスローダーがあります。高級クラスのローダーは、必要なクラスについては下には表示されません。それらが必要なものを見つけられない場合、ClassNotFoundExceptionがスローされます。

したがって、WEB-INF/lib内のJARは、EARレベルのクラスローダには表示されませんでした。それらのJARファイルを移動すると、問題が解決されます。これにより、EAR内のすべてのWARにすべてのJARが表示されます。

確認したいことは、web.xmlやその他のファイルの仕様です。サーブレットとJSPの仕様は途中で変更されたので、JSTLなどのJARはバージョン1.0から1.1に移行しました。 web.xmlとすべてのJARを慎重にチェックして、Java EEアプリケーションサーバーでサポートされている仕様と一致しているかどうかを確認したい場合があります。

残念ながら、アプリサーバーのアップグレードは、EARまたはWARを起動するほど簡単ではありません。