commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [beanutils] remove dependency on commons-logging
Date Tue, 11 May 2004 22:44:31 GMT
interesting :)

(but that's not to say that monitors are the right solution for 

BTW we *really* need to do something about moving our wiki so that we 
can use it to play around with ideas and designs. maybe i'll have to 
start a vote on that tomorrow...

- robert

On 11 May 2004, at 22:55, Alex Karasulu wrote:

> 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:
> 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:
> 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 
>> []
>> 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:

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

View raw message