[slf4j-dev] Trace and/or Ignore.

[robert burrell donkin]

On Tue, 2005-07-05 at 10:24 +0200, Endre Stølsvik wrote:
> On Sun, 3 Jul 2005, robert burrell donkin wrote:
> 
> | On Wed, 2005-06-29 at 13:12 +0200, Endre Stølsvik wrote:
> | 
> | <snip>
> | 
> | > I'd just like to comment on this topic, as trace is (or rather would be) 
> | > my favourite log-level ever. It has kinda become "a hot topic" with lots 
> | > of arguments.
> | 
> | but it's also the most badly abused
> | 
> | > The main problem with debug is that it is the only "development-level" 
> | > available in log4j, and (thus) also in slf4j.
> | 
> | ceki's convinced me that (nearly all of the time) the reason for this is
> | poor logging strategy. 
> 
> Tell me about this "logging strategy", will you?
> 
> I've been using log4j for a pretty long time now, and I miss trace. I 
> -could- just "move down" some notches, as I find that there are too many 
> "heavy" levels (info, warn, error, fatal - what's the need for "fatal" 
> anyway?), but then I'd have to output my verbose debugging lines on INFO, 
> and my extremely verbose tracing lines on "DEBUG". That isn't right.
> 
> I assume (oh well..!) that everybode agrees that "info" should be turned 
> on in most production environments, while debug obviously is off? See, the 
> next level is "warn", and that isn't right either - I'd like to see 
> "contract added" (that's not a warning) - "user data changed" (not a 
> warning either), and all similar messages. These are -informational-, and 
> not warnings.

IMHO info should not be turned on in production unless targeting and
area for debugging. but ceki's the expert on this kind of thing so
hopefully he'll jump in here...

> Had there been a "notice" level, I'd accept to "move down" with my debug 
> and trace needs down to info and debug.
> 
> But now, back to you: what's this "logging strategy" of yours and Ceki's 
> that I obviously haven't grasped?

it's not my strategy :)

it's just when given some source using trace, ceki has always convinced
me that the usage could be eliminated by improving the logging by the
code. there may well be legitimate use cases for trace out there. that's
what we're trying to discover.

- robert