[slf4j-dev] TRACE level

[Endre Stølsvik]

On Thu, 30 Jun 2005, Ceki [iso-8859-1] Gülcü wrote:

| 
| I've been looking at Jboss source code and failed to discover a
| convincing use case of the trace(Object) method, other than the
| ignore() exception use case previously described by Greg.

I can't talk for JBoss.

They also have had to use a logging framework where they have had to 
"wedge in" the trace support, not getting proper javadocs integration for 
the extra level in their IDE and whatnot.

| 
| trace() without debug()
| =======================
| 
| In some JBoss classes, e.g. org.jboss.util.stream.Streams, the trace()
| method is invoked without ever invoking debug(). It follows that by
| default, there is no log output generated by this class.
| 
| However, the same effect could have been achieved by having the
| Streams class invoke debug() and by setting the level of the
| org.jboss.util.stream.Streams logger to INFO or higher.

This is what I find interesting: you obviously feel that one should 
-really tailor- the logging hierarchy in the logconfig xml file, f.ex. set 
that category to info (since one wants informational messages there), and 
this category to warn (since that class-set uses info for debug, and debug 
for "very verbose" debug), and this category to error (since that package 
use both debug, info and warn for debugging purposes), etc etc.

You seem to argue for a totally free-use of the levels, where info one 
place would output "contextual information", while other places, it would 
be different - and the user of your framework or application would have to 
DIG into your logging-hierarchy and the extensive logging-manuals that 
obviously would have to come with your application to grasp which 
categories should have what level enabled for a "normal prod env.".

I want a -clear name- for the logging output. I'd set -the entire 
server/application- into "info" when going prod. Then, if something bad 
happens, I'd set large chuncks of the logger hierarchy into debug, and the 
parts where I believe the bugs are hidden, to trace.


Back to the Stream class you mention: What if the developers of that 
Stream class thinks that -all- info emitted from that class isn't relevant 
for debug - just for trace? That is totally relevant - There are thus 
really no "debug log lines" from that class (although _I'd_ put in one on 
close() and probably on the whatever open method there is).

Your arguments about trace and debug not found in same class could be 
drawn further to say that "_all_ levels should be used in all classes, or 
else they are not needed". That is obviously flawed. And if some levels 
should have to go, that would then be "fatal" (who -ever- uses fatal 
anyway?) - the log-level that by the name of it should have -one- log-line 
ever, and that's right before the application/system terminates 
unexpectedly. I believe this fatal level is gone from slf4j also? Good. 
Now add trace, and' you'd have a perfect levels hierarchy.

If one had both trace and debug in the logging package, you'd see much 
more of the dual-use. Now people probably can't reflect properly over the 
levels. What they get, is a shitload of "production-levels", while only 
one "development level" to choose from. No wonder it's confusing people.


Here's some javadoc for the perfect 5-level-hierarchy! ;)

I've added some subjective opinions about libraries' use of the levels, 
vs. application's use of the levels.

What more could be needed? What are redundant?

/**
 * Error - Production level: used for errors and unexpected events,
 * of a nature that (probably) will cause the (end) application to produce 
 * some error-report and/or decision taking element to the end-user. 
 * Unrecoverable errors, in the sense that the operation in progress was 
 * terminated since it couldn't continue due to this event. ...
 *
 * Libraries should be vary of this level, and only use it when their
 * function is severly impacted by the error condition - remember that
 * the using application might view the library's error as a normal, 
 * handle-able condition. ..
 */

/**
 * Warn - Production level: used for warnings, typically errors that the 
 * application/library was able to handle, typically without user 
 * intervention, but which some administrator should try to correct the 
 * cause of at some point, as it might escalate, or point to other 
 * problems. Recoverable errors. Could also signify that some condition 
 * or exception occurred that obviously points to a bug in the code, but 
 * which the application could recover from. ...
 * 
 * As with "error", libraries should be vary of using this level. ...
 */

/**
 * Info - Production level: used for informational messages, typically
 * events of some noticable application relevant level, like "new 
 * customer added" in a CRM application .. ...... 
 *
 * Notice that normal libraries shouldn't use the info-level much, as they 
 * wouldn't know what is "informational messages" within the application 
 * that uses it - use the {@link #debug} level instead . .. ...
 */

/**
 * Debug - Development / debugging level: used for contextual information
 * of a rather verbose level. Events of some "programmatical important" 
 * level. Won't normally be "turned on" except when contextual information 
 * around some of the other production levels is needed, typically in
 * a debugging or code extension scenario. ... 
 * 
 * Libraries' "info" messages would also typically go here.
 */

/**
 * Trace - Development / debugging level: used for <b>very verbose</b> 
 * information which "traces" the program-flow, e.g. for every iteration
 * of some loop. Cannot be expected to ever be turned on after the code is 
 * "finished" except when debugging or extending this specific part. ...
 *
 * This level may be used extensively within libraries, so that a user
 * of the library may turn on trace to see the code-flow behind each
 * method invocation. ...
 */

Regards,
Endre.