JBossを再起動せずに新しい変更をデプロイする方法を探していたところ、次のようになりました。
https://community.jboss.org/wiki/RedeployAnApplicationWhenChangeAFileInAnExplodedDeploymentDirectory
そして最初は、聖杯を見つけたと思っていました。展開されたディレクトリの最上位記述子に触れると、新しい変更が再デプロイされますが、その後、奇妙な動作とエラーが発生しました。
サーブレットとJavaクラスが再デプロイされていないことが判明しました。多くの否定的な答えを読んだ後、私はこれをあきらめましたが、少なくとも知りたいのですが、トップレベルの記述子に触れた後に再デプロイされるのは何ですか？
知っておく必要がある場合は、JBoss4xでの戦争としてJavaEEプロジェクトをデプロイしています。
アプリケーションは実際に再デプロイされますが、作業ディレクトリはデフォルトでは実際には削除されません（JBossがコンパイルされたjspを保存する場所です）。したがって、再デプロイ後、以前のコンパイル済みjspクラスが保持される場合があります。
JBoss 5.1（JBoss 4.xで利用可能かどうかは100％わかりません）では、JBossがアンデプロイされたときにアプリケーションの作業ディレクトリを強制的に削除するオプションがあります-再デプロイされます。このオプションは次の場所にあります：$ JBOSS_HOME / server / yourInstance / deployers / jbossweb.deployer / META-INF / war-deployers-jboss-beans.xml、このファイルでプロパティを探します：
<property name="deleteWorkDirOnContextDestroy">true</property>
デフォルトではfalseに設定されているため、trueに設定します。ホットデプロイの成功は他のクラスへの依存関係などに依存する場合がありますが、再デプロイ時に問題を解決するのに役立つ場合があります。一方、アプリケーションをホットデプロイまたは再デプロイする場合は、moveコマンド（mv）を使用しますが、コピーは使用しないでください。 （cp）1つ、mvはアトミックですがcpではないため（cpを使用すると、ファイルのコピー中にホットデプロイメントスキャナーをアクティブ化できます）。
ホット再デプロイのもう1つの解決策は、手動で削除することです（開発環境でのみ推奨）。次の一連のコマンドを使用します（既にデプロイディレクトリにいることを念頭に置いてください）。
rm yourapp.war; rm -rf ../work/jboss.web/localhost/yourapp;mv <newappversiondir>/yourapp.war .
ただし、本番環境や重要な環境でのホットデプロイメントは強くお勧めしません。