commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <>
Subject Re: [HiveMind] Question about Event mechanism and other reverse control things
Date Tue, 21 Oct 2003 16:12:01 GMT
I have created an EventService that manages all my listeners but my 
registrations and handlers are still with the services though and I knew 
I had to come back to it to set them straight. Although I was thinking I 
can use interceptors instead to manage them. Haven't really thought 
through it; have you considered interceptors? Could you please share 
your findings?


Christian Essl wrote:

> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message