通常、単一のWebサーバーにデプロイされるアプリケーションを開発します。ここでは、クラスタ環境での動作を確認します。一部の顧客はクラスタを使用しています。J2EEクラスタ：中央設定を処理する一般的な方法はありますか？
問題は、アプリケーションがクラスタ内で意味をなさないローカル設定（レジストリ/ファイル内）を作成することです。設定はアプリケーションによって変更されます。 アプリケーションがクラスタにデプロイされているときに、コンフィグレーション（-file）自体が各ノードに重複しないように、インターフェイスのような汎用的な方法がありますか？その他の推奨オプションはありますか？ （ネットワーク共有/データベース/いくつかのMBeanの設定で手動で行うのですか？）
なぜ汎用ですか？異なるアプリケーションサーバー（tomcat、jboss、Webspere、weblogicなど）上で実行する必要があります。そのため、サーバー固有の機能を使用することはできません。
ありがとうございました。
中央設定の最も簡単な方法は、ファイルシステムに配置することです。これにより、ファイルシステムをOSにマウントして、ブランドやバージョンに関係なくアプリケーションサーバーで使用できるようになります。
私たちはいくつかのアプリケーションでこれを行います。私たちが気にしている共有ライブラリやプロパティファイル。実行時にマウントされたドライブへのパスを検索し、ファイルからデータをロードできるように、JVM parmsまたはJNDI環境変数を設定します（それらに向かって移動しようとしています）。
私たちのためにかなりかすかに動作します。
今、情報を書き込んでいれば、それは別の話です。クラスタをどのように運用しているのか心配する必要があります（ロードバランシングのみ可能ですか？）。 1つのアプリのように、両方のクラスタでアプリが実行されていますか？または、それは各クラスタノードで独立して実行されていますか？もしそうなら、同時書き込みについて心配する必要があります。上記のように、データベースまたは他の解決策の1つを使用する方がよいでしょう。
しかし、あなたがやっているのは設定を読んでいるのなら、私はマウントされたファイルシステムを最も簡単なものとして選ぶでしょう。
Commons Configurationのようなライブラリを使用して、JDBCやJNDIのようにクラスタフレンドリな実装を選択することができます。
私はJDBCとJDNIをまず考えていますが、サーバーを独立して実行できるようにするには、subversion/git/mercurialのようなファイル配布システムをお勧めします。つまり、中央設定サーバーがダウンしているか、生産を止めたくない。失敗の別のポイントを加算し、中央サーバーの問題を回避するために
バージョン管理システムは時に変更内容作られ、制御リリース（とバックのリリースのロール）人の歴史を提供
一つの方法は、使用することですあなたがすでに稼働していない場合は、あなたはとにかく働かないということに基づいて、あなたがすでに（あなたが持っていると仮定して）依存しているdatabasseサーバです。
私はこのような疑いがあります。実際には、私たちの顧客から（config-databaseのような）追加の情報を必要としたくありません。私のチームと私はあなたのアイデアを検討します。ありがとう。 –