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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
