commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Essl <christiane...@yahoo.de>
Subject [HiveMind] Question about Event mechanism and other reverse control things
Date Tue, 21 Oct 2003 16:03:37 GMT
I'm a bit unsure about the strategy HiveMind currently takes to the event 
mechanism. As I see IOC recommends some sort publish/subscribe mechanism as 
opposed the JavaBean's style thing. Especially for HiveMind I think to see 
some problems with an event mechanism where Services manage their own 
listeners and/or register themselves:

a) Threaded-model: If a core-impl subsrcibes with a Singleton event-source 
it may get out of thread notifications. Otherwise if it subscribes the 
service-proxy it does not know wheter (and how often) it has alredy 
subcribed or worse when it does have to unsubscribe.

b) General: A service has to be activated to subscribe. Some Services (ie 
e-mail processors) however just want to be activated when an event occurs - 
and are threfore not guranteed to work properly. Second: the event-source 
has to be activiated just for subscription even if it would otherwise get 
never activiated - and will never therefore fire events.

c) Shutdown: Ie a timer-service has currently to be shut-down before the 
Registry is shutdown because it will fire events even during the shutdown 
(which is not allowed). This applies to all services which are not 
triggered by the user but by an outside source (e-mail listeners JMS 
consumers, JMX managers etc). If maybe sometime more dynamics and more 
structured shut-down is provided the thing get's even more chaotic.

Point b and paritally c can be solved using config-points - however this 
means that both an event registration and config-point have to be 
implemented. As I see point c - the reverse dependency - can not be solved 
this way.
  So I want to ask you if something like the following could help:

For each config-point you can define a service which wraps the config-point 
and makes it modifiable (ConfigurationPointService). The service provides 
all the methods ConfiguratonPoint does, except the method to get the List 
of elements. Contrary the service reads in the configuration-point elements 
and allows to add remove items in the list. (For event-listeners the 
service also checks that only one type of item is contained in the list). 
The Service gives out a modifiable  (not backed) snapshot of the list and a 
(concurrent) iterator. The service also fires (JavaBean styled) events when 
it is modified and has a timestamp of last change.

ConfigurationPointServices may only be created using a special 
ServiceFactory service. This factory keeps track of all such services and 
is informed pre shut-down. The factory itself than informs all the 
ConfigurationPointServices to clear all lists.

I mean the overall idea of this is obviously to move listener management 
and optional registration out of the services.

Propably there are other (better) solutions however it would be realy great 
if someone could give me some solution to the mentioned problems.

Chris
    -- Christian Essl

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message