Dain Sundstrom wrote:
On Mar 13, 2006, at 11:37 AM, Geir Magnusson Jr wrote:
Dain Sundstrom wrote:
I think projects should avoid logging entirely. The problem with
logging is the information that comes out of it is useless to other
software because it is encoded into user readable strings. IMHO, the
best policy is to use a Monitor. For example see the following XBean
Monitors:
http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-kernel/src/main/java/org/apache/xbean/kernel/ServiceMonitor.javahttp://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-kernel/src/main/java/org/apache/xbean/kernel/KernelMonitor.java
I think projects should avoid logging too. (I'm still hoping someone
tells me how the orb in Sun's J2SE logs... :)
Question about the monitors.... I'm curious - why didn't you
generalize so that you could add more events as needed w/o breaking
client software?
Well, I'm actually not too worried about breaking client software that
is monitoring the kernel. For most uses, I expect a user outside of the
xbean project to simply write bridges using the monitor, which simply
convert the monitor event into an event object specific to another
system. For example a Log4JKernel monitor, would convert a kernel
monitor event into a log4j log event. So if we add stuff in the future
it would not be a big deal for the owner of that monitor to write
another version. If we decided to make drastic changes, we could simply
create another interface and perform the wrapping inside of the kernel.
Anyway, what did you have in mind by the term "generalize"?
Well, when I first read you rpost, I had a fleeting glimpse, and was
going to sketch out in the mail that you just replied to, but found the
"right" answer wasn't obvious.
Before I looked at your code, I imagined a general interface, something like
public interface Monitor {
public void monitorEvent(
<some type> eventType,
<another type> eventData );
}
and I hadn't worked out what <some type> or <another type> was. I
figured that you could then add events w/o worrying about clients,
because a client would simply ignore any type it didn't know how to
handle. One less thing to worry about when upgrading the kernel.
I thought of a few approaches, such as <some type> == int and <another
type> depends on the approach you wanted to take. Map (for named
values), Object[] for a known set of values, or even some base
MonitorData which the client could cast to the appropriate type if it
understood the eventType, or if not, call toString() or something to get
*something* to put in the log to inform a human that something new was
coming out...
No matter how implement, I like this far better than logging for the
reasons you gave. A client can log or not log as it chooses, or not
even register for events.
geir
