> -----Original Message----- > From: Simon Kitching [mailto:[EMAIL PROTECTED] > 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 increases. > 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. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
