このソリューションでは、いくつかの場所で変更が必要であり、主にslf4j構成の問題でした。私のアプリには多数の依存関係があり、さまざまなロギング実装が導入されています。Slf4jは、それらをすべてまとめて囲い込むように設計されており、プロセスは多くの場合、jarの簡単なドロップインですが、java.util.loggingにはもう少し手間がかかります。
slf4j Bridging Legacy APIページでは、(ほとんどの場合)Jerseyによって導入されたJUL依存関係を接続する方法について説明しています。すでにjul-to-slf4j.jarを含めていましたが、正しく接続されていませんでした。SLF4JBridgeHandler.install()
アプリの初期化で実行する必要がありました。さらに、logback.xmlファイルに以下も含めない限り、このページはパフォーマンスへの悪影響について警告しています。
<contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator">
<resetJUL>true</resetJUL>
</contextListener>
それでほとんどの方法が得られましたが、ログイベントの重複が発生しました。1つはslf4jに移動し、もう1つはstderrを続行しました。Googleは、ClausNeilsenのブログの記事「java.util.loggingをSLF4Jにブリッジする」を紹介してくれました。これには、役立つコードスニペットが含まれていました。
// Jersey uses java.util.logging - bridge to slf4
java.util.logging.Logger rootLogger = LogManager.getLogManager().getLogger("");
Handler[] handlers = rootLogger.getHandlers();
for (int i = 0; i < handlers.length; i++) {
rootLogger.removeHandler(handlers[i]);
}
SLF4JBridgeHandler.install();
これで、jsvc stderr出力に表示されていたJerseyログが、logback.xmlの指示に従って、適切にフォーマットされた残りのログとともに表示されるようになりました。