1

現在、アプリケーションを本番環境から新しいデータセンターに移行中です。

  • 現在の本番環境: Java 1.4、Java EE 3、WAS 5.1、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(リクエスト、レスポンス);
そして、ここで問題が発生します。

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

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

なぜこれが起こっているのか考えてみてください。

- アシッシュ

4

1 に答える 1

1

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

そのため、WEB-INF/lib の JAR は EAR レベルのクラス ローダーからは見えませんでした。これらの JAR を上に移動すると、問題が解決します。これらのすべての JAR が、EAR 内のすべての WAR からも見えるようになります。

確認したいことの 1 つは、web.xml およびその他のファイルの仕様です。サーブレットと JSP の仕様が途中で変更されたため、JSTL などの JAR はバージョン 1.0 から 1.1 になりました。web.xml とすべての JAR を注意深くチェックして、Java EE アプリ サーバーでサポートされている仕様と一致していることを確認してください。

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

于 2009-04-29T22:25:53.950 に答える