I've just got to chime in here-- I've used Log4J for quite some time now and the one thing that has bothered me about it is its wonderful granularity during normal operations-- FATAL, ERROR, WARN, INFO; each provide for information of a particular nature, that nature is fairly obvious, and lesser important messages can be suppressed if you just don't care about it.
Unfortunately, only one exists when trying to troubleshoot problems- DEBUG. There have been many times that I've longed for one more level (e.g. TRACE or similar) that would allow for finer grained logging. The lack of this has caused me, on more than one occasion, to start using INFO for debugging information just because the quantity of information output during DEBUG would have a tendency to hide the jewels I'm looking. In one case, the difference would be between checking out a 250k log file vs 100M log file. There are times that the extra verbosity is needed, but not always. If it's not obvious, I'm very much for a TRACE level. rob hedin nds systems, lc ----- Original Message ----- From: "Jensen, Jeff" <[EMAIL PROTECTED]> To: "Log4J Users List" <[EMAIL PROTECTED]> Sent: Monday, September 22, 2003 7:22 PM Subject: RE: Plans for supporting a build in level of "trace" > -----Original Message----- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: Monday, September 22, 2003 10:59 AM > To: Log4J Users List > Subject: RE: Plans for supporting a build in level of "trace" > > > > Howdy, > > >To separate concerns. Because trace info is a specific level, more > minutia > >than debug info. > > That's your use-case, not mine. Both are debug for me. I never want > one without the other. theValue=... is useless if I don't know what > method it's in. Yes, both are debug info for me too. I want to turn off trace info when not needed to increase the clarity and value of the logs. Your statement: "theValue=... is useless if I don't know what method it's in" is irrelevant to the trace level argument. The issue exists for any logged message at any level. (The only solutions I know are to either define it in the ConversionPattern, prefix each message logged, or use NDC [which seems a little wrong to me] - how do you solve it?). So you (and others) are happy to overload the debug level. Others, including me, are not! That is too much info on one level. "That's your use case, not mine"! :-) > >3) People want it, it does not break backwards compatibility, and it > adds > >one more level of logging clarity. > > Convince me that a majority wants it. How come it doesn't > come up more > often on the log4j user list? Perhaps others are silent on it like me, who has used Log4J for a couple of years and has always missed it. In my current project, DEBUG messages containing trace info are sometimes deleted/commented out after awhile, when things are working well in that product section, possibly re-enabled when needed. This process goes against the crux of Log4j, even its "marketing": disable the level when not desired, don't delete/comment out code. OK FOLKS! Please email the list if you want it. Yoav said "Convince me that a majority wants it"! > As Paul said, this is an eternal debate, kind of like whether > to include > version numbers of a release in the jar file name. I half agree. I agree because usage of the logging levels is subject to interpretation. What each level means to one does not necessarily mean the same to another. However, I do see some consistency applied at my various clients. I disagree because tracing is a finer grained and different message type than debug. Hence my interpretation! Hence its difference name and different concept than a general debug message. I and others see it as a missing level to Log4j. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
