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 _______________________________________________ Logback-user mailing list [email protected] http://qos.ch/mailman/listinfo/logback-user
