[HiveMind] Question about Event mechanism and other reverse control things

[Christian Essl <ch...@yahoo.de>]

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

Re: [HiveMind] Question about Event mechanism and other reverse control things

[Christian Essl <ch...@yahoo.de>]

On Tue, 21 Oct 2003 12:12:01 -0400, Harish Krishnaswamy 
<hk...@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

Re: [HiveMind] Question about Event mechanism and other reverse control things

[Harish Krishnaswamy <hk...@comcast.net>]

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?

Thanks,
Harish

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