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).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
