[logback-user] Set Level per Logger AND Appender?

Ceki Gulcu listid at qos.ch
Thu Oct 30 14:24:43 CET 2008


Robert,

Thank you for your message. However I don't think I understood it very
well.

Why don't you attach directly a filter on the file appender that
writes to 'application.log'? Such a filter would ensure that no messages of
level INFO or lower would make it into 'application.log'. Are you aware
that filters can be attached directly on appenders?

Please see http://logback.qos.ch/manual/filters.html for documentation on
filters.

Robert Elliot wrote:
 > A common use case for me with log4j and now LogBack is that I want to
 > have a default logging setup appending to a (set of) file(s) -
 > typically this will be a root logger with level warn appending to say
 > application.log.  I will then tweak sub loggers to get exactly the
 > output I want - info in some places, error in others, so I get
 > sufficient feedback to see e.g. server startup and shutdown but
 > otherwise I only see things that are genuinely a potential problem.  I
 > consider this config part of the normal working operation of the
 > application, and expect to be able to retrieve the expected output at
 > any point in the future.  It's a system problem if any of that output
 > is lost or if the application.log is polluted with other log
 > statements.
 >
 > I then frequently want to set up more detailed debug logging for a
 > subset of the system - indeed I'm writing an Ajax based web console to
 > allow logging to be configured and output seen on the fly, having
 > written an aspectJ based trace logging aspect.
 >
 > The problem I experience is that if I set a Logger, using the normal
 > class based naming scheme, to level "DEBUG" then it will log at that
 > level to application.log as well as my debug appender, littering the
 > application.log file with message I do not want recorded there.  If I
 > turn additivity to false for that logger then it will no longer send
 > WARN messages to the application.log appender, losing the record of
 > all system problems that I expect application.log to contain.
 >
 > Does that make sense?  I hope it seems a reasonable use case.  If so,
 > what would be considered the best practice for achieving this?  In
 > log4j I would overcome this by creating a new appender that also
 > appends to application.log, assigning it to the logger I wanted to use
 > for debug and giving it an appropriate threshold to maintain the
 > general contract of application.log, and then setting the logger's
 > additivity to false.  This, however, is a very crude solution
 > involving a great deal of additional configuration and is very fragile
 > - any alterations to what I consider the "normal" logging behaviour of
 > my system may well require me to alter all debug configuration.
 >
 > (What I really want is to specify levels on the combination of a
 > logger and an appender rather than just on a logger.  This would allow
 > taking advantage of the inheritance system - the combination of root
 > logger and application.log appender's level of WARN would then be
 > inherited (and could be over-ridden, of course) by all loggers, and
 > adding a new debug appender to a logger and setting the level of that
 > logger & appender combo to DEBUG would not affect what was sent to
 > application.log at all.  If I were to work on making that possible in
 > Logback, would that alteration be considered, or is that seen as
 > undesirable?)
-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch


More information about the Logback-user mailing list