Подавить все выходные данные Logback для консоли?

эти сообщения отображаются только в том случае, если хотя бы одно из следующих значений истинно:

• вы включили отладку в logback.xml-файл
• у вас ошибка в конфигурации. Это так здесь-logback жалуется на несколько найденных файлов конфигурации.
• существует проблема пути к классам, если ваша среда предоставляет конфликтующие файлы. (это пришло мне в голову вчера и было реальной причиной этого вопроса).
• (есть баг в logback-случилось)

исправьте проблему, и эти сообщения должны уйти.

это" я тоже " ответ, Извините!

к счастью, я нашел решение (см. обновление) ниже.

в отличие от некоторых других ответов, я получаю поток конфигурации LogBack INFO сообщения, несмотря на отсутствие ERRORили WARNs в фазе конфигурации.

вот мои сообщения:

13:39:20,457 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
13:39:20,457 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
13:39:20,457 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/home/carl/workspace-LSY/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/IceProfile/WEB-INF/classes/logback.xml]
13:39:20,496 |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@14e2c9c - Will scan for changes in file [/home/carl/workspace-LSY/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/IceProfile/WEB-INF/classes/logback.xml] every 60 seconds. 
13:39:20,496 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter
13:39:20,497 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
13:39:20,501 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [STDOUT]
13:39:20,510 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
13:39:20,510 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [encoder] on top of the object stack.
13:39:20,537 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG
13:39:20,537 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT]
13:39:20,538 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [ch.qos.logback] to OFF
13:39:20,538 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [ch.qos.logback] to false
13:39:20,538 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.

вот моя конфигурация:

<configuration debug="true" scan="true"> 

  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> 
    <!-- encoders are  by default assigned the type
         ch.qos.logback.classic.encoder.PatternLayoutEncoder -->
    <encoder>
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
    </encoder>
  </appender>

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

  <logger name="ch.qos.logback" level="OFF" additivity="false" />

</configuration>

это спам я не хочу, я считаю себя невиновным в том, что они вызвали и я был бы признателен за помощь в избавлении от него.

один из аспектов, в котором я могу быть "виновен", заключается в том, что я инициализирую свои регистраторы в static переменная; документы рекомендуют использовать переменные экземпляра вместо этого.

варианты:

• logback-classic-0.9.24.банку
• logback-core-0.9.24.банку
• slf4j-api-1.6.1.банку
• выполнение в приложении IceFaces 2.0, работающем в Tomcat 6.0 под Ubuntu 11.04

---

обновление

наконец-то понял, в чем проблема!

С документацию (и ответ Торбьерна):

Установка атрибута debug внутри элемента будет выводить информацию о состоянии, в предположении, что

1. файл конфигурации найден
2. файл конфигурации хорошо сформированный XML.

моя ошибка была

<configuration debug="true" scan="true"> 

в ретроспективе, ужас! Надеемся, эта информация поможет другим.

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

вы аппендер должен выглядеть что-то вроде

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">

 <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
  <level>info</level>
 </filter>

 <encoder>
  <pattern>%d{yyyy-MM-dd} %d{HH:mm:ss} %.-1level %thread %logger{36}: %m%n</pattern>
 </encoder>

</appender>

Я написал в блоге о более полное описание того, что я изменил, что сработало для меня

Я не знаком с 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
    }
}

(этот код не тестировался)

в моем случае, у меня был "logback-тест.xml " в зависимом проекте, который был развернут как webapp jar. "Logback-тест.xml " файл начинается с

<configuration debug="false" scan="true">

атрибут 'scan="true "' породил эту ошибку:

ERROR in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@716de067 - URL [jar:file:/C:/Local...cut.../WEB-INF/lib/My.Dev.jar!/logback-test.xml] is not of type file

что привело к 67 (!) дополнительные информационные линии.

удалив атрибут 'scan= "true", журнал logback полностью исчез.

собственно то, что тот же logback.расположение xml сообщается несколько раз, кажется, больше похоже на ошибку в logback, чем что-либо еще. Либо сообщите об этом в logback JIRA (здесь) или сначала проверьте, находится ли рассматриваемый jar на пути к классу несколько раз.

У вас, скорее всего, есть элемент, настроенный в вашем logback.XML. Вы можете удалить его, если вы не хотите никаких обновлений консоли о состоянии самой структуры ведения журнала. Тем не менее, Logback framework рекомендует не отключать его для устранения неполадок.

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

Я просто хочу добавить информацию о сообщении заголовка по умолчанию, добавленном в logback 1.0.2:

#logback.classic pattern: %d [%thread] %-5level %logger{36} - %msg%n

Я нашел это в logback news, но это было очень трудно найти.

Если вы хотите, чтобы удалить это сообщение, вы должны настроить outputPatternAsPresentationHeader в false:

<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
        <pattern>%d %-5level [%thread] %logger{0}: %msg%n</pattern>
        <!-- do not print pattern as a header -->
        <outputPatternAsPresentationHeader>false</outputPatternAsPresentationHeader>
    </encoder>
</appender>

<configuration>
<statusListener class="ch.qos.logback.core.status.NopStatusListener" />
</configuration>

просто используйте класс NopStatusLinstener, и это остановит самостоятельное ведение журнала logback.