incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <>
Subject Re: logging
Date Tue, 14 Mar 2006 01:15:32 GMT

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.


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 :)


> -dain

View raw message