commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject RE: [logging] Enterprise Common Logging... dare we say 2.0?
Date Fri, 10 Dec 2004 02:39:28 GMT
We don't globalize trace level messaging [debug, entry/exit, trace]

Simon Kitching <s_kitching@paradise.net.nz> wrote on 12/09/2004 07:23:54 
PM:

> On Fri, 2004-12-10 at 13:20, Charles Daniels wrote:
> > > -----Original Message-----
> > > From: Emmanuel Bourg [mailto:smanux@lfjr.net] 
> > > Sent: Thursday, December 09, 2004 4:54 PM
> > > To: Jakarta Commons Developers List
> > > Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?
> > > 
> > > I'm not a logging expert, but couldn't the internationalized 
> > > logger be 
> > > just a specific Log implementation ? You would just log the 
> > > key of the 
> > > message with the existing methods :
> > > 
> > > log.warn("key");
> > > 
> > > The Locale would be a configuration parameter. There is just an 
issue 
> > > with the message's parameters :) This will require at least an 
> > > additional method like warn(String, Object[]).
> > 
> > Since all of the logging methods (fatal, error, etc.) accept a message
> > of type Object, you could support i18n/l10n by doing something like 
the
> > following:
> > 
> > log.warn(new Message("key", params));
> > 
> > where params is an Object[].  Of course, Message could have additional
> > constructors.
> > 
> > The Message class would encapsulate all l10n functionality.  This way,
> > you probably wouldn't even have to create any new implementations
> > specifically for handling i18n/l10n.  Further, you probably wouldn't
> > even have to modify existing Log implementations since most of them
> > (perhaps all?) just end up doing something like 
String.valueOf(message)
> > to get the actual text to log.  Therefore, the new Message class would
> > simply implement toString to properly construct the localized message.
> 
> Alas, I don't think that is efficient enough. This approach would
> require a new Message object to be created *before* each call,
> regardless of whether that logging level was enabled or not.
> 
> Of course, each call could be wrapped in:
>   if (log.isWarnEnabled()) {
>     log.warn(new Message(....));
>   }
> but that would get tiring very quickly!
> 
> Actually, for warn/error/fatal, this approach is probably not too bad.
> After all, there won't be a whole lot of such calls, and they *are*
> likely to have logging enabled.
> 
> It's only for debug/trace levels that this approach would have problems.
> Is it really important to "globalize" debug and trace messages?
> 
> Regardless of the performance, though, there is still the matter of
> exactly where the messagekey+params gets converted to a message string.
> Having a user-provided Message object do it delegates the responsibility
> of locating the i18n resource bundle to the logging app, which may or
> may not be appropriate. Having an underlying log adapter class do it (a
> kind of "i18n decorator" pattern?) raises the issue of how it would
> locate the bundle. Log adaptor classes don't currently deal with
> configuration in any way AFAIK; they just pass the message down.
> 
> Regards,
> 
> Simon
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 



*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message