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.
Ralph
