commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Wed, 15 Dec 2004 19:39:22 GMT
On 10 Dec 2004, at 01:23, Simon Kitching wrote:
> On Fri, 2004-12-10 at 13:20, Charles Daniels wrote:

<snip>

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

unless you use just4log (or some other byte code engineering tool) 
which finds every place the call occurs and wraps it appropriately.

i started out thinking thinking that we could avoid a separate 
globalization API (for the reasons given by charles), then (for the 
reasons given by simon). now i'm uncertain.

we could have a more compact API if we shipped a small tool that would 
perform the necessary guards on the code but i'm not sure whether this 
would be a good tradeoff and would be interested to hear some other 
opinions on this.

- robert


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