Я в настоящее время замечаю, что сторонняя библиотека (а именно, restfb) использует java.util.logging, и я вижу, что те журналы заканчиваются в STDOUT даже при том, что у меня нет консоли SLF4J appender настроенной в моем logback.xml. У меня также есть мост jul-to-slf4j в моем пути к классу. jul-to-slf4j соединяет мостом только журнал к appenders, настроенному logback, когда мост установлен, или он также регистрируется к stdout?
Я использую SLF4J и новый драйвер 42.0.0
Пост-ГРЭС Соответственно журнал изменений , он использует java.util.logging
, Чтобы иметь журналы драйвера, которые это достаточно:
Добавляют мост jul-to-slf4j :
<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();
}
Решение, которое кажется хорошим (рассмотрение обстоятельств с ИЮЛЕМ, образовывая мост) и работает на меня, так как я только должен записать все в файл .
logback.groovy (, Если Вы не используете конфигурация logback.groovy или logback во всем , конечно, Вы имеете к [1 119], поместило логическую часть в некоторый класс (например, как class MyApp { static { /* log init code here */ } ... }
) .)
src/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, кодируют Вар/функции, как Вы видите в здесь с, например, SLF4JBridgeHandler или dir журнала относительно , webappDirName)
(оставил файл завершенным, так как он производит лучшее впечатление, как все может быть установкой или поскольку пристальный шаблон)
(может относиться к кому-то - мой ENV: slf4j 1.7.5, logback 1.1.2, отличный 2.1.9 )
Мое решение:
SLF4JBridgeHandler.install();
java.util.logging.LogManager.getLogManager().getLogger("").setLevel( Level.INFO);
размещение jul-to-slf4j на Вашем приложении освобождает, или glassfish освобождает, они перенаправляют ИЮЛЬ к 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>
последняя конфигурация состоит в том, чтобы не быть загрязненной другими регистраторами
Как упомянуто в 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's 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 должен привести к хорошей производительности независимо от загрузки.