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 02:09:55 GMT

> -----Original Message-----
> From: Simon Kitching []
> Sent: Tuesday, May 11, 2004 9:48 PM
> To: Jakarta Commons Developers List
> Subject: RE: [beanutils] remove dependency on commons-logging
> On Wed, 2004-05-12 at 13:38, Noel J. Bergman wrote:
> > > > 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
> >
> > Where does that differ?  What Alex seems to be suggesting is that the
> > logging behavior be moved from the component to a "helper" component.
> The
> > logging helper (monitor) exposes a higher-level and component-specific
> > semantic.  The question appears to be who translates the event into a
> log
> > item, and calls something to emit that item.  In Alex's proposal, it
> would
> > be the monitor.
> Consider a library with 50 classes.

First off the monitor need not be 1:1 with the monitored class.  A 
single monitor can be used for multiple classes or a system of objects
that form a logical component.

Just how many of the 50 first off will be logging?  So take this subclass
and you'll either need to create a unique monitor or some monitors that 
consolidate events for several class.  

Overall you're right Simon the work load for the API author 

> With the current commons logging approach, whether a class logs or not
> is an internal matter for that class. Adding or removing logging does
> not affect the API of that class. And the code calling the library
> doesn't need to care whether logging is used in those classes or not.

With the use of adapter you still don't need to care.  The interfaces 
and methods are there but you just don't bother using them if you're 
not concerned with logging.

> then the library needs 50 Monitor class definitions.
> Or have I misunderstood?

No, although some specific details can be argued, you're right in 
general regarding the explosion of interfaces.  However keep in 
mind that granularity is the key to doing this effectively.  I guess
for IoC when you're dealing with the component level this makes
more sense.


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

View raw message