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 Wed, 12 May 2004 01:47:45 GMT

> -----Original Message-----
> From: Simon Kitching []
> Sent: Tuesday, May 11, 2004 6:29 PM
> To: Jakarta Commons Developers List
> Subject: RE: [beanutils] remove dependency on commons-logging
> Hi Alex,
> On Wed, 2004-05-12 at 09: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.
> If a library has a couple of major events that it can report, then
> callbacks are a nice idea.
> However I see logging as something *pervasive*. Libraries like log4j
> make logging very quick, with the explicit intent that lots of log calls
> are scattered through code and left there in production releases so that
> it can be enabled if needed. I suspect you see logging as something that
> is done once in every 1000 lines of code?

Naw could be every 10 lines, 100 lines whatever depending on the 
density of notable events to let the outside world know about.

> I think there are a number of major limitations to this Monitor
> approach. When I use the verb "log" below, you can also read this as
> "report a significant event to a Monitor object via a callback".

log != callback event for monitoring

log == logging implementation of callback interface 

> (a)
> Every object that wants to log needs to have an addMonitor method on it.
> And it needs to be *every* object, because otherwise if you want to add
> logging later, you need to add the method which can break ABI (on
> interfaces at least).

Good point.

> It's not clear whether you suggest having a single Monitor interface
> with a generic API, like "public void reportEvent(Object event)", or
> many different Monitor classes, with methods like "public void
> reportFailedToOpenConfigFile()". If the latter, then API stability is
> going to be an even worse issue.

The later: i.e. reportFailedToOpenConfigFile( with some relevant args )

> (b)
> Code needs to be written to call that addMonitor method, for *every*
> object that can log. This is a lot of work. Worse, it exposes the

Not necessarily an adapter can be used when a specific monitor is 
not set or added et. cetera.

> "callback" concept to the calling code. Suppose that BeanUtils adds an
> addLogListener() method to every class in BeanUtils. Wouldn't every
> library or application which uses beanutils then need to be modified to
> call those methods?

No again this does not need to happen and your example of addLogListener 
worries me - I think we're off base a bit.  Basically every "monitored" 
class depending on how its used can have either a static or instance method
to get and set a single monitor instance.  No need to make it handle more
than one monitor.  If need be a Teeing monitor can be created to propagate
events to a bunch of monitors et cetera.  But for now presume you can 
get/set a monitor.  If nothing is set then the default no-op monitor 
(adapter) is used internally by the monitored object/class.

> (c)
> What happens if an object wants to log before its addLogListener method
> is called?

Good point then you should have the monitor instance required as 
a constructor argument.

> (d)
> Where is the equivalent of:
>      if (log.isDebugEnabled()) {
>         // build complex description of problem
>      }

That's in the implementation of the monitor interface that is defined
by the software that is monitored.  So for example say we have a Foo
class.  Foo class has FooMonitor interface.  FooMonitor may define the
following methods:

void barAdded( Foo monitored, Bar added ) ;
void barRemoved(Foo monitored, Bar removed ) ;

Then FooMonitor can have an implementation let's say LoggingFooMonitor 
that handles the logging like so:

public void barAdded( Foo monitored, Bar added ) 
	if ( log.isDebugEnabled() )
		log.debug( "Bar " + added + " to Foo " + monitored ) ;

> Ok, you could say that the message building goes on within the callback
> method, but in that case sufficient context needs to be passed to that
> callback object to allow that to be done, which is more complex, and
> probably slower.

Well theirs an extra call and a stack so yeah it's slower but not really
enough to effect anything.  

> This is equivalent to setting a Monitor with a "generic" API. However it
> also leads to the same issues I list above, so I think it should be
> avoided wherever possible.

No problem at all these are just recommendations I thought I'd 
get out there.  It's up to you guys who deal with the day in day 
out work to determine what's best for you.  Good luck with your 


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

View raw message