HiveMind and event listeners

I'm still very confident that the HiveMind debacle will end, and soon, with the software grant to the ASF.

Confident enough that on my trip to and from San Jose, I opened up the HiveMind source code for the first time in months to add some new features (even with a flakey 'A' key).

It seems to me that a very common use case for HiveMind services is for one core service implementation to register for events produced by another service. In terms of Tapestry, I can imagine services that need to know when the reset service has been activated, so that they can clear their caches.

In alpha-3, you could have the BuilderFactory set a property of your service to an event producer service, then inside initializeService(), you could add this as a particular listener of the producer.

Kind of ugly:

• You need a property of your core service implementation to store the event producer service, even though you only use it the one time
• You need to implement Initializable just to do the event registrations

The changes I just made affect BuilderFactory. It adds a new element that can be nested inside <construct>: <event-listener>. <event-listener> allows you to specify another service (using a service-id attribute). This other service is the event producer, which includes methods in its service interface for adding (and removing) listeners of a given type. The constructed service will be added as a listener of events from the event producer service. Just the core service implementation needs to implement the listener interface ... the service interface does not have to extend the listener interface.

The thing to keep in mind with this is that HiveMind is using JavaBeans definition of an event set to find the method to invoke. An event set is to listener interfaces as accessor methods are to a property. An event set is a pair of methods:

• public void addFooListener(FooListener);
• public void removeFooListener(FooListener);

(defines an event set named 'foo'). You need both the add and the remove method for the JavaBeans Introspector to recognize the event set.

I'm very happy with this code ... it's another sweet layer of abstraction that will allow all manner of services to quietly interoperate behind the scenes. I can already picture many uses for this in Tapestry 3.1.