incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
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.

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

Mime
View raw message