tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Herrmann <...@jadn.com>
Subject Re: [logging] Better support for stack walking
Date Tue, 23 Jul 2002 21:19:27 GMT

Hi.  This patch to commons logging allow you to specify which methods
in the call stack are uninteresting when using the JDK1.4 Logger. In
Tomcat this seems to be all methods named "log" and "internalLog."  This
is based on Costin's idea of uninteresting classes, but seems to work
better for method names (in Tomcat anyway.)

It is something of a back door.  It is primarily for projects that
are in the process of converting to using commons-logging.

You use it like this,

    LogFactory.getFactory().setAttribute(
                           "commons-logging.wrapperMethods",
                           "log,internalLog" );

    Log log = LogFactory.getLog( "Logger'sName" );

    log.info("Hello World");
 

Is this an acceptable change to commons-logging ?

Cheers,
-bob

P.S. this patch is updated from the one posted to tomcat-dev



On Tue, 2002-07-23 at 15:03, Bob Herrmann wrote:
> On Mon, 2002-07-22 at 14:18, costinm@covalent.net wrote:
> > 
> > I think there is a simpler solution for this class of problems, and 
> > that would also work with log4j and doesn't require _any_ API
change.
> > ( only changes to the adapter implementations )
> > 
> > Any 'wrapper' will use:
> >   factory=LogFactory.getFactory();
> >    
> >   factory.setAttribute( "commons-logging.wrapperClass", 
> >                         "[CLASSNAME-OF-WRAPPER]");
> >   factory.getLog(), etc.
> 



On Tue, 2002-07-23 at 15:46, costinm@covalent.net wrote:
> > 1.  For Log4J at least, the wrapper class is 'given' to the logger 
> > implementation via a constructor argument.
> 
> No, it is passed on each call. Log4j is the easiest, it has all the 
> support we need. 
> 
> > 1.a.  Log.setLogWrapper/setAttribute isn't enough.  Putting aside 
> > design/style arguments, it's to late.  Granted this COULD be worked around 
> 
> The only reason for setAttribute on Log is that if we set the
> wrapper on the factory, this will be 'global'. In tomcat we have 
> 2-3 wrappers that are used - and if each will use commons-logging
> we'll need to do some tricks.
> 
> > 2.  In an environment where we have multiple components using 
> > commons-logging, some may wrap - others may not.  A Factory.setAttribute 
> > is dangerous here (it's potentially 'global' across multiple components). 
> > Note also the the attributes are (pre-)loaded out of a properties file.
> 
> I agree.
> 
> 
> > 3.  We need an analogous method (setWrapper or setAttribute) for the 
> > Discovery mechanism.  A requirement for 'setWrapper' would seem to be 
> > fairly specific to logging, it doesn't appear to be generally useful in a 
> > 'discovery' tool.
> 
> I don't think so - this is very specific to logging, it has 
> nothing to do with discovery.
> 
> 
> > (2) is a strong vote for 'LogFactory.getInstance(Class wrapper, 
> > [String|Class] cat)', in addition to the current 'getInstance' methods - 
> > and a vote against a 'setAttribute' in a singleton (global) Factory.
> 
> I think setAttribute on Log would solve (2).
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message