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

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 2

Those messages only show if

• you have debugging enabled in the logback.xml file
• you have an error in your configuration. Thats the case here - logback complains about multiple configuration files found.

Fix it and those messages should go away.

Answer 3

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 4

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