実行時にjar / warファイルのconfig.propertiesファイルを変更し、変更をホットデプロイしますか? 私の要件は次のとおりです。jar/war ファイルに「config.properties」があります。Web ページからファイルを開く必要があり、ユーザーが必要な変更を加えた後、「config.properties」を更新する必要があります。 properties" を jar/war ファイルに追加し、ホット デプロイします。この偉業を達成できますか?もしそうなら、私がこれにジャンプスタートできるように、関連するサイト/ドキュメントを教えてください.
3 に答える
アーキテクトがこのソリューションを再考することを強くお勧めします。あなたが説明することは、プロパティをリロードするのではなく、JNDI または同様の手法を使用して行う必要があります。
デプロイメントは静的であると見なされるべきです - 特定の Web コンテナーが手品を可能にすることに依存するべきではなく、いつの日か壊れるでしょう (ほとんどの場合、最も不便な時期に)。
前に説明したコメントに同意したとしても、1つの解決策を提案できます。
Apache Commons Configuration拡張機能は、次のようなことを行う可能性を提供します。
config.setReloadingStrategy(new FileChangedReloadingStrategy());
これにより、コードをまったく使用せずに実行時に構成ファイルを変更するトリックが作成される可能性があります。
ただし、JNDIやその他のWebアプリケーション構成方法と同様に、セキュリティが問題になります。構成できる/構成できる必要のあるパラメーターに注意してください。
あなたは私の頭の上からいくつかの問題を抱えています:
以前にファイルをロード
static
した への参照を保持しているものがないことを確認します。java.util.Properties
config.properties
ほとんどのサーブレット エンジンは war を作業ディレクトリに展開するため、ロードするプロパティ ファイルは war 内のものではなく、展開されたものになります。これは、サーブレット エンジンを再起動すると変更が上書きされることを意味します。これは通常、戦争が展開されるポイントの 1 つであるためです。
これらの問題は克服できないわけではありませんが、プロパティを JNDI (Thorbjørn が提案しているように) またはデータベースに格納することによって (ポイント 1 で言及した静的参照に注意しながら)、この種の動作を実装する方がはるかに簡単であることが常にわかっています。
JNDI/データベース ソリューションには、通常、それぞれに独自のレジストリ/データベースがあるため、複数の環境への展開が容易になるという優れた副作用があります。