Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Date: Fri, 10 Dec 2004 14:23:54 +1300
From: Simon Kitching <s_kitching@paradise.net.nz>
Subject: RE: [logging] Enterprise Common Logging... dare we say 2.0?
In-reply-to: <1102639549.3954.171.camel@blackbox>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Message-id: <1102641834.3954.231.camel@blackbox>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7bit
References: <1102639549.3954.171.camel@blackbox>

On Fri, 2004-12-10 at 13:20, Charles Daniels wrote:
> > -----Original Message-----
> > From: Emmanuel Bourg [mailto:smanux@lfjr.net] 
> > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org