JUL to SLF4J Bridge

Ответ 1

Вам нужно позвонить SLF4JBridgeHandler.install(). Вам также необходимо включить все уровни журналов в корневом журнале (причина в выдержке ниже) в java.util.logging и удалить консольный appender по умолчанию.

Этот обработчик перенаправит jul logging на SLF4J. Однако только журналы разрешено в j.u.l. будет перенаправлен. Например, если оператор журнала вызывая j.u.l. logger отключил этот оператор, по определению, будет не достигают экземпляра SLF4JBridgeHandler и не могут быть перенаправлены.

Весь процесс может быть выполнен следующим образом

import java.util.logging.LogManager;
import java.util.logging.Logger;
import org.slf4j.bridge.SLF4JBridgeHandler;

LogManager.getLogManager().reset();
SLF4JBridgeHandler.removeHandlersForRootLogger();
SLF4JBridgeHandler.install();
Logger.getLogger("global").setLevel(Level.FINEST);

Вы можете установить уровень на что-то более высокое, чем самое лучшее по соображениям производительности, но вы не сможете включить эти журналы, не включив их сначала в java.util.logging (по причине, упомянутой выше в выдержке).

Ответ 2

Как упоминалось в javadocs для SLF4JBridgeHandler, вы можете либо программно установить SLF4JBridgeHandler, вызвав:

 // Optionally remove existing handlers attached to j.u.l root logger
 SLF4JBridgeHandler.removeHandlersForRootLogger();  // (since SLF4J 1.6.5)

 // add SLF4JBridgeHandler to j.u.l root logger, should be done once during
 // the initialization phase of your application
 SLF4JBridgeHandler.install();

или через logging.properties

 // register SLF4JBridgeHandler as handler for the j.u.l. root logger
 handlers = org.slf4j.bridge.SLF4JBridgeHandler

Что касается производительности, обсуждается этот раздел в разделе jul-to-slf4j. По сути, поскольку вы уже используете logback, включение LevelChangePropagator должно обеспечивать хорошую производительность независимо от нагрузки.

Ответ 3

Мое решение:

SLF4JBridgeHandler.install();
java.util.logging.LogManager.getLogManager().getLogger("").setLevel( Level.INFO);

размещение jul-to-slf4j в ваших библиотеках приложений или библиотеках GlassFish, они перенаправляют JUL на SLF4J (и, следовательно, в моем случае в LOG4J)

то для Джерси вы можете сделать что-то вроде:

<logger name="com.sun.jersey" additivity="false">
    <level value="WARN" />
    <appender-ref ref="JVM" />
    <appender-ref ref="CONSOLE" />
</logger>   

<logger name="com.sun.common.util.logging" additivity="false">
    <level value="ERROR" />
    <appender-ref ref="JVM" />
    <appender-ref ref="CONSOLE" />
</logger>

последняя конфигурация должна избегать загрязнения другими регистраторами

Ответ 4

Решение, которое кажется приятным (учитывая обстоятельства с JUL-мостом) и работает для меня, так как мне нужно писать все в файле logback.groovy.

• ( Если вы не используете конфигурацию loglog.groovy или logback на всех, конечно, вы должны поместить логическую часть в некоторый класс (например, например class MyApp { static { /* log init code here */ } ... }).)

