Suppress all Logback output to console?

Question

How can I configure Logback to suppress all of its output to the console (standard output)? In particular, I wish to suppress (or redirect) Logback's own log messages such as the following:

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. 

I need to disable all logging to standard output because our production environment disallows applications from printing any messages to standard output.

Note I'm using Logback 0.9.21, SLF4J 1.6.0, and our application runs in WebLogic 10.3.2.

Answer 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.

Answer 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.

Answer 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.

Answer 4

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

Simplely use NopStatusLinstener class and this will stop self logging of logback.

Answer 5

So I had the same problem but found that removing the incorrect <layout /> entry which was deprecated somewhere around 0.9.4 and the messages went away...

You appender should look some thing like

<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>

I've blogged about a more complete description of what I changed that worked for me

Answer 6

In my case, I had the "logback-test.xml" in a dependent project that was being deployed as a webapp jar. The "logback-test.xml" file started with

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

The 'scan="true"' attribute generated this error:

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

which resulted in 67 (!) more INFO lines.

By removing the 'scan="true"' attribute, the logback log disappeared altogether.

Answer 7

I'm not familiar with Logback. But if it's printing to System.out or System.err, these are simply public static PrintStream variables in the System class. You could subclass PrintStream and set the system output variables to your subclass, thus controlling how it works.

For example:

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
    }
}

(This code is untested)

Answer 8

Actually the fact that the same logback.xml location is reported multiple times seems more like a bug in logback than anything else. Either report this to the logback JIRA (here) or first check whether the jar in question is on the classpath multiple times.

Answer 9

I just want to add information about default header message added in logback 1.0.2:

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

I found that in logback news, but it was really difficult to find.

If you wish to remove this message, you have to set up outputPatternAsPresentationHeader to 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>

Answer 10

You most likely have a element configured in your logback.xml. You can remove it, if you don't want any console updates about the state of the logging framework itself. Though, logback framework recommends against disabling it for troubleshooting purposes.

There is an alternative to the console listener called StatusListenerAsList which keeps the status messages as a private list. You can expose it via JMX, if needed, with a little bit of code.

Answer 11

I got the following error logs in my spring boot application:

14:37:36,455 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@5:46 - no applicable action for [springProfile], current ElementPath  is [[configuration][springProfile]]
14:37:36,456 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@6:92 - no applicable action for [include], current ElementPath  is [[configuration][springProfile][include]]

I suppressed them by either:

• renaming logback.xml to logback-spring.xml
• or, define in application.properties: logging.config=classpath:logback.xml

---

Spring documentation on this topic: