JBoss 4.2 で jsps の再コンパイルを強制するにはどうすればよいですか?
https://stackoverflow.com/questions/952309
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
QA で JBoss 4.2 のこの厄介な動作に気付きました。本番環境に入る前に、この問題の芽を摘み取り、他の例外的なケースを見つけたいと考えています。
JSP は、次のシグネチャを持つメソッドを呼び出します。
public void methodName(String arg)
これは次のように変更されました。
public void methodName(String arg, Object... args)
既存の JSP は、次の方法でこのメソッドを呼び出しました。
methodName("param");
変更されたコードのデプロイメント時に、JBoss は JSP を再コンパイルしなかったため、QA でクラッシュが発生しました。JSP に愚かなコメントを追加すると、問題が修正されました (JBoss は JSP が変更されたことを認識し、それを再コンパイルしました)。
再起動時に JSP の再コンパイルを強制する JBoss の設定はありますか?
編集：答えのいくつかの点を明確にするために、JSP は耳の一部である戦争の一部であるという設定です。耳にはすべてのクラスが瓶の中にあります。
プリコンパイルしたいという要望に関して、システムが JSP にコンパイルが必要ないと考えている場合、プリコンパイルは再コンパイルを強制しますか?そうではないようです。ここでのエラーはコンパイル エラーではなく、メソッド シグネチャ (実際にはコード レベルではなくバイト コード レベルで) が「変更された」ためのメソッド呼び出しエラーです。
補遺:最近実稼働環境で、受け入れられた回答のフラグが設定されていても、実際には JSP が変更されたにもかかわらず、JSP が再コンパイルされないことを経験したことに注意してください。重大なバグがありましたが、それにもかかわらず、JBoss は正常にシャットダウンされました。現時点では JBoss の古いバージョンになりつつありますが、まだ使用している場合は、work ディレクトリと tmp ディレクトリの内容を削除することが確実な唯一の方法です。
質問が求めていたことの核心を突いているという理由だけで、受け入れられた回答を変更するつもりはありません。JBoss のバグは別の問題です。
解決
JSP が、jar としてデプロイされている EAR の一部である WAR の一部である場合、JSP が再コンパイルされない理由がわかりません。war ファイル内の JSP には、前回のデプロイ時に JBoss でコンパイルされたクラス ファイルよりも新しいタイムスタンプが付いていませんか?そうでない場合は、デプロイする前に WAR/EAR の構築の一環として JSP に触れることはできないでしょうか。[各 JSP ファイルを手動でタッチするのではなく、Unix の「タッチ」コマンドを使用することを指します。]
あるいは、$JBOSS/server/default/deploy/jboss-web.deployer/META-INF/jboss-service.xml の DeleteWorkDirOnContextDestroy 設定が探しているものになる可能性があります。デフォルトでは false ですが、true に設定することが必要な場合があります。これにより、再デプロイ時に JSP のクラス ファイルが削除され、各 JSP の最初のアクセス時に再作成されるようになると思います。
見る https://jira.jboss.org/jira/browse/JBAS-3358 詳細については。
他のヒント
設定はわかりませんが、JBoss インスタンスの作業ディレクトリにある生成された Java クラス ファイルを削除すると、次回呼び出されたときに JSP が再コンパイルされます。
JBoss 起動スクリプトを変更して、コンパイルされた JSP が保存されている「tmp」ディレクトリまたは「work」ディレクトリ、あるいはその両方を明示的に削除できます。その場合、JBoss にはすべてを再コンパイルする以外に選択肢はありません。
微妙ではありませんが、機能します。
1 つのオプションは、ビルド時にすべての JSP をプリコンパイルすることです。これにより、コンパイル エラーにすぐにフラグが立てられます。
これを実稼働環境で行うこともでき、最初のアクセスを高速化できますが、他の何よりも QA ステップとしてこれを望んでいるように感じます。その場合は、選択したビルド ツールのテスト フェーズにプリコンパイル ステップを追加し、CI 環境にも追加できます。これにより、コンパイルできない JSP がテストから外されないことが保証されます。
プリコンパイル タスクの実行の詳細については、これを参照してください。
お役に立てれば。
一部の JSP コンテナ (JSP 1.2 仕様のセクション 8.4.2 による) は、JSP ページをプリコンパイルする機能をサポートしています。
JSP ページをプリコンパイルするには、クエリ文字列 ?jsp_precompile を使用してページにアクセスします。
http://hostname.com/mywebapp/mypage.jsp?jsp_precompile
JSP ページは実行されません。コンテナーがプリコンパイルをサポートしている場合、JSP ページは必要に応じてコンパイルされます。
パブロジムは正しい道を進んでいる。何が起こっているのかを完全に把握するには、さらに情報が必要です。私はこう理解しています。
prod で、他の JSP の再コンパイルが必要な JSP を変更しました。再コンパイルするには、次の 2 つのうちのいずれかが起こる必要があります。
- コンパイルされたバージョンの JSP を削除する必要があります。
- JSP 自体を変更する必要があります (または「変更」された場合でも、変更日は更新されます)
すべての jsps が機能することを確認する必要がある場合は、すべてを次のようにする必要があります。 Ant タスクを使用してプリコンパイルされる. 。これにより、war ファイル内のプリコンパイルされた jsps を使用して war ファイルをデプロイすることもできます。これで問題は解決するはずです。
ファイルが war ファイルではなく、展開された形式でデプロイされている場合は、次のようにする必要があります。 Web アプリのパッケージ化を真剣に検討してください デプロイメント用の war ファイル内。これにより、環境間でデプロイするのに適したパッケージになります。
