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?
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".
(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).
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.
(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
"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?
(c)
What happens if an object wants to log before its addLogListener method
is called?
(d)
Where is the equivalent of:
if (log.isDebugEnabled()) {
// build complex description of problem
}
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.
The issue you raise in your webpage about wanting to set different
logging behaviours for different instances of some class is simple to
implement with logging:
public void setLog(Log log);
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.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
