1

現在、-Djava.util.logging.config.file を使用して指定された単一のログ構成で Tomcat 7 を使用しており、-Djava.util.logging.manager="org.apache.juli.ClassLoaderLogManager" を使用してデフォルトの ClassLoaderLogManager を使用しています。これは、1 回限りのスタートアップ構成に最適です。

いくつかのサーブレットと、サーブレット コンテキストの外部で実行されるその他のコードがあります。完全に制御する専用の tomcat サーバーで実行し、すべてのコードで同じログ構成を使用する必要があります。ロギングには java.util.logging API を使用しています。これは、LogManager.getLogManager().getLogger(name) が機能する必要があり、Logger.isLoggable(Level) が機能する必要があることを意味します。

ClassLoaderLogManager は、サーブレットが個々のログ設定を指定できるようにするという、私たちの状況とは反対の方向に向けられているようです。すべてのログを 1 か所で管理したいと考えています。しかし、改善された FileHandlers のような他の JULI の利点が必要です。

ここで質問:アプリケーションをリロードせずに実行時にファイルからこれらの設定をリロードするにはどうすればよいですか?

私が試したこと：

  • LogManager.getLogManger.readConfiguration(): Thread.currentThread.getContextClassLoader() はシステム クラスローダーではないため、ClassLoaderLogManager で効果的な NOOP が発生します。
  • Thread.setContextClassLoader(ClassLoader.getSystemClassLoader()) を明示的に設定してから、上記を呼び出します。これは実際に構成ファイルを読み取りました (デバッガーでステップスルー) が、含まれている ClassLoader 内の既存のロガーに変更を伝達しませんでした。Logger.setLevel() が既存のロガーで呼び出されることはありませんでした。
  • これらの呼び出しの前に reset() を呼び出しても何も変わらないようです。
  • JMX は、単一の ClassLoader (おそらくシステム ClassLoader) のロガーのみを公開しているようです。
4

2 に答える 2

2

これに対する1つの解決策を見つけました。起動スクリプトのログ マネージャをデフォルトの java.util.logging.LogManager に置き換えるか、単にコマンド ライン引数を削除すると、通常の LogManager が使用されます。この LogManager は、readConfiguration() が呼び出されると、すべての ClassLoaders のすべての Logger の構成を完全に再読み込みします。まさに必要な動作です。

ただし、これには tomcat 起動スクリプトの変更が必要です。それをせずに誰かがより良い解決策を見つけることができれば、それは素晴らしいことです。それ以外の場合は、この回答を受け入れます。

于 2013-02-28T20:48:11.143 に答える
0

Tomcat JULI と結婚していない場合は、Logback の使用を検討することをお勧めします。これは、実行時にログ構成のリロードを確実に処理する唯一の方法であるためです。

私はこれを自分で行ったことはありませんが、ガイドを書いた人がいます: Logging with SLF4J and Logback in Tomcat and TomEE which 基本的に一連のブリッジ jar を使用します。

あなたが考慮するかもしれない他のことは、LogbackでWebアプリごとのロギングを使用し、TomcatのJULIログを無視することです(それが私がしていることです)。

警告: http://www.slf4j.org/legacy.html#jul-to-slf4j ... したがって、JULを直接使用しないでください.... Guavaと Tomcat は、JUL を使用するための私の $hit リストにあります。

于 2013-02-28T18:21:34.173 に答える