私たちがしているのは、サーバー上の別のディレクトリに配置することです (/config、/opt/config、/root/config、/home/username/config、または必要なものを使用できます)。サーブレットが起動すると、XML ファイルが読み取られ、そこからいくつかの情報 (最も重要なのは DB 接続情報) が取得されます。
なぜこれを一度やったのかと尋ねました。
すべてを DB に格納できればよいのですが、当然、DB 接続情報を DB に格納することはできません。
コードにハードコーディングすることもできますが、それは多くの理由で醜いです。情報を変更する必要がある場合は、コードを再構築して再デプロイする必要があります。誰かがあなたのコードまたは WAR ファイルのコピーを取得すると、その情報を取得します。
WAR ファイルに何かを入れるのはいいことのように思えますが、大幅に変更したい場合は、悪い考えになる可能性があります。問題は、情報を変更する必要がある場合、次に再デプロイするときにファイルが上書きされるため、WAR に組み込まれるバージョンで変更することを覚えていなかったものがすべて忘れられることです。
ファイルシステムの特別な場所にあるファイルは、私たちにとって非常にうまく機能します。大きな欠点はありません。別々に保存されているため、複数のマシンに異なる構成値が必要な場合に簡単にデプロイできます (WAR の一部ではないため)。
私が考えることができる他の唯一の解決策は、DBログイン情報を除くすべてをDBに保持することです。これは、JVM を介して取得される Java システム プロパティから取得されます。これは、上記の Hans Doggen によって言及された Preferences API のことです。私たちのアプリケーションが最初に開発されたときではなかったと思います。
構成ファイルにアクセスするためのパスは、ファイルシステム上の単なるファイルです。Web パスについて心配する必要はありません。したがって、サーブレットが起動すると、「/config/myapp/config.xml」(またはその他) のファイルを開くだけで、適切なものが見つかります。このパスをハードコーディングするだけでも、私には無害に思えます。