[slf4j-dev] Re: TRACE level

Heiner Westphal susp48 at verit.de
Wed Aug 10 16:00:35 CEST 2005


Hi!

Whenever I read "trace", my first thought is s.t. like:
10:00 entering Berlin(byCar)
10:20 entering Berlin-Tempelhof(perPedes)
10:30 leaving Berlin-Tempelhof(perPedes) -> returned Sister
10:55 leaving Berlin(byCar) -> returned Sister

Most of this info can be acquired by logging
a "new Throwable()" wherever you need a stacktrace
(though you lose info about the history, e.g. which
  other method calls have returned before...).

The use cases presented for the TRACE level so far
suggest another name for it since they would use
it for the verboser part of DEBUG.

The level hierarchy needed for those use cases looks like:
ERROR-WARN-INFO-DEBUG(terse)-DEBUG(verbose/with all data displayed)

I cannot think of a naming for the two debug levels which makes
their purpose obvious and prevents "abuse".
Perhaps that's why Sun used FINE, FINER, FINEST; just because
there are no "good" names to suggest what they really are?
The terse debug to locate the source of a problem, in terms
of classes and methods (preferrably one liners) and
the verbose debug displaying the data being processed.

As niclas already stated:
 >And I could go with a trace() as well to make people happy, although I
 > think the name is very bad. notice() or verbose() is IMHO a lot
 > better, sitting between INFO and DEBUG.

BUT this conflicts with the use of log.trace() since
trace is the least serious level in JCL.

The other dimensions (logger hierarchy and Markers) are as well
useful at least for framework- and tools-developers (anyone who
delivers  components to developers).

The logger, sometimes referred to as category-, hierarchy I find
indispensible to focus on certain components when debugging
(and to block out unwanted verbosity).
I prefer using classnames here, since packages and classes usualy
already have a useful hierarchy; no need to invent another one
IMHO. This way I can switch DEBUG on/off for whole packages or just
single classes (and do not need to know, which logger this particular
class might use, it's the class name).

I do not expect Markers to be useful, or even visible, to end users
of applications, which use slf4j, if they do not insist to use this
feature.
For developers of components and tools used to build and run that
same application, they will probably help a lot, if they are easy to
use and configure.

As long as the ability to use a feature of the logging framework does
neither impose any effort on the END USER of an application, nor affects
its performance considarably, I think it's ok to have it.

Just my 0,02 €,

Heiner




More information about the slf4j-dev mailing list