logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Log4j2 Message Formatting (was Re: [Vote] Log4j 2.0-alpha1 rc1)
Date Mon, 16 Jul 2012 01:17:58 GMT
On Sun, Jul 15, 2012 at 11:27 AM, Ralph Goers <ralph.goers@dslextreme.com>wrote:

> 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 can keep on going my way of course but I would like to use a baked in API
instead of layering my calls on top of the logging API. That would feel
cleaner, but I'd still like a rich way to format messages. I understand the
trade off now. Thank you for explaining it.

It's not until I port all of our code to 2.0 that I'll see what I am
missing WRT message formatting, so we'll see.

What I am worried about is that lack of "named" arguments for i18n support.
With the current {} format, you cannot re-order parameters. Using the JUL
format of {0}, {1} and so on solves this issue. I do not know enough about
the 2.0 API to know if this is an issue. Can I use the message as a key
into a resource bundle and use the value as a format string? But I'd still
need to re-order arguments because different languages order words in
sentences differently. Am I missing something.

Tangent: One rumor I hear behind the delay for version 5 of Hibernate is
that they decided to write their own logging framework to properly do i18n,
which is supposedly a requirement to use the software in some countries
they care about.

Gary


>
>
> 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 pattern).
>
>
> 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?
>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
View raw message