logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Log4j2 Message Formatting (was Re: [Vote] Log4j 2.0-alpha1 rc1)
Date Sun, 15 Jul 2012 15:27:29 GMT
Changing the topic since this discussion isn't really related to the release vote.

On Jul 15, 2012, at 7:36 AM, Gary Gregory wrote:

> On Sun, Jul 15, 2012 at 10:13 AM, Ralph Goers <ralph.goers@dslextreme.com> wrote:
> On Jul 15, 2012, at 6:36 AM, Gary Gregory wrote:
>> Hi All:
>> I've only now been able to take a peek at v2 in SVN so... sorry for the late email
but I feel better late than never.
>> With log4j 1.2, my usage pattern is:
>> logger.debug(String.format("This %s and that %d on this day %1$tm %1$te,%1$tY", this,
this.getThat(), this.getCalendar()));
>> In 2.0, we have this example:
>> logger.debug("Logging in user {} with id {}", user.getName(), user.getId());
>> Why invent a new syntax when String.format is baked into the JRE? 
> Because you are doing the string formatting whether the log event will be logged or not,
which means your logger.debug should always be wrapped in an if isDebugEnabled.  Also, the
current syntax is compatible with SLF4J. See http://www.slf4j.org/faq.html#logging_performance.
> Good discussion :)
> Yes, of course, I left the if/is* code out for brevity, it is not the point of my discussion.
I plan on leaving my if/is code in place even if/when I move to log4j 2.0, it's just faster
to call one API with no args than the alternative. ;)
> I'm baffled by the SLF4J comment.

Because SLF4J is now widely adopted as a standard Logging API. Efficiently supporting what
it does out of the box is a good thing IMO.

> I am a log4j 1.2 user, and I want to move to 2.0, so I have to learn the SLF4J syntax
instead of what is baked in the JRE to use this great new feature? Bleh. That seems backwards
to me. If we are trying to get people to migrate from SLF4J to Log4J, then we could make that
possible with another option instead of baking it in the product.

No - you don't have to.  As your example shows Log4j 1.x doesn't even support parameterized
messages. Just keep doing what you are doing.

> I could see that the String format should be pluggable (if that's a word). IMO the default
should be the JRE with a plugin for formats from other products.

Not if it is 10 times slower than the SLF4J syntax.

> I am not a JUL user but some of our customers are, how does the JUL syntax compare with
SLF4J? If it is not the same, it's going to be confusing! They both use { and }. Blech.

I haven't even provided the JUL adapter for Log4j 2 yet. AFAIK there are only two ways to
do it and they both suck.

> If you want to write your debug message the way you have shown there is nothing that
says you can't. It will still work.  However, as I recall Ceki ran tests that showed the Java
text formatting is pretty slow.  See http://bugzilla.slf4j.org/show_bug.cgi?id=116 for a nice
discussion on this, and related topics.
>  Is that still true in the latest Java 6 and 7? All of our customers are on Java 6 FWIW.
Does SLF4J and String.format have the same features? Is that even comparing apples to apples?

I'm about to leave for the airport so I can't check right now, but my expectation is that
when I look at String.format I am going to find a MessageFormat in it.  But no, comparing
SLF4J's formatting syntax to Java's String formatting syntax is not comparing apples to apples,
which is precisely why SLF4J's performs so much better. It is simpler.

> One other point.  The String with placeholders is handled by ParamaterizedMessage.  This
class could either be extended or enhanced to support another syntax. If it is extended then
that class would have to be used in the logging call such as
> 	logger.debug(new FormattedMessage("This %s and that %d on this day %1$tm %1$te,%1$tY",
this, this.getThat(), this.getCalendar()));
> That is pretty heavy and provides no advantage over String.format IMO (I use the if/is/log

Why is "new FormattedMessage" any heavier than "String.format".  It does have an advantage
in that it is less expensive when you don't use encapsulating ifs, which a lot of people would
like to do without.

> I want my config to say: use class foo to format the strings with args then. What the
default string format is then debatable. ;)

You would need to figure out a way to do that where it doesn't create a real mess.  Think
about a commons project using that format while a different piece of code uses the SLF4J format.
How is the user supposed to know how to deal with that?

View raw message