Re: [commons] what logger

[Simon Kitching <si...@chello.at>]

On Sat, 2007-12-15 at 17:52 +0100, Matthias Wessendorf wrote:
Hi,
> 
> I think, I'll use http://slf4j.org/ for the logger in commons.
> 
> What do you think about that ?
> 

[first, sorry for not replying in-thread. I can currently receive emails but cannot send them except via a web/interface. therefore, I cannot reply to any email I have already downloaded .:-(]

The issue is that Trinidad (ADF faces) has always emitted
internationalised log messages, by using its own logging implementation.

But commons-logging does not offer any help for that. If code wants to emit a log message that can be internationalised, it looks like this:

 if (log.isDebugEnabled()) {
    String msg = TrinidadMsgFormatter.format("SomeMsgKey", arg1, arg2);
    log.debug(msg);
 }

This is certainly inconvenient.

The slf4j equivalent looks like this:
  log.debug("SomeMsgKey", arg1, arg2);
which at initial glance seems nicer.

However there are a number of gotchas. The most important is how the
resources are found to map (key, args) to a sensible message.

If the underlying logging implementation is i18n-aware then SLF4j just passes the data on. But the underlying impl still needs to somehow know how to find the Trinidad resource bundles in order to create sensible logging messages. I don't have any experience with i18n-aware logging systems, so I'll leave that to others to comment on how easy/difficult it is to arrange that.

But AFAIK if the underlying logging implementation is *not* i18n-aware, then the message written to the log will simply be "SomeMsgKey", with all info about the actual params lost. This, for example, is the default SLF4J behaviour when configured to forward messages to commons-logging or log4j. This seems unacceptable.

So none of the three logging APIs seems tempting..

Regards,

Simon

Re: [commons] what logger

[Matthias Wessendorf <ma...@apache.org>]

On Dec 15, 2007 8:06 PM, Simon Kitching <si...@chello.at> wrote:
>
> On Sat, 2007-12-15 at 17:52 +0100, Matthias Wessendorf wrote:
> Hi,
> >
> > I think, I'll use http://slf4j.org/ for the logger in commons.
> >
> > What do you think about that ?
> >
>
> [first, sorry for not replying in-thread. I can currently receive emails but cannot send them except via a web/interface. therefore, I cannot reply to any email I have already downloaded .:-(]
>
> The issue is that Trinidad (ADF faces) has always emitted
> internationalised log messages, by using its own logging implementation.

The trinidad logger wraps the JDK one.
It internally looksup a resourcebundle and with
getMessage("SomeKey",...) you get the translated
msg, which you put into methods like warning(String);



>
> But commons-logging does not offer any help for that. If code wants to emit a log message that can be internationalised, it looks like this:
>
>  if (log.isDebugEnabled()) {
>     String msg = TrinidadMsgFormatter.format("SomeMsgKey", arg1, arg2);
>     log.debug(msg);
>  }
>
> This is certainly inconvenient.
>
> The slf4j equivalent looks like this:
>   log.debug("SomeMsgKey", arg1, arg2);
> which at initial glance seems nicer.
>
> However there are a number of gotchas. The most important is how the
> resources are found to map (key, args) to a sensible message.
>
> If the underlying logging implementation is i18n-aware then SLF4j just passes the data on. But the underlying impl still needs to somehow know how to find the Trinidad resource bundles in order to create sensible logging messages. I don't have any experience with i18n-aware logging systems, so I'll leave that to others to comment on how easy/difficult it is to arrange that.
>
> But AFAIK if the underlying logging implementation is *not* i18n-aware, then the message written to the log will simply be "SomeMsgKey", with all info about the actual params lost. This, for example, is the default SLF4J behaviour when configured to forward messages to commons-logging or log4j. This seems unacceptable.
>
> So none of the three logging APIs seems tempting..
>
> Regards,
>
> Simon
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org