logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Bush <dan.b...@gmail.com>
Subject Possible API Performance and Usability Enhancement
Date Mon, 29 Aug 2005 19:14:33 GMT
I have been recompiling log4j locally for years now to overload the
logging signature so I can take advantage of java.text.MessageFormat
and embed the isXXXEnabled check. Below I have detailed out what I am
doing but, I would like to know if it is something that could be
incorporated into the framework and if so how do I go about submitting

Suppose you have this complex customer information object. Through
configuring the logging level, you can avoid the overhead to the
filing system but, it seams silly to still have to eat the toString
overhead unless you wrap isXXXEnabled() around it:
CustomerInformation ci = new CustomerInformation();



This is ok but even when the logging level is adjusted to avoid the
logging, ci is still toString() ed which translates to unnecessary
string tomfoolery. Depending the object and the toString()
implementation this can get far uglier. Image you are using a dynamic
bean style driven toString() utility routine or the object is a
composit ...


if (logger.isDebugEnabled()) {

This avoids the toString() overhead(for DEBUG) overhead but, it messy
when used at scale.


logger.debug("ci:[{0}]", ci);

Here I am using a wrapper method which does the isDebugEnabled()
within and then java.text.MessageFormat.format(String pattern, 
Object[] arguments) if necessary. Of course I over load the signature
for convenience as well. For example debug:

debug(String message, Object [])
debug(String message, Object obj0)
debug(String message, Object obj0, Object obj1)
debug(String message, Object obj0, Object obj1, Object obj2)

Throwable ...

- Dan

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message