logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Suggestion - 1.3 API, Logger method signatures
Date Mon, 11 Dec 2006 21:13:00 GMT

On Dec 11, 2006, at 8:22 AM, Morten Hattesen wrote:

> Hi,
> The Log4J 1.3 API changes to the org.apache.log4j.Logger API was
> changed to allow the use of use message patterns
> http://logging.apache.org/log4j/docs/api-1.3/org/apache/log4j/ 
> Logger.html
> This was obviously done do avoid excessive string concatenation by the
> compiler when calling a logging method, as well as to make the code
> more legible.
> Example (log4j 1.2 api):
>    logger.debug("Fetching data for " + user.name + " from database");
> ... may be expressed like so in log4j 1.3:
>    logger.debug("Fetching data for {0} from database", user.name);
> As a side effect it is no longer as essential to wrap calls to logging
> methods in a conditional ...
>    if (logger.isDebugEnabled) {
>        logger.debug(...);
>    }
> ... since the string concatenation overhead is now not incurred unless
> the logging actually takes place.
> However, what surprises me, is that the API only supports 1 and 2
> argument messages, and that message pattern is not supported at all
> when passing a throwable.
> I can see a point in allowing a single argument convenience method
> signature, e.g.:
>    public void debug(Object messagePattern, Object arg);
> But to support multiple (2 or more) arguments (using JRE 1.2), an
> Object array should be used, e.g:
>    public void debug(Object messagePattern, Object[] args);
> In other words, I suggest that all the two-argument methods of
> org.apache.log4j.Logger (and its deprecated super classes) should be
> removed, e.g:
>    public void xxxx(String messagePattern, Object arg1, Object arg2);
> ... and replaced by ...
>    public void xxxx(String messagePattern, Object[] args);
> Also, I feel that in order to keep the 1.3 API "clean" the logging
> methods that take a throwable argument should be overloaded with
> message pattern arguments, too, e.g.
>    public void trace(Object messagePattern, Object arg, Throwable t);
>    public void trace(Object messagePattern, Object[] args,  
> Throwable t);
> Can I please get some views on this subject from other Log4J users,
> before submitting it formally to the developers' list.
> Regards,
> Morten Hattesen

I have several problems with the approach that was used with the  
log4j 1.3 parameterized logging methods:

- Uses a formatting syntax that is similar to, but not compatible  
with, java.text.MessageFormat.

- Enshrines one particular message formatting syntax, when the JDK  
provides multiple formatters (java.text.MessageFormat and  

- Requires "boxing" of primitive types prior to the logging call and  
the associated overhead

- Mixes the concerns of formatting with logging.

The formatter project in the log4j sandbox is an alternative approach  
that preserves the performance goals of the original work while  
addressing those issues.  Plus it also works with log4j 1.2.

Basically, the formatter project offers three utility classes, LogMF,  
LogF and LogSF which are used to for parameterized logging using  
java.text.MessageFormat, java.util.Formatter and a syntax compatible  
with the log4j 1.3 formatter.   A log4j 1.3 parameterized request  
such as:

  logger.debug("Fetching data for {} from database", user.name);

could be written as any of the following:

LogMF.debug(logger, "Fetching data for {0} from database", user.name);
LogF.debug(logger, "Fetching data for %s from database", user.name);
LogSF.debug(logger, "Fetching data for {} from database", user.name);

The problem with just having an Object[] method is that you then  
incur a array creation cost even if the logging request does not  
satisfy the threshold condition.  That is if you do:

logger.debug("Fetching data from {} from domain {}, new Object[]  
{ user.name, user.domain });

You still have the cost of the new Object[] even if the logger's  
threshold is INFO or higher.  The LogMF et al classes would defer  
array creation until after the condition is checked.

See http://marc.theaimsgroup.com/?l=log4j-dev&m=113704872508753&w=2  
for the original announcement.  There wasn't much feedback at the  
time of the announcement, but sounds like you might be interested.  I  
know that there needs to be a minor change to the implementations to  
get class and line numbers properly reported, but that would not  
affect the API.

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

View raw message