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:04:54 GMT
"Charles Daniels" <cjd4@yahoo.com> wrote on 12/09/2004 06:20:14 PM:

> > -----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[]).

I think there is value in an explicit contract between the component 
developer and the logger... if the logger doesn't support i18n, then that 
logger can't be used.

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

We considered that, and it can certainly be discussed here... the problem 
with this approach is

a) the overhead of newing up objects
b) more "work" for the developer, we want to "enable" globalization by 
more direct support

> 
> > 
> > Emmanuel Bourg
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> 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