[slf4j-dev] slf4j i8ln

[Ralph Goers]

On Aug 19, 2009, at 1:58 PM, Ceki Gulcu wrote:

>
>
> Ralph Goers wrote:
>> As I've said, I'm not at all in favor of SLF4J "doing" I18N. It is  
>> better to do it under a framework such as Spring's MessageSource  
>> interface where you can either use the default implementation,  
>> which uses ResourceBundles, or easily provide your own. As I said,  
>> I'm also planning on creating a framework to manage  
>> internationalized messages using Commons Configuration and XML files.
>
> In a way, MessageFormatter [1] performs a similar function to a  
> ResourceBundle. It is also noteworthy that currently  
> MessageFormatter.format() is invoked within  slf4j bindings.  
> Previously, users had asked that the MessageFormatter implementation  
> be pluggable. Unfortunately, this is not possible because if library  
> A depends on MessageFormatter_A and library B depends on  
> MessageFormatter_B, and if MessageFormatter_A and MessageFormatter_B  
> use incompatible message formatting conventions, for example "hello  
> {}" and "hello {0}", then choosing MessageFormatter_A as the  
> implementation will screw up messages generated by library B. The  
> same problem would occur with resource bundles or its spring  
> equivalents.

While an I18N framework might do some sort of message formatting  
itself it wouldn't replace MessageFormatter.format(). In otherwords,  
lets say I have a couple of message definitions like

<property key="name">Bank of America</property>
<property key="welcome">Welcome to ${name}, {}</property>

In this case one would hope that the framework would return "Welcome  
to Bank of America, {}". Presumably SLF4J's usual mechanism would  
replace the runtime variable.  OTOH, if the formatting is deferred to  
the Appender then obviously the runtime variables would have to be  
replaced there. Many of the current I18N frameworks use the normal  
Java formatter for that.

>
>> In that scenario the application either calls getMessage() and then  
>> passes the resulting String to the log call or the application  
>> passes the message key as the message on the log call, which is the  
>> approach I would suggest. In the second scenario it is up to the  
>> Appender to resolve the key by calling getMessage(). Ideally, the  
>> Appender should be able to tell whether it is getting a key or the  
>> actual message text. This can be done simply by convention - i.e. a  
>> log message like "key=Message1" or by passing a parameter. There is  
>> no real need to enhance SLF4J to be able to do this.
>
> Assuming we had I18NLogger_1 wrapping/decorating o.slf4j.Logger, a  
> printing method, say i18nInfo() could be implemented as:
>
> public class I18NLogger_1 extends LoggerWrapper implements Logger
>
>  I18NLogger(Logger logger) {
>    super(logger, I18NLogger_1.class.getName());
>  }
>
>  void i18nInfo(String message, Object... params) {
>    if(logger.isInfoEnabled()) {
>      // aMessageSourceImpl is some implementation of
>      // org.springframework.context.MessageSource or similar
>      // interface
>      String m = aMessageSourceImpl.getMessage(message, params,  
> locale);
>      logger.info(m);
>    }
>  }
> }
>
> In the above code, only aMessageSourceImpl and locale are not  
> clearly defined.
>
> Another possible implementation for I18NLogger is as follows:
>
> public class I18NLogger_2 extends LoggerWrapper implements Logger
>
>  I18NLogger_2(Logger logger) {
>    super(logger, I18NLogger_2.class.getName());
>  }
>
>  void i18nInfo(String message, Object... params) {
>    if(logger.isInfoEnabled()) {
>      // I18N is a marker for all internationalized messages
>      logger.info(I18N, message, params);
>    }
>  }
> }
>
> In this second implementation, internationalization is done within  
> the appropriate appender or possibly a new logback component (e.g.  
> ILoggingEventTransformer) which would know how to
> internationalize messages. It would do so only for messages marked  
> with I18N.

Wow. How stupid of me. I completely forgot about Markers. That is an  
obvious and very good way of indicating whether the message is a key  
or text.

>
> The advantage of this second approach is that Joran (logback's  
> internal configuration framework) can be leveraged to configure  
> things pretty much the end-user wants. See for example  
> SiftingAppender [2] which is heavily based on Joran.
>
>> The piece that SLF4J is missing is the ability to detect the target  
>> Locale of the message. But even this can be handled without change  
>> to SLF4J. Just adding the Locale to the MDC would allow the  
>> Appender to do the right thing. Of course, you'd have to use a  
>> logging implementation that supports the MDC.
>
> FYI, all slf4j bindings, including slf4j-jdk14 and even slf4j-nop  
> ship with functional MDC support. It's just that the underlying  
> logging framework does not make use of the provided MDC data.

Sure. But how would you write a Handler for JUL that could do it?

>
>> In short, instead of asking for a change to SLF4J it would make  
>> more sense to me for you to ask for an enhancement to Logback so  
>> that any Appender can have the opportunity to internationalize the  
>> message. Currently you'd have to do that in a Layout, but I don't  
>> believe all Appenders support them.
>
> I don't know. Logback is tempting because of all the customization  
> it allows. I could even imagine adding a new component, say  
> ILoggingEventTransformer, which could transform logging events with  
> internationalization being one particular type of transformation. If  
> ILoggingEventTransformer came before appenders, it could transform  
> the event for all appenders. Nevertheless, the main advantage of  
> logback is all the additional customization made possible.

Yes. Doing it that way would be beneficial to some Logback users.  
Hopefully, it would still allow the message to be left unresolved in  
the case where the customer wants to write the message key and  
parameters to a database, not the localized message.
>
> For Web Beans, I am under the impression that all logging back ends  
> need to be supported, hence I18NLogger_1.
>
> What were the requirements again? :-)

Lol.

Ralph