Выборочно отключить журнал отладки log4j в консоли Play

У меня есть приложение Play 2.0, я запустил play console из командной строки. Где-то в одной из библиотек, которые я использую, он использует log4j и начал передавать вывод отладки для [crawler4j][1], я пытаюсь выяснить, как выборочно отключить этот вывод в игровой консоли. Я безуспешно пытался изменить следующее в application.conf и logger.xml

application.conf
logger.root=ERROR
logger.play=ERROR
logger.application=ERROR

logger.xml
<logger name="org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager" level="ERROR"/>

Вот пример журнала отладки потоковой передачи

13:10:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.conn.tsccm.ConnPoolByRoute - Closing connections idle longer than 60 SECONDS
13:10:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.c.t.ThreadSafeClientConnManager - Closing connections idle longer than 60 SECONDS
13:10:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.conn.tsccm.ConnPoolByRoute - Closing connections idle longer than 60 SECONDS
13:10:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.c.t.ThreadSafeClientConnManager - Closing connections idle longer than 60 SECONDS
13:10:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.conn.tsccm.ConnPoolByRoute - Closing connections idle longer than 60 SECONDS
13:10:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.c.t.ThreadSafeClientConnManager - Closing connections idle longer than 60 SECONDS
13:10:18.819 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.conn.tsccm.ConnPoolByRoute - Closing connections idle longer than 60 SECONDS
13:11:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.c.t.ThreadSafeClientConnManager - Closing connections idle longer than 60 SECONDS
13:11:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.conn.tsccm.ConnPoolByRoute - Closing connections idle longer than 60 SECONDS
13:11:18.819 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.c.t.ThreadSafeClientConnManager - Closing connections idle longer than 60 SECONDS
13:11:18.819 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.conn.tsccm.ConnPoolByRoute - Closing connections idle longer than 60 SECONDS

Просто для ясности: настройки журнала применяются, когда я запускаю приложение Play из командной строки, а когда я запускаю его из play console, настройки не применяются.


scala log4j playframework playframework-2.0 crawler4j
person Bob    schedule 24.07.2012    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Я не думаю, что log4j здесь используется на самом деле. HTTP-клиент Apache, который является библиотекой, производящей отладку, ведет журнал через ведение журнала Apache Commons.

Play2 использует API SLF4J с бэкендом для логбэка.

В вашем пути к классам есть библиотека под названием jcl-over-slf4j, которая заставляет сообщения журнала, идущие в журнал apache commons, через переход через SLF4J, а затем вернуться в систему. (Я знаю, это запутанно, но это попытка позволить SLF4J выступать в качестве фасада для всех остальных, а его серверной части быть «одним регистратором, чтобы управлять ими всеми»).

В документах play2 указано, что файл logger.xml должен позволять полностью настраивать параметры ведения журнала, поэтому Я думаю, что при наличии файла logger.xml настройки application.conf не действуют.

logger.xml должен быть полным файлом конфигурации журнала. Я не уверен, что вы опубликовали полное содержимое logger.xml или только изменения.

Чтобы подавить вывод, подобный показанному, вы должны иметь возможность установить содержимое logger.xml примерно так:

<configuration>

  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
    </encoder>
  </appender>

  <logger name="org.apache.http.impl.conn.tsccm" level="error" />

  <root level="debug">
    <appender-ref ref="STDOUT" />
  </root>

</configuration>

Если это не сработает, измените верхнюю строку на:

<configuration debug="true">

что приведет к тому, что logback зарегистрирует свою попытку настроить себя. Это может дать больше указателей.

Надеюсь это поможет.

person Brian Smith    schedule 24.07.2012
comment
Да, я уже сделал все это раньше, но безуспешно. Я обнаружил, что этот параметр соблюдается, если я запускаю приложение Play из команды, проблема в том, что когда я запускаю его из консоли Play, он не соблюдает этот параметр. Я надеюсь, что есть способ это исправить. - person Bob; 25.07.2012
comment
Когда вы запускаете игру из консоли с логбэком ‹configuration debug=true›, видите ли вы вывод логбека, показывающий его инициализацию при запуске приложения? Если нет, вы можете попробовать запустить игровую консоль с параметром командной строки -Dlogger.resource=conf/logger.xml? - person Brian Smith; 25.07.2012
comment
Спасибо за предложение, попытка с -Dlogger.resource=conf/logger.xml тоже не помогла. Является ли logger.resource правильной переменной? Вот точная команда play -Dlogger.resource=conf/logger.xml console - person Bob; 25.07.2012
comment
logger.resource — одна из трех переменных, которые вы можете использовать в соответствии с документацией. У меня заканчиваются идеи, но последняя попытка. Я неправильно понял, что вы имели в виду под консолью, я думал, вы имели в виду игровую оболочку, но теперь я понимаю, что вы запускаете консоль scala изнутри. Это может быть связано с конфигурацией регистратора sbt, а не с приложением Play. Некоторая информация о регистраторах задач есть на github.com/harrah/xsbt/wiki/Tasks. Я бы попробовал: установить logLevel в консоли := Level.Warn в командной строке воспроизведения, а затем в консоли. Если это работает, вы можете добавить его в настройки сборки sbt. - person Brian Smith; 26.07.2012
comment
Доблестное усилие, но, к сожалению, безрезультатно, это оказывается довольно рассолом. Спасибо за ваши усилия! - person Bob; 26.07.2012
comment
Сегодня был выпущен Play 2.0.3 с исправлением ошибки, которая могла вызвать это. play.lighthouseapp.com/projects/82401/tickets/ Обновление может решить проблему. - person Brian Smith; 03.08.2012

arrow_upward
1
arrow_downward

Это сработало для меня:

import org.slf4j.{Logger, LoggerFactory}

LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME).asInstanceOf[
  ch.qos.logback.classic.Logger].setLevel(ch.qos.logback.classic.Level.INFO)
person thesamet    schedule 26.11.2012