commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [Logging] more issues with stack reading
Date Mon, 29 Jul 2002 16:59:02 GMT
On Mon, 29 Jul 2002 wrote:

> The different, to me, is that with SAX, JAXP, etc. you have a bigger stake 
> in the ground in establishing and initializing the underlying 
> implementation.  It is assumed (correct me if I'm wrong) that some portion 
> of user code will be actively involved in instantiating and (possibly) 
> configuring the implementation.

In JAXP you have almost the same model for initialization as in logging. 
JNDI is a bit different, but still the user code is not expected to 
explicitely initialize the impl. ( at least in a J2EE/servlet env ).

The attributes are used to 'tune' the behavior or get information
that was not considered generic enough to add a method ( ssl stuff in
servlets ). Or pass information that can't be expected to be common
to all impl ( like init params for jndi drivers - very common to our
case BTW )

> In commons-logging that role belongs to a class that extends LogFactory. 
> LogFactory has the tooling to locate and instantiate your specialized 
> class.

That's a different story. It seems there are cases when the LogFactory
and LogWrapper can't 'guess' some information - like how much they have
to cut from the stack trace to get to the 'real' caller method. 

Finding an implementation class is different from configuring/tunning

> ANY configuration that goes on in the code should be applicable to ALL 
> logging implementations.  That's a fairly thick wall to penetrate. Solving 
> problems with 'wrapper' classes fits this criteria - it solves a usability 
> issue which may or may-not be addressed by configuration of the underlying 
> implementation.  ['setLevel' does NOT fit the criteria (it's not common to 
> ALL logging implementations)]

That's absurd. All loggers must implement log/info/etc., that's what they
have in common. A logger doesn't have to support 'wrapper' - it may not 
even display the caller method. If a logger supports setLevel 
configuration ( and log4j, jdk1.4 do ) - I don't see why it shouldn't
be available.

I would say 'level' is more common and generic than 'wrapper'.

> Even IF we do MBeans to expose underlying implementation, this falls in 
> the realm of 'should be expected for every MBean', so we need to address 
> how we want this to go through the API regardless of the form.  For 
> example, are we about to have a common base class for the MBean for 
> 'common' attributes?  Is this possible with MBeans?

The MBeans 'solution' is to say - configuration is not our problem, 
we only deal with logging. If a logger supports MBean config or 
something that can be wrapped in an MBean - that's great, but 
not our business. The logging impl. decides what it allows to
be configured, and JMX details how this is to be done.

( by logging implementation I understand log4j, jdk1.4, etc _and_ 
the wrapper that implemenets commons-logging ).

> I don't believe that this problem applies in this case.  I'd like to 
> reopen the issue of adding a simple entry/exit method to the Log 
> interface.

Make a [PROPOSAL], get a majority vote - if a majority ( and at least 3 )
commiters think it's needed, you'll have it.


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

View raw message