commons-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 & API changes
Date Tue, 23 Jul 2002 21:38:05 GMT
On Tue, 2002-07-23 at 17:18, rsitze@us.ibm.com wrote:
> [those against API changes  -  please see last paragraph of this 
> diatribe].
> 
> Thanks for the clarification on Log4J (I could/should have reviewed the 
> Log4J code).  I believe that we agree with everything but the conclusion.
> 
> Why a setAttribute method on the Log interface?  Who is going to set the 
> attribute on every instantiation of a Log instance?  That job belongs to 
> LogFactory.  So, the handshaking between LogFactory and Log is 'internal', 
> and given just this one argument it doesn't matter to much what the form 
> of the handshaking is.
> 
> That said, I'm VERY much against 'configuring' Log and/or LogFactory via 
> properties.  That job belongs to the underlying implementation.  You can 
> implement Log as desired to accomplish your specific goals, and again you 
> can extend/subclass LogFactory to meet your needs.  I don't WANT a bunch 
> of properties to start surfacing that may/may not be pushed down to 
> various implementations... that my 'logger' independent code may one day 
> have to deal with.  [Once again, if I need that level of control, I 
> subclass LogFactory].  I don't want to start down that road, or open that 
> door.  Therefore I'm -1 against any form of setAttribute in Log.  If I had 
> my way, I'd remove it from LogFactory also (but that's history :-).
> 
> To summarize:  -1 to Log.setAttribute() for any known reason today.  <-- 
> (That little dot at the end is a 'Period' :-)
> 
> That said, there are specific instances where it may make sense to expose 
> generally usefull behavior, and this looks like one of them.  I want to 
> expose these using very explicit API's or mechanisms.
> 
> I'm OK with a Log.setWrapperClass() or supporting Log implementation 
> constructors of the form LogImpl(String wrapper, String category).  The 
> first requires changes to the Log API, which presents problems with 
> versioning (this issue has been discussed before).  The second may or may 
> not require a change to the current LogFactory interface depending upon 
> how 'smart' we make LogFactory.
> 
> All that aside, there are others who have strong feelings against changing 
> the API's.  If they would care to speak up, I'd like to know if their 
> concerns are directed generally to Log/LogFactory, or more specifically 
> toward Log alone.  Myself?  I'm almost always willing to move forward with 
> API changes - of the right sort :-)


I originally proposed to add these methods to interface Log of
commons-logger;

 void trace(Object msg, Throwable thr, String className, String method);
 void debug(Object msg, Throwable thr, String className, String method);
 void info(Object msg, Throwable thr, String className, String method);
 void warn(Object msg, Throwable thr, String className, String method);
 void error(Object msg, Throwable thr, String className, String method);
 void fatal(Object msg, Throwable thr, String className, String method);

Basically letting the Log user choose a stack tracing methodology.

Since you aren't wild about using attributes to hint, how about adding
a method to LogFactory that indicates a desired stack trace strategy;

	 LogFactory.getLog(String loggerName, StackTraceStratagy sst);

Where,
	interface StackTraceStratagy {
		public String getClassName();
		public String getMethodName();
        }


Cheers,
-bob



> 
> <ras>
> 
> 
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
> 
> 
> > 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:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>



--
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