典型的なWebアプリケーションをTomcatにデプロイしています。要件は、アプリケーションを更新するときに、フルパッケージ配信（warファイル）ではなく、増分更新方法を提供することです。
たとえば、jarファイル、XMLファイル、およびjpgファイルを変更するバグ修正を完了すると。これらの3つのファイルをパッチと呼びます。パッチファイルを配信することになっています。お客様が元のバージョンにロールバックしたい場合でも、パッチをロールバックする方法を提供する必要があります。すべてのプロセスは自動的に行われることになっています。
私の観点からは、この要件は意味がありません。フルパッケージ配信は、Webアプリケーションを更新するための簡単で信頼性の高い方法です。複雑で、エラーが発生しやすい更新方法を紹介したくありません。
増分更新要件を実装するアイデアはありますか？ありがとう！
.warまたは.earをデプロイすると、通常、アプリケーションサーバーはそれを内部ディレクトリに解凍します。このディレクトリ内のファイルを、より細かい粒度で直接変更できます。ただし、変更を一貫して有効にするには、サーバーを再起動する必要があります。
あなたの見方は確かに完全に正しいです。現在、ファイルのサイズは重要な役割を果たしていません。全体の更新に問題は見られません。顧客が更新全体に満足していないのはなぜですか？
注：彼が望んでいるのが動的更新である場合、つまりサーバーを再起動しない場合、これはとにかくまったく別の問題であり、Javaの実動システムではほとんど不可能です（ただし、JRebelなどのソリューションを使用して開発中に実行できます）。
Delta-Syncプロトコルを使用するJavaプログラムを作成できます。つまり、更新されるファイルのみをアップロードする必要があります。Dropboxを使用したことがある場合は、かなりよく理解できます。Dropboxは、Delta-Syncプロトコルを使用して、ファイルを更新し、データを同期します。
いずれにせよ、当面は、クライアント（サーバーのWARフォルダーにマッピング）とローカルマシンにインストールしてそのフォルダーを共有することで、Dropboxを使用できます。次に、ローカルマシンのファイルを変更するたびに、それらのCHANGED（PATCH）ファイルがクライアントのマシンに自動的にアップロードおよび同期されます。