logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Deboy" <sde...@comotivsystems.com>
Subject RE: Experimental log4j formatter in sandbox
Date Thu, 12 Jan 2006 20:33:36 GMT
General SLF4j concern:

I may be in the minority (I'm sure I am), but slf4j's change to require logger.debug(string)
instead of object may have a performance rationale but it has the effect of preventing filters
from being able to perform any analysis based on what was passed into the logging method.

See http://logging.apache.org/log4j/docs/api-unstable/org/apache/log4j/filter/ReflectionFilter.html

To work around this issue, we could add additional methods to logger that took an interface
as well as a String, and users would pass in instances of the interface (which provided a
way to get the underlying object and delegated tostring to the underlying object if the filter
wasn't being used).  Maybe a Wrapper interface that provided a getObject method.

Overkill?  Probably.  But Strings are pretty limiting.  Folks interested in writing filters
that understood the object type (instrumentation, etc) would have their hands tied without
something like this.

Scott Deboy
111 SW Columbia Street Ste. 950
Portland, OR  97201

Telephone:      503.224.7496
Cell:           503.997.1367
Fax:            503.222.0185



-----Original Message-----
From: Ceki Gülcü [mailto:ceki@qos.ch]
Sent: Thu 1/12/2006 7:47 AM
To: Log4J Developers List
Subject: Re: Experimental log4j formatter in sandbox
At 07:51 AM 1/12/2006, Curt Arnold wrote:
>I committed a pass at external message formatting classes in the
>sandbox.  The code can be checked out using:
>svn co http://svn.apache.org/repos/asf/logging/sandbox/log4j/ formatter 
>and can be built using either Maven (JDK 1.5 only) or Ant.  The Ant
>build can produce both a JDK 1.5 compatible jar (build with ant jar
>or mvn jar:jar) which supports varargs and the java.util.Formatter
>formatter and a (hopefully) JDK 1.3 compatible jar (build with ant
>jar-java2) which substitutes Object[] for Object... and omits support
>for the java.util.Formatter.  The formatter was built and tested with
>log4j 1.2.13 (latest in Maven) and should work with earlier log4j
>1.2.x (may throw MethodNotFound exceptions if trace() methods are
>used with pre-TRACE enabled log4j's) and log4j 1.3.
>log4j 1.3, SLF4J and NLOG4J provide methods that take a substitution
>pattern and one or more parameters used to form the message where the
>substitution is only performed if the logger threshold is satisfied.
>For example:
>logger.debug("The {} jumped over the moon {} times", "cow", new
>One of my concerns was introducing yet another pattern syntax when
>Java class libraries already have two (java.text.MessageFormat and
>java.util.Formatter).  I had originally thought that the substitution
>pattern format was a subset of that supported by
>java.text.MessageFormat, however java.text.MessageFormat would
>require parameter numbers within the braces (for example, "The {0}
>jumped over the moon {1} times").
>Instead of enshrining one pattern syntax, the external formatters
>provide three different utility classes with identical methods that
>each use a different formatter.  The class names are short since a
>previous concern with this approach was code bloat.  All the classes
>are (currently) in org.apache.log4j.formatter.  They are:

What is wrong with enshrining a solution that is optimized for the
task at hand by being simple, easy to use and CPU effective? What
advantages are there for your approach which offers 3 distinct
solutions without committing to any of them? By the way, an end-user
can always implement the LogF or LogMF approach independently of what
log4j 1.3 offers in agreement with the SLF4J API. Put differently, the
LogF and LogMF code can always be implemented as a static utility
class on top of log4j if need be. However, by being aligned with
SLF4J, log4j offers a stable solution and freedom of choice to its

Curt has expressed reservations regarding the SLF4J approach.  Are
there any other developers who are uneasy with the SLF4J approach? If
my memory serves me correctly, Paul Smith expressed interest in the
SLF4J approach. Are there any others?

>LogF - uses java.util.Formatter (name should invoke fond memories of
>LogMF - uses java.text.MessageFormat (adds M for Message)
>LogSF - uses existing log4j 1.3 syntax (adds S for Simple)
>The previous line could be written as:
>LogF.debug(logger, "The %s jumped over the moon %d times", "cow", 5);
>LogMF.debug(logger, "The {0} jumped over the moon {1} times", "cow", 5);
>LogSF.debug(logger, "The {} jumped over the moon {} times", "cow", 5);
>The primary design goal was to minimize the cost of ineffective log
>requests by deferring the cost of formatting, parameter boxing and
>array creation until after the isEnabledFor() is checked.  The cost
>of formatting, boxing and array creation is assumed to be small
>compared to the append cost and there has been no attempt to optimize
>those costs when the threshold is satisfied.  No performance
>evaluation has been attempted yet and the assumptions need to be

The assumption is largely correct except that the formatting cost
should not be prohibitive compared to the cost of appending. Given its
simplicity, the SLF4J approach is designed from the ground up to
ensure optimal performance for this particular case.

>I assume the JVM will be able to effectively "in-line" the body of
>the method calls so that:
>LogMF.debug(logger, "The {0} jumped over the moon {1} times", "cow", 5);
>results in code that is nearly indistinguishable in performance from:
>if (logger.isDebugEnabled()) {
>    logger.debug(MessageFormat.format("The {0} jumped over the moon
>{1} times", new Object[] { "cow", new Integer(5) }));
>It is possible that the Java 5 JVM is smart enough to defer boxing
>and array creation in the vararg logging methods resulting in no
>performance benefit from the non-vararg methods.  In that case, then
>all of the non-vararg methods could be eliminated from LogF since it
>only exists in the JDK 1.5.  Probably would want to still support
>them for the other formatters to preserve calling compatibility
>between the JDK 1.3+ and the JDK 1.5 implementations of the formatters.
>Unlike the log4j 1.3 and SLF4J implementations, the LogSF will
>support more than 2 substitution parameters.

The current log4j 1.3 implementation supports 1 or 2 parameters.
The SLF4J implementation supports any number of parameters.

>The implementation is
>different and may need to be tweaked to exactly reproduce the log4j
>1.3 and SLF4J behavior.  For example, LogSF doesn't attempt to
>provide any escaping mechanism to allow "{}" to appear in a
>message.   I'm not sure if log4j 1.3 or SLF4J do.

Both log4j 1.3 and SLF4J allow "{}" to be escaped. This is easy to
verify by looking at org.slf4j.impl.MessageFormatter present in both
SLF4J and log4j 1.3.

for more details. Unfortunately, SLF4J support was recently removed. I
would like to see it restored. I can personally vouch that keeping
NLOG4J in sync with SLF4J is almost effortless, especially since the
SLF4J is now quite stable. Unless there is opposition, I'd like to
take the initiative to restore native SLF4J support in 1.3.

Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/

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

View raw message