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
java.util.Formatter)
- 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
