Re: [equinox-dev] Proposal: declarative event notification mechanism

[Thomas Watson <tjwatson@xxxxxxxxxx>]

Sorry Oleg, we have been awfully silent to your idea. I think it is an interesting idea but I am wary of inventing another event model in Equinox. I would be in favor of investigating an enhancement to EventAdmin to allow declarative listeners (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=184021#c8) but I have the following reservations:

1) Theoretically things like a ds service component which is "immediate" could be used in conjunction with the lazy-activation model to eliminate the need to eagerly activate bundles which declare EventHandler service components. The problem with this approach is that none of the ds implementations currently understand how to handle lazy-activated bundles and will not recognize service components until a bundle is in the ACTIVE state. We did a bunch of work in OSGi R4.1 to standardize the lazy-activation policy, but the effort has not followed through the DS or Spring. It would likely take a non-trivial amount of work to enhance DS or Spring to handle lazy-activated bundles the way we want. In the end what we want is very similar to the use of http.registry to declare servlets/resources for the HttpService. A similar approach could be used in the implementation of EventAdmin and likely would not be too hard.

2) EventAdmin is very generic, which I think is a good thing. I would prefer to use the API as-is instead of somehow mapping any existing listener APIs we have in Eclipse onto the EventAdmin model or inventing yet another generic event API. EventHandlers in EventAdmin are passed objects of type Event. At a core level do you think this is good enough for the event needs in Eclipse? For example, in the extension registry we have IRegistryChangeEvent and IRegistryChangeListener. In the future would we be able to have clients implement EventHandler which are fired Event objects instead for registry change events?

Currently I think the Eqinox EventAdmin implementation is pretty good, but likely could use some improvement. In particular for delivering async events. Currently EventAdmin uses the same code as the Framework for delivering events. This common code currently only supports a single thread for delivering async events. This means all async events are fired from the same "event bus" in EventAdmin. It would be interesting to see if we can expand this to a thread pool which allows different event topics to be fired from different threads in the pool. This would allow two disparate topic events to be fired in parallel from different async event threads. I'm not sure if this would violate the event admin spec though.

Bottom line, I think this is a fine idea for Eclipse 4.0 but it is likely not something we can focus on in 3.4 time frame.

Tom



Oleg Besedin ---11/02/2007 02:39:26 PM---While discussing some ongoing work, Pascal came up with a very interesting idea: why won't we create a generic mechanism for "d

From:	Oleg Besedin <obesedin@xxxxxxxxxx>
To:	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:	11/02/2007 02:39 PM
Subject:	[equinox-dev] Proposal: declarative event notification mechanism

---

While discussing some ongoing work, Pascal came up with a very interesting idea: why won't we create a generic mechanism for "declarative" registration of listeners? 

The proposed event notification mechanism would be:

• based on the "whiteboard" pattern [1], plus
• a declarative way to register listeners, plus
• ideas and implementation pieces from OSGi's EventAdmin [2].

To me, this sounds like a great idea. Listeners are ubiquitous and so are the problems associated with their life cycle. 

Details 

In theory, OSGi's EventAdmin service should help work with listeners. Implementations details aside (it is not in the SDK and needs to be tested for scalability), it suffers from the same problem as OSGi services in general: a listener's bundle has to be started and needs to register listener with OSGi. This creates startup order problems and works against lazy activation of bundles. For OSGi services add-on pieces that allow declarative registration of services (Declarative Servieces, SPring, This startup problem sounds similar to the OSGi services registration problem for which we are starting to get "declarative" adds-ons such as DS and Springs. 

The solution to the listener mechanism proposed here is similar – to have a declarative way to describe listeners via XML or manifest file. 

In this model listeners are likely would have to be singletons ("simple" approach), or we could support user-provided factories to create listeners ("advanced" approach). We could add a flag to the declaration of the listener to indicate if it should receive events in case its bundle has not been activated yet. Most likely we'll need to support both synchronous and asynchronous events, just like EventAdmin does. 

To me, the declarative event processing mechanism truly sounds like a component that would be used by a number of projects. What do you think about this idea? 

Sincerely, 
Oleg Besedin 

[1] The description of the "whiteboard" pattern can be found at http://www.osgi.org/documents/osgi_technology/whiteboard.pdf . 
[2] The OSGi specification can be downloaded from http://www.osgi.org/ ; EventAdmin’s Javadoc can be found at http://www2.osgi.org/javadoc/r4/org/osgi/service/event/EventAdmin.html . _______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev