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