commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Essl <christiane...@yahoo.de>
Subject Re: [HiveMind] Question about Event mechanism and other reverse control things
Date Tue, 21 Oct 2003 16:59:54 GMT
On Tue, 21 Oct 2003 12:12:01 -0400, Harish Krishnaswamy 
<hkrishnaswamy@comcast.net> wrote:

> 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.

That sounds good how did you implement your EventService? I think it's not 
wrong to have the registration and handlers with the services only in some 
cases it's not so good.

> 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?
>

I've not considered interceptors. Could you explain how you mean that. 
Sounds like a good idea. If you mean something like dynamicly created 
listeners etc (java.beans.EventHandler?), I would say a transformer or 
custom rule could create such.

Thanks,
Christian

>
> 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>



---------------------------------------------------------------------
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