RE: Plans for supporting a build in level of "trace"
At 05:05 PM 9/24/2003 -0500, Jensen, Jeff wrote: Having a new domains feature solve the "fixed list of types" issue(s) sounds great. Hopefully it is "cross-dimensional" to coordinate not only a "priority/level" but a "functional area" as well. "Functional area". Exactly. > -Original Message- > From: Lutz Michael [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 24, 2003 4:50 PM > To: 'Log4J Users List' > Subject: RE: Plans for supporting a build in level of "trace" > > > > > Is there a location where "logging domains" are documented? > I'd really like to read about the concept(s). > > Thanks in advance. > > Mike > -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp import org.apache.Facetime; ApacheCon US 2003, 18-21 November http://apachecon.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plans for supporting a build in level of "trace"
There is no documentation on log4j domains yet. However, a short spec will be written before coding. Domains will have an impact on the inner architecture of log4j, so prior documentation should help with the coding. At 05:50 PM 9/24/2003 -0400, Lutz Michael wrote: Is there a location where "logging domains" are documented? I'd really like to read about the concept(s). Thanks in advance. Mike -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp import org.apache.Facetime; ApacheCon US 2003, 18-21 November http://apachecon.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plans for supporting a build in level of "trace"
Indeed! The pre-release "marketing bit" Ceki did was a nice little tease... ;-) "Logging minds want to know!" Having a new domains feature solve the "fixed list of types" issue(s) sounds great. Hopefully it is "cross-dimensional" to coordinate not only a "priority/level" but a "functional area" as well. > -Original Message- > From: Lutz Michael [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 24, 2003 4:50 PM > To: 'Log4J Users List' > Subject: RE: Plans for supporting a build in level of "trace" > > > > > Is there a location where "logging domains" are documented? > I'd really like to read about the concept(s). > > Thanks in advance. > > Mike > > > -Original Message- > From: Paul Smith [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 24, 2003 5:40 PM > To: Log4J Users List > Subject: Re: Plans for supporting a build in level of "trace" > > > On Thu, 2003-09-25 at 01:03, Larry Young wrote: > > Paul, > > > > Actually, based on our conversation back in > August, it works out > > better if you put the "trace" at the front of the class > name, that way you > > > still can specify package names and get everything > underneath it, and you > > can also turn on tracing without a package or class name. > For example, > > 'trace.com.acme.utils' would turn on tracing for all > classes under the > > utils package. That's a bit harder to do with 'trace' at the end. > > Thanks for refreshing my memory Larry, as I was writing it I tried to > remember our conversation, and got myself muddled. Must be lack of > coffee. > > I am excited by the new Domain concept that Ceki is developing, sounds > like it will solve a large number of logging issues. > > Paul > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > - > This message and any included attachments are from Siemens > Medical Solutions > USA, Inc. and are intended only for the addressee(s). > The information contained herein may include trade secrets or > privileged or > otherwise confidential information. Unauthorized review, > forwarding, printing, > copying, distributing, or using such information is strictly > prohibited and may > be unlawful. If you received this message in error, or have > reason to believe > you are not authorized to receive it, please promptly delete > this message and > notify the sender by e-mail with a copy to [EMAIL PROTECTED] > Thank you > > - > 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]
RE: Plans for supporting a build in level of "trace"
Is there a location where "logging domains" are documented? I'd really like to read about the concept(s). Thanks in advance. Mike -Original Message- From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 5:40 PM To: Log4J Users List Subject: Re: Plans for supporting a build in level of "trace" On Thu, 2003-09-25 at 01:03, Larry Young wrote: > Paul, > > Actually, based on our conversation back in August, it works out > better if you put the "trace" at the front of the class name, that way you > still can specify package names and get everything underneath it, and you > can also turn on tracing without a package or class name. For example, > 'trace.com.acme.utils' would turn on tracing for all classes under the > utils package. That's a bit harder to do with 'trace' at the end. Thanks for refreshing my memory Larry, as I was writing it I tried to remember our conversation, and got myself muddled. Must be lack of coffee. I am excited by the new Domain concept that Ceki is developing, sounds like it will solve a large number of logging issues. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- This message and any included attachments are from Siemens Medical Solutions USA, Inc. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plans for supporting a build in level of "trace"
On Thu, 2003-09-25 at 01:03, Larry Young wrote: > Paul, > > Actually, based on our conversation back in August, it works out > better if you put the "trace" at the front of the class name, that way you > still can specify package names and get everything underneath it, and you > can also turn on tracing without a package or class name. For example, > 'trace.com.acme.utils' would turn on tracing for all classes under the > utils package. That's a bit harder to do with 'trace' at the end. Thanks for refreshing my memory Larry, as I was writing it I tried to remember our conversation, and got myself muddled. Must be lack of coffee. I am excited by the new Domain concept that Ceki is developing, sounds like it will solve a large number of logging issues. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plans for supporting a build in level of "trace"
Paul, Actually, based on our conversation back in August, it works out better if you put the "trace" at the front of the class name, that way you still can specify package names and get everything underneath it, and you can also turn on tracing without a package or class name. For example, 'trace.com.acme.utils' would turn on tracing for all classes under the utils package. That's a bit harder to do with 'trace' at the end. --- regards --- Larry At 06:23 PM 9/23/03, you wrote: IMHO, the simplicity of Debug/info/warn/error/fatal is one of Log4j's strengths. I personally would not want Trace However, if I required Trace-style logging, I would simply log to a dotted logger name "---.trace". E.g If I have a component "com.mycompany.mycomponent", I have a complimentary "com.mycomany.mycomponent.trace" logger, and configure Log4j to suppress this logger under normal circumstances. The other advantage to this approach is that you can get all Trace style logs into their own appender very easily (attach the appropriate appender to each .trace logger in the config), which means my trace logs are separated easily from the other debug, which I think is what a lot of people are worried about. I can't see anyone wanting to wade through Trace AND Debug log messages to find things out, but maybe I can't see the use case that other people have. Having said all this, as a Log4j developer I wonder since we've previously made a lot of effort to match JDK 1.4's syntax (e.g. Category->Logger, Priority->Level), one might argue that it's not too much effort to go that extra mile to just add the Trace level for those that way inclined. Perhaps those log4j dev-people who were involved in the Log4j-JDK1.4 matching development might be able to comment on any rationale etc. But for me, I'm very happy with the current Trace-less log4j. Paul Smith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plans for supporting a build in level of "trace"
Although catering for user requests is one of the guiding principles behind this project, I feel that introducing the TRACE level would be a mistake. Log4j domains which will be soon introduced into log4j provide a much more powerful mechanism for categorizing logging statements. Please bear with me for a few more days. See also below. At 11:23 AM 9/24/2003 +1000, Paul Smith wrote: IMHO, the simplicity of Debug/info/warn/error/fatal is one of Log4j's strengths. I personally would not want Trace However, if I required Trace-style logging, I would simply log to a dotted logger name "---.trace". E.g If I have a component "com.mycompany.mycomponent", I have a complimentary "com.mycomany.mycomponent.trace" logger, and configure Log4j to suppress this logger under normal circumstances. Log4j domains are/will be your friend. The other advantage to this approach is that you can get all Trace style logs into their own appender very easily (attach the appropriate appender to each .trace logger in the config), which means my trace logs are separated easily from the other debug, which I think is what a lot of people are worried about. I can't see anyone wanting to wade through Trace AND Debug log messages to find things out, but maybe I can't see the use case that other people have. Did I mention log4j domains? Having said all this, as a Log4j developer I wonder since we've previously made a lot of effort to match JDK 1.4's syntax (e.g. Category->Logger, Priority->Level), one might argue that it's not too much effort to go that extra mile to just add the Trace level for those that way inclined. Perhaps those log4j dev-people who were involved in the Log4j-JDK1.4 matching development might be able to comment on any rationale etc. But for me, I'm very happy with the current Trace-less log4j. The idea was to be as friendly as possible to the JDK 1.4 users migrating to log4j from JDK 1.4 logging. As a whole, it was a good move although renaming priority to level was probably not worth the trouble. Once log4j 1.3 is introduced, developers will realize how much more advanced the log4j API is compared to JDK 1.4 logging. Paul Smith -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp import org.apache.Facetime; ApacheCon US 2003, 18-21 November http://apachecon.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plans for supporting a build in level of "trace"
I agree, adding a TRACE level would make debugging easier. As FATAL and ERROR are both about errors, DEBUG should have a more detailed level. --- Robert Hedin <[EMAIL PROTECTED]> escreveu: > 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] > = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plans for supporting a build in level of "trace"
IMHO, the simplicity of Debug/info/warn/error/fatal is one of Log4j's strengths. I personally would not want Trace However, if I required Trace-style logging, I would simply log to a dotted logger name "---.trace". E.g If I have a component "com.mycompany.mycomponent", I have a complimentary "com.mycomany.mycomponent.trace" logger, and configure Log4j to suppress this logger under normal circumstances. The other advantage to this approach is that you can get all Trace style logs into their own appender very easily (attach the appropriate appender to each .trace logger in the config), which means my trace logs are separated easily from the other debug, which I think is what a lot of people are worried about. I can't see anyone wanting to wade through Trace AND Debug log messages to find things out, but maybe I can't see the use case that other people have. Having said all this, as a Log4j developer I wonder since we've previously made a lot of effort to match JDK 1.4's syntax (e.g. Category->Logger, Priority->Level), one might argue that it's not too much effort to go that extra mile to just add the Trace level for those that way inclined. Perhaps those log4j dev-people who were involved in the Log4j-JDK1.4 matching development might be able to comment on any rationale etc. But for me, I'm very happy with the current Trace-less log4j. Paul Smith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plans for supporting a build in level of "trace"
Bill, I believe there is a plan in place to do this with some kind of "logging context" in a future release. I'm not part of the dev list, so I don't know that for a fact, but it is my understanding from various responses to some problems that I had early on with these issues. My biggest issue is that I don't agree with the forced relationship between Levels, especially when you add additional Levels to the standard package. Why is "trace" higher or lower than "debug" or "info"? I don't agree that this is a fixed relationship, it depends on the circumstances. Then you add additional Levels (DB Access, Timing, etc) and it gets even muddier. I think you are right, there is a dual notion of what a Level is. It is used for both turning on/off logging (with an implied relationship between the various Levels) and also to define the type of info being logged. For my purposes, I've created something like what you describe by wrapping the Logger class to remove the entire concept of Levels and replaced it with a LogType concept. Now, I can turn on/off logging for any particular LogType totally independent of any other LogType, because there is no inherent relationship between them. The nice part is that if I choose to have a relationship between them I can, but the Logging class doesn't make that assumption, that's up to the LogType to decide if it is "enabled". So in my config file I select what Type of info I want logged, not the Level (and its related Levels). Unfortunately, I didn't have the time to rewrite the Logger class to replace Levels (Levels and their implied relationships are embedded pretty deep in log4j), so I used a "poor-man's" context by prefixing each logger's "class name" with a "log type" name, which gives me roughly the same outcome (i.e. turning logging on/off by type instead of by group which is how levels work), albeit a bit ugly in the config file. Happily, the Java code is unaware because the wrapper does all the translation work. Probably the biggest problem I can see with this approach is that it's not exactly compatible with Java 1.4 Logging, which in my case doesn't bother me because I don't think logging belongs in the language anyhow! :) --- regards --- Larry At 04:52 PM 9/23/03, you wrote: It seems obvious enough why there is wide disagreement on how to use the existing levels and/or whether more levels are needed. People are trying to cram selectively enabled logging into log4j's strict hierarchical logging scheme. What I think mos people want is some reasonable way of saying how much logging they want (and the current scheme is fine for that) along with saying what kind of information they want logged (the current scheme is lousy for that). What folks probably want for the latter is the ability to turn on and off some selection of "items of interest". I'm sure many people independently do this outside of log4j. I don't know if it would be easy / reasonable / worthwhile to have some facility inside log4j that implemented the same idea. You might be able to cook up some "items of interest" that were interesting to many development efforts, but there would certainly be unique elements that folks would want to use to supplement that. -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plans for supporting a build in level of "trace"
It seems obvious enough why there is wide disagreement on how to use the existing levels and/or whether more levels are needed. People are trying to cram selectively enabled logging into log4j's strict hierarchical logging scheme. What I think mos people want is some reasonable way of saying how much logging they want (and the current scheme is fine for that) along with saying what kind of information they want logged (the current scheme is lousy for that). What folks probably want for the latter is the ability to turn on and off some selection of "items of interest". I'm sure many people independently do this outside of log4j. I don't know if it would be easy / reasonable / worthwhile to have some facility inside log4j that implemented the same idea. You might be able to cook up some "items of interest" that were interesting to many development efforts, but there would certainly be unique elements that folks would want to use to supplement that. -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plans for supporting a build in level of "trace"
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]
RE: Plans for supporting a build in level of "trace"
How would we use this component? Would it be a full replacement for the standard distribution, or an adder jar? I imagine a full replacement, but one must not assume...:-) I would expect it to be the same version as the standard release with the one file difference. Awareness and Convenience: In my experience, most people are not aware of the sandbox, and do not care to use it even if they are aware of it (lazy? cannot use the non-standard version? etc.). This means it will not "rise to the download count" you would want to see to prove its usefulness and usage, or lack thereof. > -Original Message- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: Monday, September 22, 2003 11:53 AM > To: Log4J Users List > Subject: RE: Plans for supporting a build in level of "trace" > > > Hypothetically speaking, let's say there was a log4j sandbox > jar with a > Level class replacement that includes a TRACE (and maybe FINE, FINER, > FINEST, REALLY_FINEST, ABSOLUTELY_FINEST, > IT_CANT_GET_ANY_FINER, etc ;) > -- just kidding) level, would that be useful for people? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plans for supporting a build in level of "trace"
> -Original Message- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: Monday, September 22, 2003 11:03 AM > To: Log4J Users List > Subject: RE: Plans for supporting a build in level of "trace" > > > > Howdy, > > >I agree that this debate will carry on forever, because we all work > >differently. I believe having one trace level is good > compromise. The > >way I work is to put debug statements into the code to > decipher what is > >happening in the program flow, but I would love to have a trace level > to > >print out parameter values or variable values. The debug level gets > >extremely verbose when logging out array values etc and all you are > >interested in is program flow. > > Interesting that the above is exactly the opposite of what Jeff's > use-case is: trace for entering/exiting methods, debug for variable > values ;) Possibly, but the salient point is it is another use-case for having TRACE! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
RE: Plans for supporting a build in level of "trace"
It would be for jboss folks...they use a custom trace level. I've already created a custom level (although it's probably not perfect) for providing support for jdk1.4 util.logging-generated events (and their levels) in Chainsaw v2. See http://cvs.apache.org/viewcvs/jakarta-log4j/src/java/org/apache/log4j/Ut ilLoggingLevel.java?rev=1.1&content-type=text/vnd.viewcvs-markup. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2003 10:37 AM To: Log4J Users List Subject: RE: Plans for supporting a build in level of "trace" Hypothetically speaking, let's say there was a log4j sandbox jar with a Level class replacement that includes a TRACE level, would that be useful for people? ---> Should do.. as long as the sandbox stays compatible with future versions of log4J. Shuchi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plans for supporting a build in level of "trace"
Hypothetically speaking, let's say there was a log4j sandbox jar with a Level class replacement that includes a TRACE level, would that be useful for people? ---> Should do.. as long as the sandbox stays compatible with future versions of log4J. Shuchi
RE: Plans for supporting a build in level of "trace"
Howdy, >It does not really matter what TRACE level gets used for. Each development >team / organization will have their interpretation of it depending on how >they intend to use the information logged at both levels. I agree, it doesn't matter what it's used for, only if it's used at all. >More importantly - having a level more verbose than DEBUG is very handy. We Very handy for you. >1. TRACE level >2. An extension of DailyRollingFileAppender that also uses filesize as a >rolling criterion >3. MBeans support Would you consider 2 and 3 as important to the core of log4j as 1 above? Clearly you think 1 belongs in the native log4j core. The point I'm making is not as much about the TRACE level per se. I know some people want it and use it. It's about adding a feature to the core of a product where: - It's not clear how useful the feature is, and - It's not clear what the backwards compatibility implications are, especially for organizations that already have their own custom TRACE level (or other levels that go between DEBUG and OFF). Hypothetically speaking, let's say there was a log4j sandbox jar with a Level class replacement that includes a TRACE (and maybe FINE, FINER, FINEST, REALLY_FINEST, ABSOLUTELY_FINEST, IT_CANT_GET_ANY_FINER, etc ;) -- just kidding) level, would that be useful for people? Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plans for supporting a build in level of "trace"
It does not really matter what TRACE level gets used for. Each development team / organization will have their interpretation of it depending on how they intend to use the information logged at both levels. More importantly - having a level more verbose than DEBUG is very handy. We are planning to use log4J and are building the following features into our logging wrapper : 1. TRACE level 2. An extension of DailyRollingFileAppender that also uses filesize as a rolling criterion 3. MBeans support Shuchi Mittal Strategic Technology Engineer [EMAIL PROTECTED] Phone: 678-375-3113 The #1 Way to Pay Online http://www.checkfree.com/paybillsonline
RE: Plans for supporting a build in level of "trace"
Howdy, >I agree that this debate will carry on forever, because we all work >differently. I believe having one trace level is good compromise. The >way I work is to put debug statements into the code to decipher what is >happening in the program flow, but I would love to have a trace level to >print out parameter values or variable values. The debug level gets >extremely verbose when logging out array values etc and all you are >interested in is program flow. Interesting that the above is exactly the opposite of what Jeff's use-case is: trace for entering/exiting methods, debug for variable values ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plans for supporting a build in level of "trace"
Hi, I agree that this debate will carry on forever, because we all work differently. I believe having one trace level is good compromise. The way I work is to put debug statements into the code to decipher what is happening in the program flow, but I would love to have a trace level to print out parameter values or variable values. The debug level gets extremely verbose when logging out array values etc and all you are interested in is program flow. Andreas -Original Message- From: Lutz Michael [mailto:[EMAIL PROTECTED] Sent: Monday, 22 September 2003 17:49 To: 'Log4J Users List' Subject: RE: Plans for supporting a build in level of "trace" This topic is a source of endless debate where I work. We have groups that actually separate "event logging" from "tracing", and support about 5 levels of each. So, instead of just 1 trace level, they use 5 different levels of tracing. I doubt the end of this debate will ever be reached with consensus. My opinion - I like to keep things simple, and thus 1 level of debug is fine for me, but I have heard people argue successfully for additional levels. For instance, 1 level of debugging that operations may be able to understand, a lower level that developers understand without source code in front of them, and an even lower level of tracing that requires source code in front of a developer. The debate rages on ... the addition of a single trace level might be a reasonable compromise. This will also incur change in a lot of documentation - these levels are documented in a lot of places. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2003 11:42 AM To: Log4J Users List Subject: RE: Plans for supporting a build in level of "trace" Howdy, >"TRACE" or "FINE" is one that many seem to agree is sensible and required. That's the part I'm not convinced of. How do you support the above? >I think the idea is, no matter how many or few default levels there are, >the defaults should cover the range of the "logging space" completely. >FATAL pretty much covers it on one end of the spectrum. >On the other end we need a logging level whose messages would be so >verbose and so often called that we would almost never need a finer level. >DEBUG is too general purpose for that. I disagree, think DEBUG is fine for the other end of the spectrum, and wouldn't use something lower than that. However, if there's really an overwhelming majority of people who disagree, then by definition I'm in the minority and these levels should be added ;) But I'm yet to be convinced this is the case... Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- This message and any included attachments are from Siemens Medical Solutions USA, Inc. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] NOTE: This e-mail message is subject to the MTN Group disclaimer see http://www.mtn.co.za/email_disclaimer.asp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. >Having TRACE in Log4j means: >1) No requirement to extend Log4j on each project; it is an intrinsic >logging type. No such requirement exists in any organization I've ever worked, people use debug-level statement without extending log4j. People who use JDK 1.4 don't use the trace level. But that's only my experience, which is no less or more meaningful than anyone else's. >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? >4) It matches levels with commons-logging. Why does it have trace? ;-) SOLELY because JDK 1.4 has it and commons-logging was designed to map to both log4j and commons-logging (among other logging kits). As Paul said, this is an eternal debate, kind of like whether to include version numbers of a release in the jar file name. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plans for supporting a build in level of "trace"
This topic is a source of endless debate where I work. We have groups that actually separate "event logging" from "tracing", and support about 5 levels of each. So, instead of just 1 trace level, they use 5 different levels of tracing. I doubt the end of this debate will ever be reached with consensus. My opinion - I like to keep things simple, and thus 1 level of debug is fine for me, but I have heard people argue successfully for additional levels. For instance, 1 level of debugging that operations may be able to understand, a lower level that developers understand without source code in front of them, and an even lower level of tracing that requires source code in front of a developer. The debate rages on ... the addition of a single trace level might be a reasonable compromise. This will also incur change in a lot of documentation - these levels are documented in a lot of places. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2003 11:42 AM To: Log4J Users List Subject: RE: Plans for supporting a build in level of "trace" Howdy, >"TRACE" or "FINE" is one that many seem to agree is sensible and required. That's the part I'm not convinced of. How do you support the above? >I think the idea is, no matter how many or few default levels there are, >the defaults should cover the range of the "logging space" completely. >FATAL pretty much covers it on one end of the spectrum. >On the other end we need a logging level whose messages would be so >verbose and so often called that we would almost never need a finer level. >DEBUG is too general purpose for that. I disagree, think DEBUG is fine for the other end of the spectrum, and wouldn't use something lower than that. However, if there's really an overwhelming majority of people who disagree, then by definition I'm in the minority and these levels should be added ;) But I'm yet to be convinced this is the case... Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- This message and any included attachments are from Siemens Medical Solutions USA, Inc. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plans for supporting a build in level of "trace"
Hi Yoav,
To separate concerns. Because trace info is a specific level, more minutia than debug
info.
For example:
private SomeClass someMethod(String anArg)
{
LOG.trace("begin");
SomeClass theValue = null;
//do some processing and get theValue
//possibly some other LOG.debug() or info calls
LOG.debug("theValue=" + theValue);
LOG.trace("end");
return theValue;
}
Having TRACE in Log4j means:
1) No requirement to extend Log4j on each project; it is an intrinsic logging type.
2) Enables better log management with the standard product - separating execution
trace info from debug info, so when desiring debug level but not trace, the log is not
filled with the trace messages (which is voluminous).
3) People want it, it does not break backwards compatibility, and it adds one more
level of logging clarity.
4) It matches levels with commons-logging. Why does it have trace? ;-)
5) Developer can do LOG.trace(msg) vs LOG.log(CustomPriority.TRACE, msg);
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2003 9:59 AM
To: Log4J Users List
Subject: RE: Plans for supporting a build in level of "trace"
Howdy,
Why?
Yoav Shapira
Millennium ChemInformatics
>-Original Message-
>From: Jensen, Jeff [mailto:[EMAIL PROTECTED]
>Sent: Monday, September 22, 2003 10:45 AM
>To: Log4J Users List
>Subject: RE: Plans for supporting a build in level of "trace"
>
>I also have wanted a TRACE level supported in Log4j for quite awhile.
I
>hope it is added soon...
>
>
>-Original Message-
>From: Dennis Cook [mailto:[EMAIL PROTECTED]
>Sent: Saturday, September 20, 2003 8:24 PM
>To: [EMAIL PROTECTED]
>Subject: Plans for supporting a build in level of "trace"
>
>
>I have been using the commons-logging package with JDK1.4 for a while
>now and just tried plug in the log4j package. The application is
>making use of the the commons-logging "debug" and "trace" levels. But
>in log4j they both print out as DEBUG level. Does anyone know if
>support "trace" will be added to future versions of 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]
This e-mail, including any attachments, is a confidential business communication, and
may contain information that is confidential, proprietary and/or privileged. This
e-mail is intended only for the individual(s) to whom it is addressed, and may not be
saved, copied, printed, disclosed or used by anyone else. If you are not the(an)
intended recipient, please immediately delete this e-mail from your computer system
and notify the sender. Thank you.
-
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]
RE: Plans for supporting a build in level of "trace"
Howdy, >"TRACE" or "FINE" is one that many seem to agree is sensible and required. That's the part I'm not convinced of. How do you support the above? >I think the idea is, no matter how many or few default levels there are, >the defaults should cover the range of the "logging space" completely. >FATAL pretty much covers it on one end of the spectrum. >On the other end we need a logging level whose messages would be so >verbose and so often called that we would almost never need a finer level. >DEBUG is too general purpose for that. I disagree, think DEBUG is fine for the other end of the spectrum, and wouldn't use something lower than that. However, if there's really an overwhelming majority of people who disagree, then by definition I'm in the minority and these levels should be added ;) But I'm yet to be convinced this is the case... Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plans for supporting a build in level of "trace"
Better question:
Why have any level's implemented?
Probably because it's useful to have sensible default implementations.
"TRACE" or "FINE" is one that many seem to agree is sensible and required.
I think the idea is, no matter how many or few default levels there are,
the defaults should cover the range of the "logging space" completely.
FATAL pretty much covers it on one end of the spectrum.
On the other end we need a logging level whose messages would be so
verbose and so often called that we would almost never need a finer level.
DEBUG is too general purpose for that.
-Mark
"Shapira, Yoav"
<[EMAIL PROTECTED]To: "Log4J Users List" <[EMAIL
PROTECTED]>
.com>cc:
Subject: RE: Plans for supporting a
build in level of "trace"
09/22/03 10:58 AM
Please respond to
"Log4J Users
List"
Howdy,
Why?
Yoav Shapira
Millennium ChemInformatics
>-Original Message-
>From: Jensen, Jeff [mailto:[EMAIL PROTECTED]
>Sent: Monday, September 22, 2003 10:45 AM
>To: Log4J Users List
>Subject: RE: Plans for supporting a build in level of "trace"
>
>I also have wanted a TRACE level supported in Log4j for quite awhile.
I
>hope it is added soon...
>
>
>-Original Message-----
>From: Dennis Cook [mailto:[EMAIL PROTECTED]
>Sent: Saturday, September 20, 2003 8:24 PM
>To: [EMAIL PROTECTED]
>Subject: Plans for supporting a build in level of "trace"
>
>
>I have been using the commons-logging package with JDK1.4 for a while
>now and just tried plug in the log4j package. The application is
>making use of the the commons-logging "debug" and "trace" levels. But
>in log4j they both print out as DEBUG level. Does anyone know if
>support "trace" will be added to future versions of 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]
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential,
proprietary and/or privileged. This e-mail is intended only for the
individual(s) to whom it is addressed, and may not be saved, copied,
printed, disclosed or used by anyone else. If you are not the(an) intended
recipient, please immediately delete this e-mail from your computer system
and notify the sender. Thank you.
-
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]
RE: Plans for supporting a build in level of "trace"
Howdy, Why? Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Jensen, Jeff [mailto:[EMAIL PROTECTED] >Sent: Monday, September 22, 2003 10:45 AM >To: Log4J Users List >Subject: RE: Plans for supporting a build in level of "trace" > >I also have wanted a TRACE level supported in Log4j for quite awhile. I >hope it is added soon... > > >-Original Message- >From: Dennis Cook [mailto:[EMAIL PROTECTED] >Sent: Saturday, September 20, 2003 8:24 PM >To: [EMAIL PROTECTED] >Subject: Plans for supporting a build in level of "trace" > > >I have been using the commons-logging package with JDK1.4 for a while >now and just tried plug in the log4j package. The application is >making use of the the commons-logging "debug" and "trace" levels. But >in log4j they both print out as DEBUG level. Does anyone know if >support "trace" will be added to future versions of 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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plans for supporting a build in level of "trace"
I also have wanted a TRACE level supported in Log4j for quite awhile. I hope it is added soon... -Original Message- From: Dennis Cook [mailto:[EMAIL PROTECTED] Sent: Saturday, September 20, 2003 8:24 PM To: [EMAIL PROTECTED] Subject: Plans for supporting a build in level of "trace" I have been using the commons-logging package with JDK1.4 for a while now and just tried plug in the log4j package. The application is making use of the the commons-logging "debug" and "trace" levels. But in log4j they both print out as DEBUG level. Does anyone know if support "trace" will be added to future versions of 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]
Plans for supporting a build in level of "trace"
I have been using the commons-logging package with JDK1.4 for a while now and just tried plug in the log4j package. The application is making use of the the commons-logging "debug" and "trace" levels. But in log4j they both print out as DEBUG level. Does anyone know if support "trace" will be added to future versions of log4j? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
