On 15 Dec 2004, at 20:10, Richard Sitze wrote:
robert burrell donkin <[EMAIL PROTECTED]> wrote on 12/15/2004 01:39:57 PM:
basedOn 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 itupon a property in commons-logging.properties. 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
focus.
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.
providing underlying layers that could (if they wished) provide better support pretty much addresses my concern.
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.
+1
those goals seem reasonable (and probably achievable).
i'm not sure that lowest common denominator is the right description: a minimal sufficient implementation sounds better to me. in other words, rather than starting with what's provided in other frameworks, we start from nothing and add only what's necessary. once a sufficient implementation has been provided, development stops.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
