8<
> >
> > 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!
That's what you should be doing already, even without the proposed
Message class, unless you are passing only a string literal (i.e., not a
string constructed via concatenation), otherwise you take a performance
hit regardless. For example:
log.warn("No such object: " + name);
You would want a code guard around this to avoid unnecessary
concatenation. Even the new internationalized logging methods (as
proposed earlier in this thread) were add, you would still want to use a
code guard when passing multiple message parameters:
log.warn("key", new Object[] { param1, param2 });
Otherwise you might unnecessarily create the object array. So you
should really be using code guards as a matter of practice anyway.
>
> 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?
JCL User Guide proposes that debug and trace messages NOT be localized.
Only warn/error/fatal messages are to be localized. Therefore, in the
case of debug/trace messages, no Message instances would be used, so
there is no problem.
>
> 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.
>
> Regards,
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
