Dain Sundstrom wrote:
On Mar 13, 2006, at 3:09 PM, Geir Magnusson Jr wrote:
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...
I considered this style, but it occurred to me that everyone would write
a listener containing a switch, which seems like busy work to me. Also,
this style event assumes that every event fires the same data.
Agreed on the switch issue (but figured there might be a helper for that...)
Re the issues of same data, sorry, I wasn't clear - I thought that
there'd be something like a baseclass
public class EventBase {
String msg;
public String toString() {
return msg;
}
}
and then things like
public class KernelNotificationError extends EventBase {
ServiceMonitor monitor;
ServiceEvent event;
Throwable t;
}
for each of the events that the kernel or services generate.
so
public interface Monitor {
void monitorEvent( int type, EventBase data);
}
I think the best way to deal with this is to encourage every one to
extend the NullMonitor which provides no-op implementations of every
method. That way they always pickup new methods.
I couldn't find it. Does it have something like
public abstract class NullMonitor {
public void eventOne(...whatever ) {
unOverridden( ... make a nice string.... );
}
public void eventTwo(.... whatever ... ) {
unOverridden{ ...... make a nice string .... );
}
...
public abstract unOverridden(String s);
}
If you grok what I mean (I did a redeye last night to UK and I'm pretty
beat right now...)
As I wrote before, the biggest issue with using a Monitor is the work
involved in designing the monitor interfaces. If they are to specific,
you don't have upgrade problems, and if they are too generic they are
difficult to use. You also need to choose how many monitors you need
and the granularity. All of these are very tricky issues to get right
the first time you write a system. In XBean, I had an advantage as it
was the 4th kernel system I've written, so I already knew the events
users would want to monitor.
You may write a 5th one day :)
geir
-dain
