commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [Logging] Internationalization enhancement proposal
Date Sat, 22 Feb 2003 00:26:33 GMT
Andrew McConnell wrote:

> I miss your point about different styles of ResourceBundles. Can you
> elaborate?

If you pass in the key - the logger is expected to locate the bundle
and do the substitution. How do you specify where is the key stored ( which
resource bundle ) ? And AFAIK not everyone uses the same layout and style
for the ResourceBundle.

You could pass in the RB as a param, but with the signatures you posted
I just don't see how it could work without additional config or complexity.

> I disagree with the notion that i18n has no place in logging
> infrastructures for the following reason:

I didn't say that. 

I said that logging and i18n shouldn't be mixed up in the same API.

> Despite the well-documented limitations of the JDK 1.4 API, Sun did
> something very useful by exposing the raw log message ("before
> localization and formatting") within the LogRecord, as well as all of
> the parameters that are ultimately handed to the ResourceBundle. In my

That's exactly my sugestion - instead of adding 24 new methods, just
define a LogRecord class ( that can be added to c-l without _any_ backward
compat problems ). The LogRecord method will have a toString() method doing
the normal formatting - but loggers that are I18N-aware could use the 
information directly.

All log() methods take Object as param - it can be a String, and most
current loggers are just converting it to String. But it can be a LogRecord
or something else.

If a LogRecord would be used - performance-critical code could benefit from
not having to do the concatentation of strings and conversions, and a smart
logger could store the fields directly ( I'm thinking about access.log as
example, or general "logs" that are generated by apps, not only for debug). 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message