commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject RE: [logging] Enterprise Common Logging... dare we say 2.0?
Date Fri, 10 Dec 2004 02:39:28 GMT
"Charles Daniels" <cjd4@yahoo.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message