7

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 が耳の一部である戦争の一部であるということです。ear には、すべてのクラスが jar に含まれています。

プリコンパイルしたいという要望に関して、システムが jsp をコンパイルする必要がないと判断した場合、プリコンパイルは再コンパイルを強制しますか? そうではないようです。ここでのエラーはコンパイル エラーではなく、(実際にはコード レベルではなくバイト コード レベルで) 「変更された」メソッド シグネチャによるメソッド呼び出しエラーです。

補遺: 最近の本番環境では、受け入れられた回答のフラグが設定されていても、JSP が実際に変更されたにもかかわらず、JSP が再コンパイルされなかったことに注意してください。重大なバグがありましたが、JBoss は正常にシャットダウンされました。この時点で JBoss の古いバージョンになりつつありますが、まだ使用している場合は、作業ディレクトリと tmp ディレクトリの内容を削除することが確実な唯一の方法です。

質問が探していたものに実際に到達したという理由だけで、受け入れられた回答を変更していません。JBoss のバグは別の問題です。

4

6 に答える 6

11

If the JSPs are part of a WAR that is part of an EAR that is being deployed as a jar, then I'm not clear why your JSPs are not being recompiled. Don't the JSPs in the war file have newer timestamps than their JBoss-compiled class files from the last deploy? If not, couldn't you touch the JSPs as part of building the WAR/EAR before deploying. [I'm referring to using the Unix "touch" command, not manually touching each JSP file.]

Alternatively, the DeleteWorkDirOnContextDestroy setting in $JBOSS/server/default/deploy/jboss-web.deployer/META-INF/jboss-service.xml may be what you are looking for. It is false by default, but setting it to true may be what you need. I think this should delete the JSPs' class files on redeploy so that they get recreated upon first access of each JSP.

See https://jira.jboss.org/jira/browse/JBAS-3358 for more info.

于 2009-06-12T01:27:59.773 に答える
1

設定はわかりませんが、生成された Java クラス ファイルを JBoss インスタンスの作業ディレクトリに削除すると、次に呼び出されたときに JSP が再コンパイルされます。

于 2009-06-04T21:18:19.143 に答える
1

JBoss 起動スクリプトを変更して、コンパイル済みの JSP が格納されている「tmp」および/または「work」ディレクトリを明示的に削除することができます。その場合、JBoss はそれらをすべて再コンパイルするしかありません。

微妙ではありませんが、それは仕事をするでしょう.

于 2009-06-07T15:07:54.490 に答える
0

1つのオプションは、ビルド時にすべてのjspをプリコンパイルすることです。これにより、コンパイルエラーにすぐにフラグが立てられます。

これは本番環境でも実行できます。最初のアクセスを高速化しますが、QAステップでこれを何よりも望んでいるように感じます。その場合は、選択したビルドツールのテストフェーズにプリコンパイルステップを追加できます。CI環境にも追加できます。これにより、コンパイルされないjspがテストから外れないことが保証されます。

プリコンパイルタスクの実行の詳細については、次を参照してください。

JbossJasper設定

お役に立てれば。

于 2009-06-09T08:31:28.273 に答える
0

Pablojim は正しい軌道に乗っています。何が起こっているのかを完全に把握するには、もう少し情報が必要です。これが私がそれを理解する方法です。

prod で、他の JSP を再コンパイルする必要がある JSP を変更しました。それらを再コンパイルするには、2 つのいずれかが発生する必要があります。

  1. コンパイルされたバージョンの jsp を削除する必要があります。
  2. JSP自体を変更する必要があります（または「触れた」場合でも-変更日が更新されます）

それでもすべての jsps が機能することを確認する必要がある場合は、それらすべてをant task を使用してプリコンパイルする必要があります。これにより、war ファイル内のコンパイル済み jsps を使用して war ファイルをデプロイすることもできます。これで問題が解決するはずです。

ファイルが war ファイルではなく、展開された形式でデプロイされている場合は、Web アプリをデプロイ用に war ファイルにパッケージ化することを真剣に検討する必要があります。これにより、環境間で展開するのに適したパッケージになります。

于 2009-06-12T15:07:55.403 に答える
0

一部の JSP コンテナー (JSP 1.2 仕様のセクション 8.4.2 による) は、JSP ページのプリコンパイル機能をサポートしています。

JSP ページをプリコンパイルするには、クエリ文字列 ?jsp_precompile を使用してページにアクセスします。

http://hostname.com/mywebapp/mypage.jsp?jsp_precompile

JSP ページは実行されません。コンテナーがプリコンパイルをサポートしている場合、JSP ページは必要に応じてコンパイルされます。

http://www.rgagnon.com/javadetails/java-0414.htmlも参照してください。

于 2009-06-10T11:33:45.193 に答える