[logback-user] How To Use Filters

[Ceki Gülcü]

Hi Yoram,

Comments inline.

At 07:52 PM 1/3/2007, Yoram Forscher wrote:
>Hi Sebastien,
>
>Happy New Year to you too and thanks for the prompt reply.
>
>You were correct, of course. I was using a previous version of logback,
>because the IDE I'm using (Intellij) did not clear WEB-INF/lib before
>copying the JAR files, leaving the previous version there.
>
>Now that I use the correct JAR files, the filters work correctly.
>
>One new thing that I noticed, and I think it's a change from previous
>versions, is that when creating a context
>(LoggerFactory.getILoggerFactory()), this context is initialized with
>the default configuration which includes a console appender. In order to
>start from a clean slate I had to invoke shutdownAndReset() on the
>context before loading my own configuration. This is not documented, and
>frankly I think this behavior is incorrect.

We've been agonizing about the question of default configuration in
the absence of a (default) configuration file for a very long time. We
have recently succumbed to user demand and now initialize the context
with a console appender in case no default configuration could be
found.

There are pros and cons to this approach. Many, including myself,
consider that defaulting to the console, without any explicit
action by the user, as desirable. However, in case configuration is
performed explicitly at a later stage, one must make sure to call
shutdownAndReset() on the logging context. This is unfortunately
undocumented in the "Short Introduction". This omission should be
considered a bug which we will fix for the next release.

There is one case I can imagine where the current behavior might be
troublesome. Assume that before the user can explicitly configure
logback, some other component makes logging calls. In that case those
logs will appear on the console instead of being lost.

WDYT?

>One last thing: what is the expected behavior of
>logger.isDebugEnabled(marker)?

The method isXXXEnabled(Marker) is part of the org.slf4j.Logger
interface.

The original idea was to allow the value returned by isDebugEnabled to
depend on a marker value. However, it turns out that this is not
possible in practice. Thus, in the current code of logback
isDebugEnabled(Marker) simply delegates to isDebugEnabled().



>Thanks for your help,

Thanks for your interest in logback,

>Yoram

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch