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 based upon 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...
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
