Rod> I agree that for the specific case you cite the
Rod> API contract is sufficient. But allow me to provide
Rod> some concrete examples of
Rod> where logging (and not debugging) is more
Rod> useful. [...]
Craig> At the risk of starting a whole new discussion,
Craig> would having event listeners in the Pool and
Craig> DBCP APIs reduce the need for logging for this
Craig> type of thing?
Having events and event listeners in the Pool and DBCP APIs *may* reduce the
need for the types of logging I was describing, and may provide other
benefits besides. Let's assume we could adequately anticipate the events
that one would need/want to listen to. (That *is* an assumption.) This still
complicates the component APIs, adds a whole new set of intefaces to be
maintained, and like Morgan notes:
Morgan> But then you have to configure the event
Morgan> listeners, etc. etc. etc. I'd
Morgan> prefer to leverage a logging
Morgan> API as a single point of configuration.
The examples of logging I described in the previous email weren't just
hypothetical. These are actual logging activities supported by the version
of the DBCP we use in production, and that support has helped us quite a
bit.
Maybe our process or our system is unusual, but for us, the primary way we
make use of such logging is to discover a problem either in production or
testing (hopefully the latter ;) ), suspect pooling issues based upon the
information readily available, and just bounce the system with a new logging
configuration in order to diagnose the precise problem at hand. In the
general case, we keep the logging running at a much coarser level of detail,
and periodically check the logs for messages that are out of the ordinary.
If we were clever, we could have custom appenders that drive certain log
messages to syslog, or trigger an email or pager, or even take some recovery
action on it's own. (Actually, we do do a bit of that.)
It's hard to beat the convience of simply toggling a property to get the
detailed log information I need, in whatever format I desire. Could I put
together such a system based upon event listeners, perhaps having those
listeners log the data I seem to want? Yes, but that's something of a
hassle, and that's something everyone who wants logging will need to do
(unless I build the logging-listeners back into the system, which puts us
more or less back where we started), and it really is a lot more difficult
to create a new pair of event and listener interfaces every time I've got a
new thing I may potentially want to notify someone of, compared to just
writing log.info("FYI").
I suppose we could set up a more generic event mechanism, with simple but
flexable configuration, perhaps even with default implemenations that simply
log the events, but then I think we're getting dangerously close to a
logging API once again.
Craig> But that's not to say an event model might not be
Craig> useful as well -- for example, if you want your
Craig> app to take some action when those events
Craig> have occurred
I agree, an event model may be worth adding to Pool and DBCP or any of a
number of components we have. And an event model may even remove the need
for logging in some of examples I provided (although I would argue that in
example #1 and #2 at least, the most meaningful recovery action is to change
the client code or to change the configuration--both of which are going to
require manual intervention anyway. Logging the information (not
necessarily to a file) may be the most useful thing to do in those cases).
But I think maybe that's a different debate anyway. I would argue that an
event model and a logging API serve different purposes, and in particular
that the purpose served by logging (or even persistent, configurable
"debugging") is appropriate for many of the non-trivial commons components.
I could try to make this case myself, but for now I'll just point you to
Ceki's slides from ApacheCon (http://www.qos.ch/ac2001/) some of which
address this issue.
(I will point out, however, that not all of the commons components are
"black-boxes". Many of them--for example: httpclient, pool, digester--are
specifically designed for extension and enhancment via custom/proprietary
code, and hence the ability to "debug" both the new/custom code as well as
the jakarta-commons code is useful long after a formal release. There is a
role for "persistent debugging" here, in addition to the role I'd contend
exists for "logging".)
- Rod
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
