Hi, Sorry to step in late but has anyone considered the use of a generic event callback interface for use in monitoring. Beanutil classes can expose a BeanutilsMonitor interface with methods that are called by the executing code to monitor notable events such as failures and successful operations.
A while back Paul Hammant had written a little wiki page about this called NoLogging. Here's a link to it: http://wiki.apache.org/avalon/AvalonNoLogging The use of a callback interface (monitor) was very compelling because it removed any dependency on a logging package. Also the monitor interface is a way for a piece of software to publish those events that are important. Implementations of the monitor interface can then do whatever they like with the event. The most common monitor implementation will simply log the event. It's a bit of a PITA to write monitors for components as an author but you give maximal flexibility to users that will implement different monitors for different circumstances or environments. I have decided to use it while building IoC container independent components within the Eve directory server. I've written a little about the technique here: http://incubator.apache.org/directory/subprojects/eve/components.html The technique is quite useful and keeps code that would otherwise use a logger looking much cleaner. I just thought I'd let you guys know of this option in case it might interest you. There are however some very important guidelines to follow: o If providing monitor adapters print the stack traces of any arguments that are descendents of Throwable. This way at a minimum some notification about errors is given to the developer that just wants to use an adapter for the time being instead of a logging monitor. o Like the Heisenberg Uncertainty Principle your measurements will effect the thing you're measuring so don't spend too much time measuring or don't do anything that would change the execution path of the code (i.e. throwing exceptions). As a matter of fact everything just in case (within a callback) should be surrounded by a try catch on all Throwables. This way you are guaranteed to not drastically affect the code you're monitoring. Hope this is useful to ya if not any feedback on the technique is welcome. I'm sort of new to using it so there may be problems with the approach that I'm unaware of. So far it seems pretty neat. Cheers, Alex > -----Original Message----- > From: robert burrell donkin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 11, 2004 5:12 PM > To: Jakarta Commons Developers List > Subject: Re: [beanutils] remove dependency on commons-logging > > 1. if we're going to look at logging again, i'd prefer to think about > making beanutils a little more easy to use in a managed environment. > this means giving more programmatic control over logging. > > 2. (for reasons given in a previous mail) i'd prefer it if this goes > into a branch rather than the head. > > 3. i'd prefer a service release for downstream developers to solve any > possible problems with commons-collections before looking at logging. > logging is a very delicate problem. it's crucial that it's quick, > simple and robust. > > 4. i'd want to be certain that it'd work with tomcat before any changes > to logging went into head. > > - robert > > On 11 May 2004, at 08:17, Simon Kitching wrote: > > > Hi, > > > > As no-one shot down my proposal as posted earlier, here is a proposed > > patch to beanutils to make commons-logging a completely optional > > dependency. > > > > The Log class is a copy of o.a.c.l.Log, and is intended to be committed > > to the beanutils cvs tree as o.a.c.l.Log. > > > > The LogSource class is intended to be added in o.a.c.beanutils. > > > > logging.patch changes all calls to LogFactory.getLog into calls on > > LogSource.getLog. > > > > The build.xml.patch removes commons-logging from the buildfile, as > > after > > this patch it is neither a compile-time nor a runtime dependency. > > > > I'm expecting comments (maybe screams :-). The only *possible* concern > > I > > am aware of about this patch is where multiple libs containing copies > > of > > o.a.c.l.Log are used and they have different security policies applied. > > > > Cheers, > > > > Simon > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
