We don't globalize trace level messaging [debug, entry/exit, trace] Simon Kitching <[EMAIL PROTECTED]> wrote on 12/09/2004 07:23:54 PM:
> On Fri, 2004-12-10 at 13:20, Charles Daniels wrote: > > > -----Original Message----- > > > From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, December 09, 2004 4:54 PM > > > To: Jakarta Commons Developers List > > > Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0? > > > > > > I'm not a logging expert, but couldn't the internationalized > > > logger be > > > just a specific Log implementation ? You would just log the > > > key of the > > > message with the existing methods : > > > > > > log.warn("key"); > > > > > > The Locale would be a configuration parameter. There is just an issue > > > with the message's parameters :) This will require at least an > > > additional method like warn(String, Object[]). > > > > 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! > > Actually, for warn/error/fatal, this approach is probably not too bad. > After all, there won't be a whole lot of such calls, and they *are* > likely to have logging enabled. > > It's only for debug/trace levels that this approach would have problems. > Is it really important to "globalize" debug and trace messages? > > 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. > > Regards, > > Simon > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ******************************************* Richard A. Sitze IBM WebSphere WebServices Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
