"Charles Daniels" <[EMAIL PROTECTED]> wrote on 12/09/2004 07:42:47 PM:
> 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.
The resource bundle is named on the EnterpriseLogFactory factory methods
that produce the EnterpriseLog. It's up the the wrapper/implementation to
determine what to do with the resource bundle name and keys.
Keep it simple
>
> >
> > Regards,
> >
> > Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
