commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rsi...@us.ibm.com
Subject Re: [Logging] more issues with stack reading
Date Mon, 29 Jul 2002 18:16:25 GMT
>> 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
>it.

>> 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 admit I must agree, in principle, with your comment.  setWrapperClass in 
factory and/or Log isn't necessarily the right thing to do across the 
board.

Also, I think we need more than an MBean for 'generic' support.  To use 
the MBean presumes that we know what the underlying implementation is (and 
we don't).  So we either use introspection on the MBean, or admit that 
there is a more straight forward way (a hint, as you said):

So, until someone proposes something better:

+0 (I may change this later, after I think on this more, to +1) to:
    LogFactory.LOG_WRAPPER_CLASS = 
"org.apache.commons.logging.Log.WRAPPER_CLASS";
    LogFactory.setAttribute(LogFactory.LOG_WRAPPER_CLASS, Wrapper.class);
    w/ logic in LogFactory to pass wrapper class to Log via *constructor* 
argument (other ideas?).

(and I don't have a strong opinion on what the constant's name or value 
really is).

I'm thick headed, and I appreciate your patience in letting me wade 
through the issues.

[I'm still against Log.setAttribute :-]

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

Ooops.  Sorry I raised setLevel :-)  Let's put that issue aside.

>.. cut ..

>Costin

<ras>

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message