commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Wed, 15 Dec 2004 19:39:57 GMT
On 10 Dec 2004, at 01:42, Charles Daniels wrote:

> 8<


>> 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.
> Yes, I agree, the trick then becomes locating the resource bundle.
> Perhaps one way to do this is to have the Message class locate it based
> upon a property in  The Message.toString
> method would then lookup the  resource and construct the message.  This
> way, neither the application nor the Log implementation would have to
> deal with it.

i really think that this needs to be done through pluggable adapters 
(since there isn't going to be any one correct solution).

in addition, i've come to the conclusion (after tussling with some 
thorny i18n and customization problems elsewhere) that the formatting 
conventionally available for parameterization rendering (stuff like 
MessageFormat) just isn't good enough and a proper bean query language 
is really needed. i've always wanted to mix resources and JEXL but 
(<sigh>as usual</sigh>) i haven't found the cycles...

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message