http://d.hatena.ne.jp/cero-t/20100907/1283874313
あまりにも懐かしくて思わず反応。
java.util.loggingはJavaのlibフォルダのところにあるロギング設定プロパティファイルを読んで実行します。もしくはオプションで設定をかえることもできます。
これらのことからわかるようにVMの起動時に静的な設定をまずします。そしてreadConfigrationメソッドはその静的な設定のリセット用です。
つまり、JavaVMで1つの設定が必ず有効になります。なので各種読み込みはわざとすべてシステムクラスローダになっています。ソースを見るとわかりますが、びっくりするくらいシステムクラスローダを使う箇所だらけです。
つまり、アプリケーションより下の層で設定されるべきもの、アプリケーションに左右されるべきではないものという扱いです。
エンタープライズアプリケーションはクラスローダがたくさんありますので、もちろんそのままでははねられます。また、ログの設定（出力するレベルも）を管理するのはアプリケーションサーバーであり、アプリ側が設定するべきではないという考え方でしょう。データソースはアプリ側が設定すべきではない、JNDIで取得するべきだというのと同じですね。Glassfishなどもドメインのライブラリにおくようになっていたはずです。
となるとアプリとセットでログハンドラを設定したい場合（アプリごとにログのはき方を変える場合がどれだけあるか）に困ります。エンタープライズアプリケーションならばまだアプリケーションサーバーの設定でいける分だけ問題はないですが、クラスローダがシステムじゃないところから立ち上がるやつで困ることになります。
そうです。WebStartでもこのためにreadConfigurationはききません。
というわけで、java.util.loggingをアプリとセットで使う場合はコードでアプリの起動直後にセットアップ系の処理を書くというのが常識となっています。設定ファイルを読み込むようなコードを書いてるのを見かけた場合、本当にそれは理解していてやっているのか注意する必要があります。
というのがJ2SE1.4あたりで散々言われたことです。もう8年前か…おっさんになるはずだな。
