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 06:54:45 GMT


Dain Sundstrom wrote:
> 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.

Oh, definitely.  That's why I noted that there are some very non-OO 
solutions out there... (or think I did...)

> 
> 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 error.
> 
>>> 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.
> 
> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-kernel/src/main/java/org/apache/xbean/kernel/NullServiceMonitor.java

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

YBean?  Then the end, ZBean, is in sight for you...

> 
> -dain
> 
> 

Mime
View raw message