[slf4j-dev] Re: Beta 4 and the new method signatures

[Endre Stølsvik]

| >> ...
| > It's indeed workable but is it better? As mentioned previously, I think
| > that the simplified Log interface does not solve the extra use cases.
| >
| > If "info" is a logger, then
| >
| >   info.log("doing something now");
| >
| > is not exactly the same as
| >
| >   logger.info(""doing something now");
| >
| > While both statements are likely to be allowed to print on the output
| > devices, the first statement would leave no clue about the origin of the
| > log whereas the second form would print the logger name (hence the class
| > name).
| 
| I think these are both statements are equivalent.  Neither gives the location
| of the source - both only give the scope that the logger was declared in.
| 
| It just so happens that by convention the logger.info("something") style
| has a logger per class.   There is nothing in the simple Log API that prevents
| you having an info logger per class if you feel the need.
| 
| Personally I like my debug statements to be very well located (and would
| probably appreciate the option of an inefficient file:line location
| mechanism).   But I see very little reason to have a tight scope for
| errors and warnings (often with a stack trace has the detailed location).
| If an info is ambiguous then perhaps it is not actually logging very much
| "information"

I don't quite agree. It is valuable to see that a warning was emitted from 
the Authentication subsystem. Or the Form Validator system. Or that an 
error was emitted from the data store, or from the rendering system.

It sort of gives you "free contextual information" in the sense that the 
log message itself don't need to say "Vertex rendering calculation 
pipeline overloaded by 10 elements", since the loggers name is 
"RENDERER.vertex.calc.pipeline". (Please note that the examples probably 
aren't that fantastic, but please just gloss over that..!) Debug, trace, 
warnings and errors will all have benefit from this logger's name. The 
error can then simply be "10 elements overload". 
  In addition, all messages will have the same formatting on the 
contextual information - you don't need to parse the entire message to see 
that it was the vertext calculation pipeline that failed. And obviously 
-sorting- of the errors are even more important - all things regarding 
this pipeline can be dumped to one logfile.

Regarding the access logger scenario: you don't need to include the 
logger's name (category!) and level in the logfile. You could have a 
category called "ACCESS.log" which is coupled to an Appender (log4j 
terminology) that only emits the message - info-messages going here will 
be your access log. You could even emit your 404's to this logger at 
error-level, so that you can can configure an additional Appender with 
just the 404s in it - but still the access log would be correct. Or maybe 
you'd emit the 404s at ACCESS.log.404 at error level, and 200s at 
ACCESS.log.200 at info level and so on. Then to get all errors, you could 
go by the level, or more fine grained by the sub-category. What about 
ACCESS.log.2.200 (Since the return codes are grouped by the hundreds)?

Regards,
Endre.