• ЦСИ /logback.groovy

  import org.slf4j.bridge.SLF4JBridgeHandler
  import ch.qos.logback.classic.jul.LevelChangePropagator
  
  // for debug: just to see it in case something is logging/initialized before
  System.out.println( 'my myapp logback.groovy is loading' )
  
  // see also: http://logback.qos.ch/manual/configuration.html#LevelChangePropagator
  // performance speedup for redirected JUL loggers
  def lcp = new LevelChangePropagator()
  lcp.context = context
  lcp.resetJUL = true
  context.addListener(lcp)
  
  // needed only for the JUL bridge: http://stackoverflow.com/a/9117188/1915920
  java.util.logging.LogManager.getLogManager().reset()
  SLF4JBridgeHandler.removeHandlersForRootLogger()
  SLF4JBridgeHandler.install()
  java.util.logging.Logger.getLogger( "global" ).setLevel( java.util.logging.Level.FINEST )
  
  def logPattern = "%date |%.-1level| [%thread] %20.20logger{10}|  %msg%n"
  
  appender("STDOUT", ConsoleAppender) {
      encoder(PatternLayoutEncoder) {
          pattern = logPattern
      }
  }
  
  /*// outcommenting in dev will not create dummy empty file
  appender("ROLLING", RollingFileAppender) {  // prod
      encoder(PatternLayoutEncoder) {
          Pattern = "%date %.-1level [%thread] %20.20logger{10}  %msg%n"
      }
      rollingPolicy(TimeBasedRollingPolicy) {
          FileNamePattern = "${WEBAPP_DIR}/log/orgv-fst-gwt-%d{yyyy-MM-dd}.zip"
      }
  }
  */
  
  appender("FILE", FileAppender) {  // dev
  
      // log to myapp/tmp (independent of running in dev/prod or junit mode:
  
      //System.out.println( 'DEBUG: WEBAPP_DIR env prop:  "."='+new File('.').absolutePath+',  \${WEBAPP_DIR}=${WEBAPP_DIR},  env=' + System.getProperty( "WEBAPP_DIR" ))
      String webappDirName = "war"
      if ( new File( "./../"+webappDirName ).exists() )  // we are not running within a junit test
          file = "../tmp/myapp.log"
      else  // junit test
          file = "tmp/myapp-junit-tests.log"
  
      encoder(PatternLayoutEncoder) { pattern = logPattern }
  }
  
  // without JUL bridge:
  //root(WARN, ["STDOUT", "ROLLING"])  // prod
  //root(DEBUG, ["STDOUT", "FILE"])  // dev
  
  // with JUL bridge: (workaround: see links above)
  def rootLvl = WARN
  root(TRACE, [/*"STDOUT",*/ "FILE"])
  // I manually added all "root package dirs" I know my libs are based on to apply
  // the root level to the second "package dir level" at least
  // depending on your libs used you could remove entries, but I would recommend
  // to add common entries instead (feel free to edit this post if you like to
  // enhance it anywhere)
  logger( "antlr", rootLvl )
  logger( "de", rootLvl )
  logger( "ch", rootLvl )
  logger( "com", rootLvl )
  logger( "java", rootLvl )
  logger( "javassist", rootLvl )
  logger( "javax", rootLvl )
  logger( "junit", rootLvl )
  logger( "groovy", rootLvl )
  logger( "net", rootLvl )
  logger( "org", rootLvl )
  logger( "sun", rootLvl )
  
  
  // my logger setup
  
  logger( "myapp", DEBUG )
  
  
  //logger( "org.hibernate.SQL", DEBUG )  // debug: log SQL statements in DEBUG mode
  //logger( "org.hibernate.type", TRACE )  // debug: log JDBC parameters in TRACE mode
  logger( "org.hibernate.type.BasicTypeRegistry", WARN )  // uninteresting
  
  scan("30 seconds")  // reload/apply-on-change config every x sec
  

(рекомендуется для меня использовать, так как вы можете реагировать на Java-код vars/functions, как вы можете видеть здесь, например, SLF4JBridgeHandler или каталог журнала в отношении webappDirName)

(оставил файл завершенным, так как он дает лучшее впечатление о том, как все можно настроить или как шаблон для просмотра)

(может иметь отношение к кому-то - мой env: slf4j 1.7.5, logback 1.1.2, groovy 2.1.9)

Ответ 5

Я использую SLF4J и новый драйвер Postgres 42.0.0

В соответствии с changelog используется java.util.logging

Чтобы иметь журналы драйверов, достаточно:

• Добавить jul-to-slf4j bridge:

  <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>jul-to-slf4j</artifactId>
      <version>${slf4j.version}</version>
      <scope>runtime</scope>
  </dependency>
  

• Добавить в logback.xml(logback-test.xml)

  <contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator">
      <resetJUL>true</resetJUL>
  </contextListener>
  
  <appender ...
  
  <logger name="org.postgresql" level="trace"/>`
  

• Добавить в код

  static {
      SLF4JBridgeHandler.install();
  }