On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote:
<snip>
That a single log request can be rendered for more than one locale
would either require having a localizable object passing through the
logging dispatch system, being able to translate the log request at the
appender or some other approach internal to the logging system.
Constructing a message using resource bundles and passing a rendered
message on to log4j logging would not accomplish that goal.
We do not desire to pass on the rendered message, unless the underlying
logger offers us no alternative. We desire to pass the messageID and
parameters directly to the Logger, to be handled as it would.
Again, I'm not sure what changes/problems you are arguing for?
That is effectively issuing an architectural ultimatum to the logging implementations: be able to pass resource bundles and parameters through your processing pipeline or appear to be a second class implementation of Jakarta Commons Logging.
(ceki - can't you keep your troops in line! ;)
LOL! how the story has been rewritten in the last two years...
we here in the commons are humble implementors of a simple (but yet too complex) thin (but too fat) bridging API. we are second class (we don't really provide any logging worth a damn): the logging system architects are the first class citizens.
FWIW i have an idea that logging systems capable of supporting native thin wrapper implementations will actually be mostly used through the Log compatibility layer.
If this is making architectural demands, it would be right to have the implementors feedback.
though we are hoping not to make architectural demands, i think everyone here is glad to have your feedback.
your points about the distinction between administrative and diagnostic logging interest me. it seems to me that diagnostic logging is less about the language that the log is written in and more about being able to correlate the message with the code that created the message. this suggests that knowledge of the key is much more critical than the message itself for diagnostic output. given a good key creation convention ("org.apache.commons.bizarro[100]", say). it might therefore be useful to be able to be able to render the key as part of the message (or even as the message).
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
