2015-12-29 4 views
0

У меня есть webapp, работающий на Jetty 9.3.6 в ${jetty.base}, который установлен в /opt/mybase/. Мой веб-приложение использует slf4j и я использую log4j в качестве фактической основы регистрации, поэтому операторы лесозаготовительных в моем источнике WebAPP выглядит следующим образом:Jetty 9.1+: как получить мои журналы webapp с log4j/slf4j

import org.slf4j.Logger; 
import org.slf4j.LoggerFactory; 

public class SillyClass 
{ 
    private static final Logger log = LoggerFactory.getLogger (SillyClass.class.getName()); 

    ... 

    public static void foo() 
    { 
     if (error()) 
     { 
      log.error ("ERROR"); 
     } 
     else 
     { 
      log.info ("NOT an error"); 
     } 
    } 

    ... 

} 

И в моем Gradle файл сборки, я сделал это:

dependencies { 

... 
compile 'org.slf4j:slf4j-api:1.7.12' 
compile 'org.slf4j:slf4j-log4j12:1.7.12' 
compile 'log4j:log4j:1.2.17' 
... 
} 

Эта конфигурация хорошо работает для другого (не-Jetty, non-webapp) Java-проекта, который использует ту же систему ведения журнала; Я могу использовать ${project.home}/src/main/resources/log4j.properties для управления выходом журнала.

В любом случае, когда я переехал в Джетти, я следил за инструкциями here до точки; но как только я это сделал, я ударил multiple-bindings error. Чтобы исправить это, я удалил slf4j ссылки в моем Gradle файл сборки, но это привело к ошибке:

java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of org/eclipse/jetty/start/Classpath$Loader) for the method's defining class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature 

Я тогда удалил все ссылки на slf4j и log4j (закомментированный три линии я показываю в моей build.gradle выше), но ошибка, которую я вижу, по-прежнему остается прежней. Что я делаю не так?

Мой /opt/mybase/resources/log4j.properties файл:

log4j.rootLogger=TRACE, FILE 
log4j.appender.FILE=org.apache.log4j.FileAppender 
log4j.appender.FILE.File=/opt/mybase/logs/jetty.log 
log4j.appender.FILE.Append=false 
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout 
log4j.appender.FILE.layout.ConversionPattern= %d{dd MMM yyyy HH:mm:ss.SSS} %l %m%n 

Любая помощь приветствуется.

+1

Вы должны попробовать, используя только одну зависимость 'compile 'org.slf4j: slf4j-log4j12: 1.7.12'' вместо этого все три – nullpointer

+0

Возможный дубликат http://stackoverflow.com/questions/14024756/slf4j-class -path-contains-multiple-slf4j-bindings – nullpointer

+0

Это не работает: я больше не вижу никаких журналов. Я отредактировал свой OP для 'log4j.properties' Сообщение с несколькими связями возвращается, когда я удаляю' compile 'org.slf4j: slf4j-log4j12: 1.7.12''. – Sonny

ответ

0

Ну, это по-настоящему смущающая ошибка с моей стороны. Главный вопрос был не log4j или slf4j, либо конфигурация в причале, я считаю. Я думаю, что все отлично. Кроме того, несмотря на многократные привязки, сервер Пристань фактически выбирает что-то показано здесь в журналах Jetty:

SLF4J: Class path contains multiple SLF4J bindings. 
SLF4J: Found binding in [jar:file:/tmp/jetty-0.0.0.0-443-webapp.war-_webapp-any-8458003046853847474.dir/webapp/WEB-INF/lib/slf4j-log4j12- 1.7.12.jar!/org/slf4j/impl/StaticLoggerBinder.class] 
SLF4J: Found binding in [jar:file:/opt/mybase/webapp/lib/logging/slf4j-log4j12- 1.6.6.jar!/org/slf4j/impl/StaticLoggerBinder.class] 
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. 
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory] 

Кроме того, если зависимость имеет протоколирование встраиваемый, вы не повезло, в зависимости от того, насколько хорошо поддерживается вещи Я думаю, что у вас все равно будет столкновение. По крайней мере, я не знаю, как предотвратить это.

Ну, реальная проблема в том, что веб-приложение не имеет свой собственный log4j.properties (если вы используете Gradle, это было бы в $(projectHome)/src/main/resources/log4j.properties). Я добавил, что в мой проект и мой каротаж делает намного больше смысла (то есть, я см. там, где это должно быть, в /opt/mybase/logs/my-silly-webapp-log.txt).

Наконец, авария, о которой я сообщал, не имеет отношения (в комментариях, 29 декабря) и связана с ошибкой Jetty 9.3.6, которая еще не решена, появляется , несмотря на то, что он был вызван в решении Jetty bug db для 9.3.6. Что меня отбросило, так это то, что журналы появились сразу после ошибки multiple_bindings, о которой я сообщал изначально. Они не связаны, похоже. Я не могу отследить точную ошибку в Jetty bug DB, поскольку я пишу это, но последний I ch ecked that bug (около недели назад), вопрос был, когда Jettylog4j.properties/opt/mybase/resources/log4j.properties) установил rootLogger в DEBUG (получил это из комментариев к этой ошибке). Я могу воспроизвести ошибку (приложение websocket просто отлично работает, несмотря на аварийный сбой журнала Jetty), когда мой rootLogger в Jetty log4j.properties установлен в DEBUG.Переместив rootLogger на Jettylog4j.properties в INFO или ниже, я могу подтвердить, что проблема уходит. Я подниму его в DB ошибки Jetty.

Надеюсь, это поможет кому-то.

Смежные вопросы