On Fri, 2004-12-10 at 13:20, Charles Daniels wrote:
<snip>
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!
unless you use just4log (or some other byte code engineering tool) which finds every place the call occurs and wraps it appropriately.
i started out thinking thinking that we could avoid a separate globalization API (for the reasons given by charles), then (for the reasons given by simon). now i'm uncertain.
we could have a more compact API if we shipped a small tool that would perform the necessary guards on the code but i'm not sure whether this would be a good tradeoff and would be interested to hear some other opinions on this.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
