Подавить весь вывод Logback к консоли?
Как я могу настроить Logback для подавления всего его вывода к консоли (стандартный вывод)? В частности, я хочу подавить (или перенаправление) собственные сообщения журнала Logback, такие как следующее:
16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml]
16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs multiple times on the classpath.
16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml]
16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml]
16:50:25,923 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
16:50:25,924 |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@1a15291 - Will scan for changes in file [/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml] every 60 seconds.
Я должен отключить весь вход к стандартному выводу, потому что наша продуктивная среда запрещает приложения от печати любых сообщений к стандартному выводу.
Обратите внимание, что я использую Logback 0.9.21, SLF4J 1.6.0 и наше выполнение приложения в WebLogic 10.3.2.
4 ответа
Хольгер Хоффштетте был прав в своем диагнозе , что дублирующееся сообщение о записи пути к классам является признаком ошибки в том, как Logback считает записи пути к классам. Роберт Эллиот также охарактеризовал проблему в ветке в списке рассылки пользователей Logback . Согласно Роберту и другим участникам этой связанной дискуссии в списке рассылки SLF4J, когда приложение, использующее Logback, запускается в контейнере WebLogic, из-за способа работы загрузчика классов WebLogic Logback сообщает о повторяющихся записях пути к классам для файл конфигурации logback.xml . Однако, независимо от того, должен ли загрузчик классов WebLogic сообщать только об уникальных записях пути к классам, Logback обязательно должен подсчитывать только уникальные записи пути к классам, чтобы не выводить это сбивающее с толку, ложное сообщение.
Я реализовал исправление для LBCLASSIC-159 , которое, по сути, делает то, что рекомендует Роберт Эллиот, и использует набор вместо списка для хранения ресурсов, возвращаемых загрузчиком классов, эффективно устраняя любые повторяющиеся ресурсы пути к классам. Я успешно протестировал исправление с помощью Logback 0.9.24, SLF4J 1.6.1 и WebLogic 10.3.2. Как и предсказывал Торбьорн в своем ответе , с этим исправлением Logback больше не отображает дублирующиеся сообщения о состоянии записи пути к классам (или любые другие информационные сообщения) в стандартный вывод.
Я надеюсь, что сопровождающие интегрируют мое исправление в основной репозиторий исходного кода Logback и включат его в следующий выпуск.
Эти сообщения появляются только если верно хотя бы одно из следующих условий:
- у вас включена отладка в файле logback.xml
- у вас ошибка в конфигурации. В данном случае это так - logback жалуется на несколько найденных конфигурационных файлов.
- есть проблема с classpath, если ваше окружение предоставляет конфликтующие файлы. (этот вариант пришел мне в голову вчера и был истинной причиной этого вопроса).
- (есть ошибка в logback - уже случалось)
Исправьте проблему, и эти сообщения должны исчезнуть.
На самом деле тот факт, что одно и то же местоположение logback.xml сообщается несколько раз, больше похож на ошибку в логбэк, чем на что-либо еще. Либо сообщите об этом в JIRA для входа в систему ( здесь ), либо сначала проверьте, находится ли рассматриваемая jar в пути к классам несколько раз.
Я не знаком с Logback. Но если он печатается в System.out или System.err , это просто общедоступные статические PrintStream переменные в классе System . Вы можете создать подкласс PrintStream и установить системные выходные переменные для своего подкласса, таким образом контролируя его работу.
Например:
public class NOPPrintStream extends PrintStream
{
public NOPPrintStream() { super((OutputStream)null); }
public void println(String s) { /* Do nothing */ }
// You may or may not have to override other methods
}
public class MyClass
{
public static void main(String[] args)
{
System.out = new NOPPrintStream();
// Start program
}
}
(Этот код не проверялся)