[slf4j-dev] Re: TRACE level

[Ceki Gülcü]

Hello Jens,

Thank you for your comments.

Before adding TRACE, I would like to make sure that the TRACE level is
needed, because once it is added, it can't be taken back. Greg floated
the idea  of adding  trace() printing methods  in deprecated  mode, to
mitigate the  pain of migration  from JCL (for those  already invoking
the trace()  method). However, I think  it would be wiser  that we add
it, once and for all,  after we have convincingly established the need
for it.

You are clearly in favor of adding the TRACE level. Other users, most
notably Endre and Greg have asked for its addition. It would be easier
to succumb to the pressure and move on to other things. However, the
TRACE debate has been a catalyst for high quality discussions, as this
thread demonstrates.

There are two questions on my mind.

1) Is TRACE being used for good reasons?

2) Is TRACE being used because the existing APIs do not offer enough
expressive power?

It is probably easier to answer the first question because the second
is open-ended. So, let's focus on the first question if it's OK with
you.

As I am familiar with hibernate, let me quote you:

<jens>
   Or hibernate - almost the same thing, but they are even mixing
   developer info and end user infos into one level (info). So usually, an
   application programmatically disables the hibernate info/debug stuff,
   since the stuff is usually totally superfluous for the end user but also
   losses some "interesting" messages.
</jens>

In log4j, you can disable logging per class. What is preventing the
end user from disabling logs of level DEBUG in certain hibernate
classes and let other hibernate classes with "interesting" information
log at level DEBUG?

In the JBoss project, they use the TRACE level to *by* *default*
silence logs generated by certain classes. As by default log4j logs at
level DEBUG (its most verbose level), messages of level TRACE are
turned off by default. As I wrote in a previous message, the JBoss
developers could have logged their debug messages at level DEBUG (as
if DEBUG and TRACE were merged into DEBUG), and let the end user
disable DEBUG logs for the classes the user found uninteresting or too
chatty. Assuming what the end user finds chatty is similar to what the
JBoss developers find chatty, the end result would have been very
similar.

I would love to see code samples backing up your case. Do any pop up
to your mind in common-httpclient? Maybe in hibernate?  You mention
common-httpclient and hibernate as bad examples. Do you have example
of projects using the TRACE level as positive examples (examples to
follow)?

I am looking forward for your comments.

At 09:09 AM 7/7/2005, Jens Elkner wrote:
>Hi,
>
>I just found the new slf4j and thought, perhaps this time it is possible
>to get something with the trace() method (ie. I really miss this level
>in log4j).
>
>The marker stuff is a nice add on, but actually, how does one know,
>which markers are used in an application and especially where? Well,
>perhaps I'm a little outside of the circle when thinking on end users,
>but I think, making it easy for them as well, can't be fault.
>
>So, I really like Endre's perfect 5-level-hierarchy!
>
>What we see, not having a trace level, is that other levels are misused,
>which leads to the fact, that one tends e.g. to allow the logging of ERRORS,
>only. But doing this, one usually looses some WARNings/INFOs, which are
>important!
>
>Here some examples:
>
>FOP - very bad - I decided to programatically switch the level
>to FATAL, because all the logged stuff below FATAL is usually completely
>useless for an enduser.
>
>Or common-httpclient. I guess, since there is no real trace(), they used
>debug() for verbose output and info() for debug(). Usually almost everything
>logged in the info() level is IMHO developer info - i.e. nothing important
>for the enduser or anything, where the enduser can do something ...
>
>Or hibernate - almost the same thing, but they are even mixing developer
>info and enduser infos into one level (info). So usually, an application
>programatically disables the hibernate info/debug stuff, since the stuff
>is usually totaly superfluous for the enduser but also losses some
>"interesting" messages.
>
>IMHO, logging should be used in the first case, to support/inform the
>end user about important stuff or errors and in a manner, he can
>probably understand, and not to flood with information,
>which he does not understand (e.g. stacktraces) or takes im hours
>to read (which leads to ignorance again) nor he can do anything
>about it (actually I'm using log4j about 5 year and never put a stack
>trace into a level > DEBUG).
>
>In the second case, it should support the developer, to find defects.
>Here, at least some people, need at least to levels, one to roughly
>isolate the problem and sometimes a very verbose trace/info, to get
>the tricky details ...
>
>So I opt for the "simple and easy" way, i.e. Endre's perfect
>5-level-hierarchy.
>
>Regards,
>jens.
>--
>+---[ Jens Elkner ]--------------------------------------------------------+
>| Walther-Rathenau-Str. 58                 elkner at linofee.org              |
>| 39104 Magdeburg   GERMANY           http://www.linofee.org/~jel/         |
>+--------------------------------------------------------------------------+
>_______________________________________________
>dev mailing list
>dev at slf4j.org
>http://slf4j.org/mailman/listinfo/dev

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/