weblogicのhibernateからの巨大なNodeManagerログ

Question

weblogic 8.1の1台で突然膨大な量のログが記録され、ディスクがいっぱいになりました。

mydrive:\bea\weblogic81\common\nodemanager\NodeManagerLogs\generatedManagedServer1\managedserveroutput.log 

に常駐し、ログファイルのエントリはちょうどentriresのsamekindsは、何度も何度も繰り返されている。私たちにハッセルを与え、ログ私はどこにも設定されているすべてのデバッグ設定を見つけるカント

19:17:46,798 DEBUG [CascadingAction] cascading to saveOrUpdate: mypackage.config.common.Share 
19:17:46,798 DEBUG [DefaultSaveOrUpdateEventListener] reassociated uninitialized proxy 
19:17:46,798 DEBUG [Cascade] done processing cascade ACTION_SAVE_UPDATE for: mypackage.config.common.FileLocation 
19:17:46,798 DEBUG [Cascade] processing cascade ACTION_SAVE_UPDATE for: mypackage.config.common.FileLocation 
19:17:46,798 DEBUG [CascadingAction] cascading to saveOrUpdate: mypackage.config.common.Share 
19:17:46,798 DEBUG [DefaultSaveOrUpdateEventListener] reassociated uninitialized proxy 

19:21:24,470 DEBUG [StdRowLockSemaphore] Lock 'TRIGGER_ACCESS' returned by: LLL-SCHEDULER_QuartzSchedulerThread 
19:21:31,923 DEBUG [StdRowLockSemaphore] Lock 'STATE_ACCESS' is deLLLred by: QuartzScheduler_LLL-SCHEDULER-NACDLLLF011219763113220_ClusterManager 
19:21:31,923 DEBUG [StdRowLockSemaphore] Lock 'STATE_ACCESS' is being obtained: QuartzScheduler_LLL-SCHEDULER-NACDLLLF011219763113220_ClusterManager 
19:21:31,923 DEBUG [StdRowLockSemaphore] Lock 'STATE_ACCESS' given to: QuartzScheduler_LLL-SCHEDULER-NACDLLLF011219763113220_ClusterManager 
19:21:31,923 DEBUG [StdRowLockSemaphore] Lock 'TRIGGER_ACCESS' is deLLLred by: QuartzScheduler_LLL-SCHEDULER-NACDLLLF011219763113220_ClusterManager 

ようなもの...。 Iveは、リモート開始クラスパスと管理対象サーバーの引数を調べました。

誰でもこのログファイルを制御する方向で私を指摘できますか？

Answer 1

これらのログエントリは問題ではないため、グローバルログレベルがDEBUGに設定されているように見えます。代わりに、おそらく新しいロギングメカニズムが実装されているか、stdoutに書き込んでWeblogicによって再ログされている新しいログAppenderです。私はあなたのロガーの設定を見ていきます。例えば

（これはデフォルトの設定を使用している場合、または、1でそれを提供）、アクティブLog4Jの設定とHibernateを使用する場合は、Hibernateは自動的にあなたがあなた自身のアプリケーションに設定することをLog4Jのインスタンスで参加します

これは、通常のLog4J設定に従って調整することができます。この例では、プロパティの設定のスタイルを使用しています：

HibernateはApacheのコモンズロギングAPIを介して他のログメカニズムで参加することができる

log4j.category.org.hibernate=WARN 

。独自のロガーを設定し、org.hibernate。*の周波数を調整する方法を見てください。

n.b.デバッグ中にスイッチバックするとき

log4j.category.org.hibernate.SQL=INFO or DEBUG 

が役に立ちます。

Answer 2

プログラマーが多い大規模なシステムですか？そうであれば、コード内のどこにも設定がプログラム的に変更されたロガーであることを確認する価値があります。

log4jでは、これはLogManagerまたはBasicConfiguratorクラスを使用して実行できます。またPropertyConfiguratorとDomConfiguratorを介して。あなたの例に示されているPatternLayoutを使用して、コードの1つの不正な行だけが新しいLoggerをstdoutに設定できます。

BasicConfigurator.configure();