incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: logging
Date Tue, 14 Mar 2006 02:20:20 GMT
On Mar 13, 2006, at 5:15 PM, Geir Magnusson Jr wrote:

> 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);
> }

Considered that also :)  The problem is you simply hide the  
complexity in the code.  Since each type can have it's own monitory  
class you end up with magic "type" values in you switch case that  
assume a specific sub class and cast to it.

Regardless of the solution you pick you end up with code somewhere  
that has a map from event type to event data, and I prefer to make  
that explicit, so you get a compile error instead of a subtle runtime  

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

There isn't one for KernelMonitor since it only has one method, but  
there is one for ServiceMonitor. 

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

I used a structure like that in the past and people didn't like it.

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

I already have plans for a major revision to XBean that I will  
consider the 5th revision. :)


View raw message