One other thing I would strongly encourage, purchase Ceki's book and read the section about wrapping Log4j. It is something that is encouraged, however Ceki strongly recommends not sub-classing logger. Use aggregation, as he describes in his book.
-----Original Message----- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2003 8:42 AM To: Log4J Users List Subject: RE: Adding an abstraction level Howdy, Not quite. Using isEnabledFor(Level l), e.g. isDebugEnabled() around logger.debug statements can significantly reduce logging overhead. You should read the log4j manual on this issue, as it contains a more complete explanation and benchmarks. As for your level of abstraction, which on this list we often refer to as a log4j wrapper: chances are you're not gaining much from it, but also not losing much in your case. I've seen worse wrappers suggested here, e.g. ones that do the Logger.getLogger(...) call each time -- that's terrible ;) Yoav Shapira Millennium ChemInformatics >-----Original Message----- >From: Jain, Siddharth (ODC - Satyam) [mailto:[EMAIL PROTECTED] >Sent: Friday, October 03, 2003 2:23 AM >To: Log4J Users List >Subject: RE: Adding an abstraction level > >Hi Jitesh, > >I really do not think this would help you, since there is a property known >as "threshold" in log4j, which specifies the minimum logging level, >thereby, >if you want that in certain deployment scenarios, or for certain appenders, >messages should be logged above a certain level, then just specify this >property to whatever level u want, because internally, log4j checks for the >the level being enabled or not. >I hope this helps you out. > >Cheers >Siddharth > > > -----Original Message----- >From: Jitesh_Arya [mailto:[EMAIL PROTECTED] >Sent: Friday, October 03, 2003 11:49 AM >To: Log4J Users List >Subject: Adding an abstraction level > > > > >Hi, this is my first mail to this mailing list and it's not been long since >I subscribed to it. So, please forgive if I sound really stupid putting >forth my question(s). >What we have done is we have added another level of abstraction between the >application (some web app) developer and the log4j. We have written another >class that imports log4j and other classes that are required for logging >and >written our own functions without any added functionality. That is, my >debug >will in turn >call log4j's debug method. Another thing that has been added is: the >isDebugEnabled () check before debug () of log4j is called. And similarly, >isEnabledfor(level) >for other levels. Now, my questions: >1) Is this added level of abstraction advisable? >2) Does the check before the call to log4j method serve any purpose >(here in my case) in reducing the cost? This (in normal cases, not here) >does prevent the cost of parameter construction when implemented in >application directly (this I understand). But here, the parameters will be >constructed, (so no savings on that side) when call is made to the debug () >or any other method that we have implemented. So, you see anything here >(diamond or just coal)? > >A heavy lot of thanks in ADVANCE:-) > >Regards, >Jitesh 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]
