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 Mon, 13 Mar 2006 23:09:40 GMT

Dain Sundstrom wrote:
> On Mar 13, 2006, at 11:37 AM, Geir Magnusson Jr wrote:
>> Dain Sundstrom wrote:
>>> I think projects should avoid logging entirely.  The problem with 
>>> logging is the information that comes out of it is useless to other 
>>> software because it is encoded into user readable strings.  IMHO, the 
>>> best policy is to use a Monitor.  For example see the following XBean 
>>> Monitors:

>> I think projects should avoid logging too.  (I'm still hoping someone 
>> tells me how the orb in Sun's J2SE logs... :)
>> Question about the monitors.... I'm curious -  why didn't you 
>> generalize so that you could add more events as needed w/o breaking 
>> client software?
> Well, I'm actually not too worried about breaking client software that 
> is monitoring the kernel.  For most uses, I expect a user outside of the 
> xbean project to simply write bridges using the monitor, which simply 
> convert the monitor event into an event object specific to another 
> system.  For example a Log4JKernel monitor, would convert a kernel 
> monitor event into a log4j log event.  So if we add stuff in the future 
> it would not be a big deal for the owner of that monitor to write 
> another version.  If we decided to make drastic changes, we could simply 
> create another interface and perform the wrapping inside of the kernel.
> Anyway, what did you have in mind by the term "generalize"?

Well, when I first read you rpost, I had a fleeting glimpse, and was 
going to sketch out in the mail that you just replied to, but found the 
"right" answer wasn't obvious.

Before I looked at your code, I imagined a general interface, something like

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

No matter how implement, I like this far better than logging for the 
reasons you gave.  A client can log or not log as it chooses, or not 
even register for events.


View raw message