Spring Java EE アプリケーションを実行するために、Tomcat 6 で IntelliJ を使用しています。コンパイルされた war を展開するのではなく、展開された war 展開を使用することを選択したため、一部のクラスと JSP をホットスワップするオプションが与えられました。
ただし、「クラスの更新」および「クラスとリソースの更新」とは別に、IntelliJ では、ユーザーが更新アクションで「再デプロイ」および「サーバーを再起動」することもできます。この 2 つの選択肢の違いは何ですか?
クラスのメソッド シグネチャを変更した場合、または Springconfig.xml を変更した場合、サーバーを再起動する必要がありますか、それとも再デプロイで十分ですか? 関数シグネチャまたはそれらに関連付けられた注釈が変更されたクラスを単純にホットスワップできないことに気付きました。
サーバーの再起動は、まさにそのとおりに実行し、Tomcat サーバーを再起動します。戦争はサーバーの起動時に再構築され、展開されます。これは、クラスのホットスワップに問題がある場合に役立ちます。
再デプロイは、変更されたクラスやその他のリソースをホットスワップアウトしようとするのではなく、(サーバーを再起動せずに) .war 全体を再デプロイします。
参照: http://www.jetbrains.com/idea/webhelp/updating-a-running-java-ee-application.html
2 番目の質問への回答としては、再デプロイで十分です。とはいえ、メモリ リークが発生する可能性があり、多くの場合、完全な再起動よりもわずかに高速です。
リソースを更新します。変更されたすべてのリソース (つまり、クラス以外のすべてのアプリケーション コンポーネント) が更新されます。
クラスとリソースを更新します。変更されたすべてのリソースが更新されます。変更されたクラスは再コンパイルされます。デバッグ モードでは、更新されたクラスがホットスワップされます。実行モードでは、IntelliJ IDEA は出力フォルダー内の変更されたクラスを更新するだけです。そのようなクラスが実行中のアプリケーションで実際に再ロードされるかどうかは、使用されているランタイムの機能によって異なります。
再デプロイします。アプリケーションが更新され、再デプロイされます。
サーバーを再起動します。サーバーが再起動されます。アプリケーションの更新されたバージョンは、サーバーの起動時にデプロイされます。パックされたアーティファクトの場合、使用可能なオプションは次のとおりです。
ホットスワップクラス。変更されたクラスは、実行時に再コンパイルおよび再ロードされます。このオプションは、デバッグ モードでのみ機能することに注意してください。再デプロイします。アプリケーション全体が再構築され、再デプロイされます。サーバーを再起動します。サーバーが再起動されます。アプリケーションは、サーバーの起動時に再構築およびデプロイされます。
から: http://www.jetbrains.com/idea/webhelp/run-debug-configuration-tomcat.html