[mutters something about keeping OUR troups in line..]
robert burrell donkin <[EMAIL PROTECTED]> wrote on
12/20/2004 04:03:28 PM:
> On 18 Dec 2004, at 20:52, Curt Arnold wrote:
> > 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.
Absolutely.
> 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).
Can EASILY be managed by making the key part of your message text, in your
resource. Documented as a best practice.. and yes, I can see all sorts
of holes in this.
TWO thoughts:
1. Configuration. We are NOT a logger, we don't want to be a logger,
minimize configuration, etc.
2. Again, you are PRESUMING pre-translation of text before we hand off to
the logger.
3. How the message is rended MUST be managed by the underlying logger
implementation.
4. I'm coming around to the idea that for loggers that do NOT support
translation, we could allow one to be plugged in. The scope must be
across ALL components. The components must not presume, or be written to
presume, any function/feature of these pluggable translators. Therefore I
would maintain that the we should still focus on a resource bundle
approach [properties file or class], so that we maintain portability
across loggers/translators.
A "simple" translator would be provided, but just as we do NOT want to get
into the logging game, I maintain that we don't want to become the defacto
clearing house for translation mechanisms. Those belong somewhere else.
>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
