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.
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 approach Alex is suggesting, every one of those 50 classes in
the library needs an addMonitor(Monitor m) method on it, and every time
an instance of any of those classes is created, the creator must call
addMonitor(myMonitor) in order to enable logging.
And that's assuming there is a single Monitor interface that is used,
that looks something like:
class Monitor {
public void reportEvent(int level, String msg);
}
If each of the 50 library classes actually has its own Monitor subclass,
with APIs like:
class FooMonitor {
public void reportBadConfigFile();
public void reportInvalidUserName();
}
then the library needs 50 Monitor class definitions.
Or have I misunderstood?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
