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 [EMAIL PROTECTED] | | 39104 Magdeburg GERMANY http://www.linofee.org/~jel/ | +--------------------------------------------------------------------------+ _______________________________________________ dev mailing list [email protected] http://slf4j.org/mailman/listinfo/dev
-- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ _______________________________________________ dev mailing list [email protected] http://slf4j.org/mailman/listinfo/dev
