commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject RE: [beanutils] remove dependency on commons-logging
Date Tue, 11 May 2004 21:55:46 GMT

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:

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 

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.


> -----Original Message-----
> From: robert burrell donkin []
> 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:
> > For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message