あるドメインに固有のプロパティファイルはどこに置けばよいですか？

あるアプリケーションが、配備(deploy)された場所に依存してリソースの構成を行う必要
があり、さらにそのアプリケーションを「変更せずに」異なった環境にも配備したい場合
を想像してみてください。
簡単な例としては、アプリケーションの作業ディレクトリを指定し、そのアプリケーション
を開発、テスト、そして運用環境に配備するけど、データベースは構成コンポーネントには
入れたくないような場合です。

ドメイン全体に対するプロパティファイルは良い解決策になります。EAR の変更は必要
ないし、DB に依存しないし、再配備にも対応します。

では、そのようなファイルをどこに置けば良いのでしょうか？

プロパティファイルは歴史的に Glassloader.getResource と関連するメソッドによって
ロードされます。ということは、プロパティファイルはクラスパス上に置いておく必要
があります。

サーバー上では、簡単に既知の場所のサーバークラスパスを追加することができ、
プロパティファイルをそこに置くことができます。

そして、サーバーのクラスローダーから見える、ライブラリやクラスのための
ドメイン固有の場所が用意されています。

$domain が、そのドメインのディレクトリだと仮定してみましょう（Windows での
インストールならば、デフォルトドメインなら一般的に C:\Sun\AppServer\domains\domain1
になります)。

この場合、プロパティファイルを配備する標準的な場所は次のようになります:

$domain/lib/classes

このように、examples.properties のようなファイルをこのディレクトリに置いて、
アプリケーションから使うことができます。

このプロパティファイルにアクセスするには、次のようなコードを使います:

public Properties loadProperties() throws IOException {
    Properties prop = new Properties();
    InputStream is = this.getClass().getClassLoader().getResourceAsStream("examples.properties");
    if (is != null) {
        try {
            prop.load(is);
        }
        finally {
            // Forgetting to close input streams from property loaders
            // is a common source of resource leaks in applications.
            is.close();
        }
    }
    return prop;
}

このメソッドは EJB でも WAR でも使えます。$domain/lib/classes ディレクトリは
どちらのコンポーネントのクラスパスでもあるからです。

日本語翻訳: shioda

英文 (翻訳したバージョン: 1)