commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Wed, 15 Dec 2004 20:10:13 GMT
robert burrell donkin <> wrote on 
12/15/2004 01:39:57 PM:

> On 10 Dec 2004, at 01:42, Charles Daniels wrote:
> > 8<
> 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 
> > 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...

Ok.. this requires some thought here.  All that sounds good, but is out of 

1.  Remember that our goal is to pass resourceBundleName and keyID's 
straight through to underlying loggers that support I18N.  For those that 
do NOT support, we want minimal help.

2.  Recall that we are enabling LOGGING for COMPONENTS.  This is 
substantially different, and can be [arguably should be] separated from 
any I18N for other output related to the component development [including 
GUI's, text output for console or printer user I/O].

3.  It is NOT our goal to develop a flexible, pluggable, etc.  I18N 
framework for logging.

4.  It is my hope and belief that we can fall back to a lowest common 
denominator that is "sufficient" for logging in *component* development.

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

Richard A. Sitze
IBM WebSphere WebServices Development

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

View raw message