> I think we have to put much more effort into the definition of the > hierarchy life cycle. The current definition of > HierarchyEvent is patently > lacking. We can either add methods to HierarchyEvent or > alternatively add > new event types. The Monitoring API of JMX is also worth a look.
Either way is going to require changes to the HierarchyEventListener. I would tend towards a HierarchyEvent with a single event reporting method in the listener interface (or at least a small number of generic methods). That way we can add more event types/ids in the future if we need to, without affecting the signature of the listener interface. If a listener implementation gets an event type/id that it does not recognize, it can ignore it. I'll look at it some more and make a proposal. I want to get this moving...so I can get the plugins done...so I can get the receivers/watchdogs done...etc. Too many dependencies. -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
