- 配備時のJSPプリコンパイルを行わない
JSP初回アクセス時のコンパイルではこの問題は発生しないため、
配備時のJSPプリコンパイルを行わないことで、この問題を回避できます。
JSP初回アクセス時のコンパイルにかかる時間が問題にならないのであれば、
こちらの回避方法を推奨します。
コマンドから配備する場合は、
deployコマンドに--precompilejspオプションを指定しなければ、
配備時にJSPプリコンパイルは行われません。
(--precompilejspオプションの既定値はfalseです)
運用管理ツールから配備する場合は、
「JSPコンパイル」にチェックを入れなければ、
配備時にJSPプリコンパイルは行われません。
(「JSPコンパイル」は既定でチェックが外れています)
- Webアプリケーション(WAR)に同じJARファイルを含める
Webアプリケーション(WAR)のWEB-INF/libにあるJARファイルは、
配備時のJSPプリコンパイルのクラスパスに含まれます。
そのため、EARのlibにあるJARファイルを
Webアプリケーション(WAR)のWEB-INF/libにも含めることで、
この問題を回避できます。
なお、アプリケーション実行時には、WEB-INF/libに置かれたJARファイルよりも、
EARのlibに置かれたJARファイルが優先されるため、
アプリケーション実行時の動作に影響はありません。
ただし、Webアプリケーションのクラスロード処理の優先順位の設定(※)で、
Webアプリケーションのクラスローダを優先するよう設定している場合は、
アプリケーション実行時にもWEB-INF/libのJARファイルが優先して参照されるため、
アプリケーション実行時の動作に影響があります。
アプリケーションの作りによっては、EARのlibとWEB-INF/libの2箇所から
同じ名前のクラスがロードされる場合があります。
これらはロードするクラスローダが異なるため、
同じ名前でも異なるクラスとみなされClassCastException等の原因になります。
この場合は、1つ目の回避方法をご検討ください。
(※)
クラスロード処理の優先順位の制御は、
WEB-INF/nec-web.xmlの要素<class-loader>の属性delegateで指定します。
delegate="true"の場合は、親クラスローダが優先されます。
delegate="false"の場合は、Webアプリケーションのクラスローダが優先されます。
要素<class-loader>を省略した場合や、
WEB-INF/nec-web.xmlそのものを省略した場合の属性delegateのデフォルト値は、
Servletのバージョンによって異なります。
Servlet 2.4以降では属性delegateのデフォルト値は"true"であり、
Servlet 2.3以前は"false"です。