(but that's not to say that monitors are the right solution for beanutils)
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:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
