On Wed, 2 Apr 2003, Thomas Nichols wrote:
> Date: Wed, 02 Apr 2003 22:54:37 +0100 > From: Thomas Nichols <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Users List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [logging] How to setLevel() for commons logging? (urgent :) > > At 13:41 02/04/2003 -0800, Craig R. McClanahan wrote: > > > >On Wed, 2 Apr 2003, Thomas Nichols wrote: > > > > > Has a commons.logging.Log.setLevel() been ruled out for architectural > > > reasons? This would have kept my code generic. > > > >Yes, because it is out of scope and inconsistent with the charter of > >commons-logging. > > > > > > > > Thanks, > > > Thomas. > > > > > > >Craig > > No problem - thanks for the work you've put in. Would the suggestion of a > non-typesafe accessor method to the underlying Log4J / JDK14 logger object > invoke spontaneous vomiting? >
If you really want to do stuff like that, you can do so by creating your own LogFactory implementation, which returns specialized subclasses of the log implementation objects -- without corrupting the underlying architecture of commons-logging :-).
Great, thank you.
Of course, if you find it necessary to access these logger objects, it seems to me that using commons-logging is a waste of time -- you're going to be tying yourself to the underlying implementation anyway.
I can live with a Log4J dependency in a single source file, but I don't want such dependencies scattered throughout the code. Such an architecture would even allow me to have a controller class select either Log4J or JDK14 logging at startup based on user prefs - to do this it would be very handy to have access to the internals of the instantiated logger to perform custom setup. It seems this is exactly what I get from your suggestion of a custom LogFactory - and commons-logging stays clean and within scope :-)
Thanks again, Thomas.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
