commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Tue, 21 Dec 2004 18:08:14 GMT
[mutters something about keeping OUR troups in line..]

robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message