2

ほとんどの開発者として、メソッドの本体に小さな変更を加え、コンテナを停止および開始せずにテストしたいと考えています。Tomcat。JVMによって提供されるホットスワップ機能は有望であるように思われ、TomcatとSpringコンテキストの両方がリロードされないようにしたかったのです。これは、単一モジュールのMavenプロジェクトがある場合に非常にうまく機能します。ただし、スタイルのマルチモジュールMavenWebプロジェクトを扱っている場合

kilo
-kilo-business
-kilo-common
-kilo-dao
-kilo-web

kilo-business依存モジュール（たとえば、モジュールが依存するモジュール）のクラスのメソッド本体に変更を加えたいkilo-web場合、ホットスワップにより、Tomcatのコンテキスト、したがってSpringのコンテキストがリロードされます。kilo-webモジュール自体のクラスに変更が加えられた場合、コンテキストは再ロードされません。これにより、で変更されたjarがあるためWEB-INF/lib、Tomcatは、のクラスで何かが変更された場合とは異なる方法で処理していると思いますWEB-INF/classes。もちろん、この推論は経験的なものです-誰かが本物の情報源とその推論を指摘できれば素晴らしいでしょう。

さらに重要なことに、これを回避するためのアイデアはありますか？依存するjarの内容が含まれている場合、この問題は解消されWEB-INF/classesますか？に依存するプロジェクトを展開されたディレクトリとしてデプロイするために、eclipseWTPプラグインを作成する方法を見つけることができませんでしたWEB-INF/classes。

JRebelが提供する優れた機能について聞いたことはありますが、JVM自体が提供できるものを最大限に活用できるようにしたいと考えていました。

前もって感謝します！

4

1 に答える 1

1

実際、TomcatインスタンスはEclipseを介してデバッグモードで実行されていました。でクラスのメソッド本体を変更するkilo-webと、JVMTIがホットコードスワップを実行したため、変更は出力に反映されましたが、WEB-INF / classesのクラス自体は変更されませんでした（最後に変更されたタイムスタンプから確認されました）。断続的に気付いたのと同じように、依存モジュールでも同じことが起こりますkilo-common（ただし、それでも機能します）。結局のところ、赤いニシン-私の謝罪。

より一般的には、クラスローダーに関するJevgeni Kabanovの話を聞いた後、Tomcatで使用されるクラスをリロードするバニラアプローチでは、既存のクラスローダーから状態をコピーする（そして関連するリークを伴う癖に遭遇する）まったく新しいクラスローダーが作成されるため、コンテキストのリロードが必要になります。 。全体的に、素晴らしいビデオ。

于 2012-09-13T18:57:14.900 に答える