This seems like a carelessness error, but I can't seem to find the cause. Logging with logback/slf4j (most recent version slf4j-api-1.6.1, logback core/classic 0.9.24). Simplest log configuration for testing is:

11:21:27,825 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
11:21:27,826 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] at [file:.../logback-test.xml]
11:21:28,116 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
11:21:28,124 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
11:21:28,129 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [stdout]
11:21:28,180 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [layout] on top of the object stack.
11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - This appender no longer admits a layout as a sub-component, set an encoder instead.
11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - To ensure compatibility, wrapping your layout in LayoutWrappingEncoder.
11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - See also http://logback.qos.ch/codes.html#layoutInsteadOfEncoder for details
11:21:28,207 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG
11:21:28,207 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [stdout] to Logger[ROOT]

which is, according to the docs, the format logback uses for default. It then finishes reading the config (which is set up to output a different format) and continues with the properly formatted output. There's a config parameter <configuration debug="false"> which does not affect this.

8 Answers
8

If you set the debug attribute of the configuration element to true, you will get all status information to the console. If this is your problem, just set it to false or remove it.

If you have any configuration problems of level WARN or above, you will also get all status information logged to the console (including messages of level INFO). The best solution to this problem is to fix the problem (in your case replace the <layout> element with an <encoder> element).

If you for some reason cannot fix the problem, but want to remove the status-information from the console, you can instead configure an alternative StatusListener. Use the NopStatusListener to completely remove the status-information:

This is the right answer, it should be upvoted more, thank you. (logback 1.0.11)
– Jakub KulhanFeb 3 '14 at 15:01

3

This totally worked, should be accepted answer!
– raffianOct 30 '15 at 23:40

3

This worked. I wasn't entire clear that the INFO log messages would disappear, too, but in fact they do. I know the answer says this, but for some reason it wasn't clear to me. To be oh-so-clear: fix the encoder/layout problem and not only will the warning messages go away, but the info messages will go away, too, even though they are unrelated to the problem.
– JasonNov 22 '15 at 1:34

3

Did not work with the debug attribute, but worked flawlessy with the status listener.
– Ameba SpugnosaJun 23 '16 at 13:08

As described in the docs, if warnings or errors occur during the parsing of the configuration file, logback will automatically print status data on the console.

Follow http://logback.qos.ch/codes.html#layoutInsteadOfEncoder i.e.
the link mentioned by logback in its warning message. Once you follow the steps mentioned therein, that is, if you replace <layout> element with <encoder>, logback will stop printing messages on the console.

Sort of right, although you did point me in the right direction. I'd changed to that encoder syntax without effect, although it turns out that removing another line in the logback.xml that was causing a warning did the trick. The deceptive thing about it is that the output seems to be outputting decisions made before it actually parses your logback file, (1>Could NOT find resource [logback.groovy],2>Found resource [logback-test.xml]). It's pretty confusing for a fix in the logback-test to hide status messages for what happens before it gets parsed. But thanks for the pointer.
– Steve B.Jul 16 '10 at 13:49

5

I think what Steve B. meant is that it's counterintuitive (or at least unconventional) that Logback should suppress all status messages, including (and particularly) those that precede the loading of the configuration file, unless it encounters an error later in the configuration. When you are unfamiliar with this rule and first see these status messages (which imply a configurtion warning or error), most users would expect that once the error is resolved, Logback would no longer print the related error messages, but continue to print the other status messages.
– Derek MaharAug 5 '10 at 16:23

5

FWIW, i also find this quite confusing behaviour. The spew of INFO level messages does a pretty good job of hiding the ERROR messages telling me what i actually need to fix. The lack of a DTD, or any other specification of the syntax of the configuration file, made it quite a trial to debug even once i spotted the message.
– Tom AndersonMay 8 '11 at 18:34

4

@Ceki: I finally figured it out: The 2nd way to trigger these messages is to have the debug="true" attribute in the configuration element of logback.xml. Please mention this for the benefit of other people who fall into this hole!
– Carl SmotriczOct 12 '11 at 21:26

4

Perhaps before the first INFO statement there should be a 'Warning detected, outputting all past status info. To stop this message, fix your warnings/errors'
– David RousselMay 2 '13 at 19:40

(...)if warnings or errors occur during the parsing of the configuration file, logback will automatically print status data on the console.

Once you get it right, there won't be any pollution in the first lines of your log anymore.

As of March 2015, in Logback 1.1.2, you need to use <encoder> sub-component - <layout> is now deprecated and if use it, error messages will appear. You cannot control this, it´s Logback default behavior.

Some internal classes have been renamed too, and even the examples in their manual page are outdated!

If you want to completely remove those messages, use the NopStatusListener as Rasmus described. The encoder vs layout approach does not suppress messages such as 'logback.groovy not found' for example. I'm using logback-classic 1.1.3 (March 2015)
– Cristian BotizaJun 16 '15 at 19:48

I've tried everything and nothing worked for me. My problem was due to multiple logback.xml files in my classpath. This is the common case in multi modular projects.
When there is only one logback.xml file in classpath, there is no ambiguity and the problem is solved.

Using the logback.groovy: statusListener(NopStatusListener) (in the src/test/resources/logback.groovy) works.

(A valid use case is e.g. if working with ANT in Eclipse, using logback logging, groovy classes and unit tests where the unit tests take the src/test/resources/logback.groovy, but will also see the src/main/resources/logback.groovy (or similar) you cannot exclude (if ANT's classpath is said to use the projects classpath).)