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 Re: Log4j2 Message Formatting (was Re: [Vote] Log4j 2.0-alpha1 rc1)
Date Mon, 16 Jul 2012 19:19:58 GMT

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. 

View raw message