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
From: Oleg Besedin <[EMAIL PROTECTED]>
To: Equinox development mailing list <[email protected]>
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
