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
