|Re: [equinox-dev] Proposal: declarative event notification mechanism|
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.
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
Oleg Besedin <obesedin@xxxxxxxxxx>
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
11/02/2007 02:39 PM
[equinox-dev] Proposal: declarative event notification mechanism