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 19:42:04 GMT
On Mon, Jul 16, 2012 at 3:19 PM, Ralph Goers <ralph.goers@dslextreme.com>wrote:

> On Jul 15, 2012, at 6:17 PM, Gary Gregory wrote:
>> 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.
> The Log4j 2 API contains LocalizedMessage. I'm not actually very fond of
> this class as it was implemented primarily to provide compatibility with
> Log4j 1.2.  However, it does provide some ideas on how proper
> internationalization and localization could be accomplished.
> There was a discussion on I18n and L10n on the SLF4J list a while ago. As
> a result of that Ceki created the cal10n project which is documented at
> http://www.slf4j.org/localization.html.  The problem I have with this is
> that it is localizing the messages as they are being generated. In my
> experience localization should happen when the message is being viewed, not
> when it is written.  Thus the "message" in the log would consist only of
> the message key and the variables would be there (probably as key/value
> pairs).  In that case the application doing the logging doesn't have any
> idea what the actual message text is.
> However, a good Message implementation could handle both cases.

Ok, so the question is: do you see implementing or redoing this class
post-2.0 without breaking BC?

Thank you,

> Ralph

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

View raw message