Shapira, Yoav wrote: >The reason I like the TRACE level as a standard is not because of the >above. It's because commons-logging expects it and JDK logging has it >(as FINE). I think the JDK logging levels of FINE, FINER, FINEST in >addition to the normal levels are completely overkill. But one TRACE >level is a good option to have > I would agree with this.
>. >I don't really agree with your use case though. You said you find >yourself having to add more detailed debug statements and then comment >them out. This is design-time and compile-time stuff. Would it be >accurate to say you only leave the "real" DEBUG-level statements in the >code when you ship to production? > I do not agree with this. Yes, some (1/3 to 1/2) of the "trace" debug statements are compile-time debugging and do not need to be in production code. I remove these from production code by defining a static DEBUG and surrounding such code with "if ( DEBUG )...", etc. The rest of my "trace" debug statements are things I do need to have included in production code. One example is SQL/JDBC debugging code in generally "silent" processes. When a user calls with a problem, I rerun the process on their system with DEBUG turned-on and get additional messages which better pinpoint the code that is generating the problem. For me, DEBUG provides an overview that often shows the problem. If the problem is still unclear, I rerun with (we'll call it) TRACE turned-on for the module with the problem and I get output of the SQL statements and detailed SQL exception output. Now I usually have enough information to pinpoint the data and/or database problem causing the problem. If / when I start out with TRACE turned on I am inundated with so much detail it is very hard to see the problem. I need to include both DEBUG and TRACE levels in the production code because the problem may be occuring on a distant machine, without source, with an out-of-date-but working version, etc. > >A big advantage of log4j is its small footprint and high speed. The >introduction of finer logging levels as part of the standard >distribution will encourage people to use these levels more. That in >turn will lead to slower run-time performance of these systems in >production, unless you are careful to take out all the TRACE-level >statements before shipping the product. And if you have to take out all >the TRACE-level statements before shipping, what use are they? ;) I >think the idea is if someone wants to really log things at a very fine >level, like the original poster in this thread, then they have to go >through some effort because this logging will slow down the system and >that's not something the log4j architects want to encourage... > > I find it hard to believe that having one additional standard level, TRACE, defined in log4j would significantly effect performance. I understand I would want to avoid over use of TRACE when seeking maximum performance. BUT I would like the ability to choose when ease of debugging and support is worth the performance hit. R.Parr Temporal Arts -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
