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.