Suppress all Logback output to console?

Solution 1:

Those messages only show if at least one of the following is true:

• you have debugging enabled in the logback.xml file
• you have an error in your configuration. That is the case here - logback complains about multiple configuration files found.
• there is a classpath problem if your environment provides conflicting files. (this one occurred to me yesterday and was the real cause of this question).
• (there is a bug in logback - has happened)

Correct the issue and those messages should go away.

Solution 2:

Holger Hoffstätte was correct in his diagnosis that the duplicate classpath entry message is a symptom of a bug in how Logback counts classpath entries. Robert Elliot also characterized the problem in a thread on the Logback user mailing list. According to Robert and others in this related disussion on the SLF4J mailing list, when an application that uses Logback runs in a WebLogic container, due to the way the WebLogic classloader operates, Logback reports duplicate classpath entries for the logback.xml configuration file. However, regardless of whether the WebLogic classloader should or should not report only unique classpath entries, Logback should certainly count only unique classpath entries so that it does not print this confusing, spurious message.

I have implemented a fix for LBCLASSIC-159 that essentially does what Robert Elliot recommends and uses a set instead of a list to hold the resources that the classloader returns, effectively eliminating any duplicate classpath resources. I have successfully tested the fix with Logback 0.9.24, SLF4J 1.6.1, and WebLogic 10.3.2. As Thorbjørn predicted in his answer, with this fix in place, Logback no longer displays the duplicate classpath entry status messages (or any of the other informational messages) to standard output.

I hope that the maintainers will integrate my fix into the main Logback source code repository and include it in the next release.

Solution 3:

This is a "me too" answer, sorry!

Happily, I've found a solution (see UPDATE) below.

Contrary to some of the other answers, I'm getting a stream of LogBack configuration INFO messages in spite of having no ERRORs or WARNs in the configuration phase.

Here are my messages:

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.

Here's my 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>

This is spam I don't want, I consider myself innocent of having provoked it, and I'd appreciate some help in getting rid of it.

One respect in which I may be "guilty" is that I'm initializing my loggers in a static variable; the docs recommend using instance variables instead.

Versions:

• logback-classic-0.9.24.jar
• logback-core-0.9.24.jar
• slf4j-api-1.6.1.jar
• executing in an IceFaces 2.0 app running in Tomcat 6.0 under Ubuntu 11.04

UPDATE

Finally figured out what the problem was!

From the fine manual (and Thorbjørn's answer):

Setting the debug attribute within the element will output status information, under the assumption that

1. the configuration file is found
2. the configuration file is well-formed XML.

My mistake was

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

In retrospect, duh! Hopefully this information will help others.