You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Christian Essl <ch...@yahoo.de> on 2003/09/20 08:05:16 UTC
[HiveMind] CentralEventService
Howard suggested a Service which produces EventHanddlers. Following on that
I suggested a Central Event Service:
> A Service where (all) Services can register themself with the event-type
> (listener interface) and an event-id they are interested in and the
> firing >Service just imforms the central event Service when an event
> should be fired. The CentralEventService keeps all the listeners and when
> asked to fire >provides the EventAction whith the listeners to fire the
> Event. This would certainly be a bit slower, but it would free the
> service of managing their >own listeners and thus provide some further
> decoupling. If ie a Service is never actually used it is not just
> activated to register a listener. If a >threaded service fires Events and
> a Singleton-Service has to listen currently it has to make sure to
> register with each instance. In case of a central >EventService this
> would not be needed. You could also add some additions to such a Service.
> Ie you could make Event-groups or you are interested only >in events on
> the current thread etc.
Attached is a hivemindmodule (only in source) which implements such a
Service. (This is not realy tested yet - it should just give you a better
idea of what I mean with such a Service).
To register events you use a contribution to the configuration-point
hivemind.events.CentralEvents. The contribution will produce an
EventListener which will invoke a method on a target Service (it uses
java.beans.EventHandler)
For example:
<contribution configuration-id="hivemind.event.CentralEvents">
<event target="hivemind.event.centraltest.Listener1" <!-- the target
service id -->
interface="java.awt.event.ActionListener" <!-- the Interface of the
listener service id -->
action="doAction" <!-- the method which should be called on the target
service when an event happens -->
event-property="actionCommand" <!-- the argument to the action which is a
property of the event given (see java.beans.EventHandler -->
event-id="some.event-id" /> <!-- The event id to which is listend (this
is specific to the event-fiering-service) -->
</contribution>
The Service which fires an event will use the hivemind.event.CentralEvents
service. The method fireEvent(EventExecuter exec,Class
listenerInterface,String eventId). Takes the listener interface for which
the event should be fired. The event-id (specific to the firing service)
and an EventExecuter. The EventExecuter will than be called by the
CentralEvents service for each registered listener. It is responsible of
actually calling the listener methods.
For example to fire an java.awt.event.ActionEvent you would typically use
this:
final ActionEvent ev = new ActionEvent(this,2,"some command");
EventExecuter exec = new EventExecuter(){
public void executeEvent(Object listener){
((ActionListener)listener).actionPerformed(ev);
}
};
centralEventService.fireEvent(exec,ActionListener.class,"myservice.event.id")
;
It would be nice if you could give me some feedback on how useful you find
this and if so how to improve it.
Re: [HiveMind] CentralEventService
Posted by Christian Essl <ch...@yahoo.de>.
I forgot to mention two more points why I preferre the call from the
outside aproach:
If you register in the initialize method and the service is deferred the
Listeners are registered not until the Service is the first time used and
than it may be to late.
Second if the service-type is per thread and you register directly the
CoreService the CoreService may be called out of the one thread and this
will break what I think most peaple use this service-type for namely no
need for synchronization.
On Sat, 20 Sep 2003 16:12:36 +0200, Christian Essl <ch...@yahoo.de>
wrote:
> Service interfaces do not have to extend the listener interface. Their
> are two ways to register a listener. One is directly with the
> EventService. In this case any object implementing a listener can be
> given (ie an inner class refercing directly the CoreService). The second
> is through the configuration point. In this way the EventRegistry builds
> up a DynamicProxy (using CreatorService - currently a
> java.beans.EventHandler) which calls one of the 'normal' methods of the
> ServiceInterface. In this form - from the outside way - it is not
> possible to call direclty into the CoreService (because I don't get it).
>
> Here also a question about what a Service is arises. Is it the
> Interceptors + the CoreService or only the CoreService? I would argue for
> the Interceptors + option and in this way it is cleaner to call from the
> outside. So I prefer the second aproach and think of removing the first.
>
>
>> Haven't looked at your code yet, but one thing to consider is that
>> service may want to "quietly"
>> receive notifications for events ... but not want the event listener
>> interface to be part of their
>> service interface. The core implementation could implement the listener
>> method. When I was
>> visualizing this kind of event framework, I was picturing services
>> implementing Initializable, and
>> registrying for events from the callback method, possibly via inner
>> classes and such.
>>
>> --
>> Howard M. Lewis Ship
>> Creator, Tapestry: Java Web Components
>> http://jakarta.apache.org/tapestry
>> http://jakarta.apache.org/commons/sandbox/hivemind/
>> http://javatapestry.blogspot.com
>>
>>> -----Original Message-----
>>> From: Christian Essl [mailto:christianessl@yahoo.de] Sent: Saturday,
>>> September 20, 2003 2:05 AM
>>> To: commons-dev maillinglist
>>> Subject: [HiveMind] CentralEventService
>>>
>>>
>>> Howard suggested a Service which produces EventHanddlers. Following on
>>> that I suggested a Central Event Service:
>>>
>>> > A Service where (all) Services can register themself with the >
>>> event-type
>>> > (listener interface) and an event-id they are interested in and the >
>>> firing >Service just imforms the central event Service when an event >
>>> should be fired. The CentralEventService keeps all the listeners and
>>> when > asked to fire >provides the EventAction whith the listeners to
>>> fire the > Event. This would certainly be a bit slower, but it would
>>> free the > service of managing their >own listeners and thus provide
>>> some further > decoupling. If ie a Service is never actually used it is
>>> not just > activated to register a listener. If a >threaded service
>>> fires Events and > a Singleton-Service has to listen currently it has
>>> to make sure to > register with each instance. In case of a central
>>> >EventService this > would not be needed. You could also add some
>>> additions to such a Service. > Ie you could make Event-groups or you
>>> are interested only >in events on > the current thread etc.
>>>
>>> Attached is a hivemindmodule (only in source) which implements such a
>>> Service. (This is not realy tested yet - it should just give you a
>>> better idea of what I mean with such a Service).
>>>
>>> To register events you use a contribution to the configuration-point
>>> hivemind.events.CentralEvents. The contribution will produce an
>>> EventListener which will invoke a method on a target Service (it uses
>>> java.beans.EventHandler)
>>> For example:
>>>
>>> <contribution configuration-id="hivemind.event.CentralEvents">
>>> <event target="hivemind.event.centraltest.Listener1" <!-- the target
>>> service id -->
>>> interface="java.awt.event.ActionListener" <!-- the Interface of the
>>> listener service id -->
>>> action="doAction" <!-- the method which should be called on the
>>> target service when an event happens -->
>>> event-property="actionCommand" <!-- the argument to the action which
>>> is a property of the event given (see java.beans.EventHandler -->
>>> event-id="some.event-id" /> <!-- The event id to which is listend
>>> (this is specific to the event-fiering-service) -->
>>> </contribution>
>>>
>>> The Service which fires an event will use the
>>> hivemind.event.CentralEvents service. The method
>>> fireEvent(EventExecuter exec,Class listenerInterface,String eventId).
>>> Takes the listener interface for which the event should be fired. The
>>> event-id (specific to the firing service) and an EventExecuter. The
>>> EventExecuter will than be called by the CentralEvents service for each
>>> registered listener. It is responsible of actually calling the listener
>>> methods.
>>>
>>> For example to fire an java.awt.event.ActionEvent you would typically
>>> use this:
>>>
>>> final ActionEvent ev = new ActionEvent(this,2,"some command");
>>> EventExecuter exec = new EventExecuter(){
>>> public void executeEvent(Object listener){
>>> ((ActionListener)listener).actionPerformed(ev);
>>> }
>>> };
>>>
>>> centralEventService.fireEvent(exec,ActionListener.class,"myser
>>> vice.event.id") ;
>>>
>>>
>>> It would be nice if you could give me some feedback on how useful you
>>> find this and if so how to improve it.
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] CentralEventService
Posted by Christian Essl <ch...@yahoo.de>.
I forgot to mention two more points why I preferre the call from the
outside aproach:
If you register in the initialize method and the service is deferred the
Listeners are registered not until the Service is the first time used and
than it may be to late.
Second if the service-type is per thread and you register directly the
CoreService the CoreService may be called out of the one thread and this
will break what I think most peaple use this service-type for namely no
need for synchronization.
On Sat, 20 Sep 2003 16:12:36 +0200, Christian Essl <ch...@yahoo.de>
wrote:
> Service interfaces do not have to extend the listener interface. Their
> are two ways to register a listener. One is directly with the
> EventService. In this case any object implementing a listener can be
> given (ie an inner class refercing directly the CoreService). The second
> is through the configuration point. In this way the EventRegistry builds
> up a DynamicProxy (using CreatorService - currently a
> java.beans.EventHandler) which calls one of the 'normal' methods of the
> ServiceInterface. In this form - from the outside way - it is not
> possible to call direclty into the CoreService (because I don't get it).
>
> Here also a question about what a Service is arises. Is it the
> Interceptors + the CoreService or only the CoreService? I would argue for
> the Interceptors + option and in this way it is cleaner to call from the
> outside. So I prefer the second aproach and think of removing the first.
>
>
>> Haven't looked at your code yet, but one thing to consider is that
>> service may want to "quietly"
>> receive notifications for events ... but not want the event listener
>> interface to be part of their
>> service interface. The core implementation could implement the listener
>> method. When I was
>> visualizing this kind of event framework, I was picturing services
>> implementing Initializable, and
>> registrying for events from the callback method, possibly via inner
>> classes and such.
>>
>> --
>> Howard M. Lewis Ship
>> Creator, Tapestry: Java Web Components
>> http://jakarta.apache.org/tapestry
>> http://jakarta.apache.org/commons/sandbox/hivemind/
>> http://javatapestry.blogspot.com
>>
>>> -----Original Message-----
>>> From: Christian Essl [mailto:christianessl@yahoo.de] Sent: Saturday,
>>> September 20, 2003 2:05 AM
>>> To: commons-dev maillinglist
>>> Subject: [HiveMind] CentralEventService
>>>
>>>
>>> Howard suggested a Service which produces EventHanddlers. Following on
>>> that I suggested a Central Event Service:
>>>
>>> > A Service where (all) Services can register themself with the >
>>> event-type
>>> > (listener interface) and an event-id they are interested in and the >
>>> firing >Service just imforms the central event Service when an event >
>>> should be fired. The CentralEventService keeps all the listeners and
>>> when > asked to fire >provides the EventAction whith the listeners to
>>> fire the > Event. This would certainly be a bit slower, but it would
>>> free the > service of managing their >own listeners and thus provide
>>> some further > decoupling. If ie a Service is never actually used it is
>>> not just > activated to register a listener. If a >threaded service
>>> fires Events and > a Singleton-Service has to listen currently it has
>>> to make sure to > register with each instance. In case of a central
>>> >EventService this > would not be needed. You could also add some
>>> additions to such a Service. > Ie you could make Event-groups or you
>>> are interested only >in events on > the current thread etc.
>>>
>>> Attached is a hivemindmodule (only in source) which implements such a
>>> Service. (This is not realy tested yet - it should just give you a
>>> better idea of what I mean with such a Service).
>>>
>>> To register events you use a contribution to the configuration-point
>>> hivemind.events.CentralEvents. The contribution will produce an
>>> EventListener which will invoke a method on a target Service (it uses
>>> java.beans.EventHandler)
>>> For example:
>>>
>>> <contribution configuration-id="hivemind.event.CentralEvents">
>>> <event target="hivemind.event.centraltest.Listener1" <!-- the target
>>> service id -->
>>> interface="java.awt.event.ActionListener" <!-- the Interface of the
>>> listener service id -->
>>> action="doAction" <!-- the method which should be called on the
>>> target service when an event happens -->
>>> event-property="actionCommand" <!-- the argument to the action which
>>> is a property of the event given (see java.beans.EventHandler -->
>>> event-id="some.event-id" /> <!-- The event id to which is listend
>>> (this is specific to the event-fiering-service) -->
>>> </contribution>
>>>
>>> The Service which fires an event will use the
>>> hivemind.event.CentralEvents service. The method
>>> fireEvent(EventExecuter exec,Class listenerInterface,String eventId).
>>> Takes the listener interface for which the event should be fired. The
>>> event-id (specific to the firing service) and an EventExecuter. The
>>> EventExecuter will than be called by the CentralEvents service for each
>>> registered listener. It is responsible of actually calling the listener
>>> methods.
>>>
>>> For example to fire an java.awt.event.ActionEvent you would typically
>>> use this:
>>>
>>> final ActionEvent ev = new ActionEvent(this,2,"some command");
>>> EventExecuter exec = new EventExecuter(){
>>> public void executeEvent(Object listener){
>>> ((ActionListener)listener).actionPerformed(ev);
>>> }
>>> };
>>>
>>> centralEventService.fireEvent(exec,ActionListener.class,"myser
>>> vice.event.id") ;
>>>
>>>
>>> It would be nice if you could give me some feedback on how useful you
>>> find this and if so how to improve it.
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Re: [HiveMind] CentralEventService
Posted by Christian Essl <ch...@yahoo.de>.
Service interfaces do not have to extend the listener interface. Their are
two ways to register a listener. One is directly with the EventService. In
this case any object implementing a listener can be given (ie an inner
class refercing directly the CoreService). The second is through the
configuration point. In this way the EventRegistry builds up a DynamicProxy
(using CreatorService - currently a java.beans.EventHandler) which calls
one of the 'normal' methods of the ServiceInterface. In this form - from
the outside way - it is not possible to call direclty into the CoreService
(because I don't get it).
Here also a question about what a Service is arises. Is it the Interceptors
+ the CoreService or only the CoreService? I would argue for the
Interceptors + option and in this way it is cleaner to call from the
outside. So I prefer the second aproach and think of removing the first.
> Haven't looked at your code yet, but one thing to consider is that
> service may want to "quietly"
> receive notifications for events ... but not want the event listener
> interface to be part of their
> service interface. The core implementation could implement the listener
> method. When I was
> visualizing this kind of event framework, I was picturing services
> implementing Initializable, and
> registrying for events from the callback method, possibly via inner
> classes and such.
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
>
>> -----Original Message-----
>> From: Christian Essl [mailto:christianessl@yahoo.de] Sent: Saturday,
>> September 20, 2003 2:05 AM
>> To: commons-dev maillinglist
>> Subject: [HiveMind] CentralEventService
>>
>>
>> Howard suggested a Service which produces EventHanddlers. Following on
>> that I suggested a Central Event Service:
>>
>> > A Service where (all) Services can register themself with the > event-
>> type
>> > (listener interface) and an event-id they are interested in and the >
>> firing >Service just imforms the central event Service when an event >
>> should be fired. The CentralEventService keeps all the listeners and
>> when > asked to fire >provides the EventAction whith the listeners to
>> fire the > Event. This would certainly be a bit slower, but it would
>> free the > service of managing their >own listeners and thus provide
>> some further > decoupling. If ie a Service is never actually used it is
>> not just > activated to register a listener. If a >threaded service
>> fires Events and > a Singleton-Service has to listen currently it has to
>> make sure to > register with each instance. In case of a central
>> >EventService this > would not be needed. You could also add some
>> additions to such a Service. > Ie you could make Event-groups or you are
>> interested only >in events on > the current thread etc.
>>
>> Attached is a hivemindmodule (only in source) which implements such a
>> Service. (This is not realy tested yet - it should just give you a
>> better idea of what I mean with such a Service).
>>
>> To register events you use a contribution to the configuration-point
>> hivemind.events.CentralEvents. The contribution will produce an
>> EventListener which will invoke a method on a target Service (it uses
>> java.beans.EventHandler)
>> For example:
>>
>> <contribution configuration-id="hivemind.event.CentralEvents">
>> <event target="hivemind.event.centraltest.Listener1" <!-- the target
>> service id -->
>> interface="java.awt.event.ActionListener" <!-- the Interface of the
>> listener service id -->
>> action="doAction" <!-- the method which should be called on the target
>> service when an event happens -->
>> event-property="actionCommand" <!-- the argument to the action which
>> is a property of the event given (see java.beans.EventHandler -->
>> event-id="some.event-id" /> <!-- The event id to which is listend
>> (this is specific to the event-fiering-service) -->
>> </contribution>
>>
>> The Service which fires an event will use the
>> hivemind.event.CentralEvents service. The method fireEvent(EventExecuter
>> exec,Class listenerInterface,String eventId). Takes the listener
>> interface for which the event should be fired. The event-id (specific to
>> the firing service) and an EventExecuter. The EventExecuter will than be
>> called by the CentralEvents service for each registered listener. It is
>> responsible of actually calling the listener methods.
>>
>> For example to fire an java.awt.event.ActionEvent you would typically
>> use this:
>>
>> final ActionEvent ev = new ActionEvent(this,2,"some command");
>> EventExecuter exec = new EventExecuter(){
>> public void executeEvent(Object listener){
>> ((ActionListener)listener).actionPerformed(ev);
>> }
>> };
>>
>> centralEventService.fireEvent(exec,ActionListener.class,"myser
>> vice.event.id") ;
>>
>>
>> It would be nice if you could give me some feedback on how useful you
>> find this and if so how to improve it.
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Re: [HiveMind] CentralEventService
Posted by Christian Essl <ch...@yahoo.de>.
Service interfaces do not have to extend the listener interface. Their are
two ways to register a listener. One is directly with the EventService. In
this case any object implementing a listener can be given (ie an inner
class refercing directly the CoreService). The second is through the
configuration point. In this way the EventRegistry builds up a DynamicProxy
(using CreatorService - currently a java.beans.EventHandler) which calls
one of the 'normal' methods of the ServiceInterface. In this form - from
the outside way - it is not possible to call direclty into the CoreService
(because I don't get it).
Here also a question about what a Service is arises. Is it the Interceptors
+ the CoreService or only the CoreService? I would argue for the
Interceptors + option and in this way it is cleaner to call from the
outside. So I prefer the second aproach and think of removing the first.
> Haven't looked at your code yet, but one thing to consider is that
> service may want to "quietly"
> receive notifications for events ... but not want the event listener
> interface to be part of their
> service interface. The core implementation could implement the listener
> method. When I was
> visualizing this kind of event framework, I was picturing services
> implementing Initializable, and
> registrying for events from the callback method, possibly via inner
> classes and such.
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
>
>> -----Original Message-----
>> From: Christian Essl [mailto:christianessl@yahoo.de] Sent: Saturday,
>> September 20, 2003 2:05 AM
>> To: commons-dev maillinglist
>> Subject: [HiveMind] CentralEventService
>>
>>
>> Howard suggested a Service which produces EventHanddlers. Following on
>> that I suggested a Central Event Service:
>>
>> > A Service where (all) Services can register themself with the > event-
>> type
>> > (listener interface) and an event-id they are interested in and the >
>> firing >Service just imforms the central event Service when an event >
>> should be fired. The CentralEventService keeps all the listeners and
>> when > asked to fire >provides the EventAction whith the listeners to
>> fire the > Event. This would certainly be a bit slower, but it would
>> free the > service of managing their >own listeners and thus provide
>> some further > decoupling. If ie a Service is never actually used it is
>> not just > activated to register a listener. If a >threaded service
>> fires Events and > a Singleton-Service has to listen currently it has to
>> make sure to > register with each instance. In case of a central
>> >EventService this > would not be needed. You could also add some
>> additions to such a Service. > Ie you could make Event-groups or you are
>> interested only >in events on > the current thread etc.
>>
>> Attached is a hivemindmodule (only in source) which implements such a
>> Service. (This is not realy tested yet - it should just give you a
>> better idea of what I mean with such a Service).
>>
>> To register events you use a contribution to the configuration-point
>> hivemind.events.CentralEvents. The contribution will produce an
>> EventListener which will invoke a method on a target Service (it uses
>> java.beans.EventHandler)
>> For example:
>>
>> <contribution configuration-id="hivemind.event.CentralEvents">
>> <event target="hivemind.event.centraltest.Listener1" <!-- the target
>> service id -->
>> interface="java.awt.event.ActionListener" <!-- the Interface of the
>> listener service id -->
>> action="doAction" <!-- the method which should be called on the target
>> service when an event happens -->
>> event-property="actionCommand" <!-- the argument to the action which
>> is a property of the event given (see java.beans.EventHandler -->
>> event-id="some.event-id" /> <!-- The event id to which is listend
>> (this is specific to the event-fiering-service) -->
>> </contribution>
>>
>> The Service which fires an event will use the
>> hivemind.event.CentralEvents service. The method fireEvent(EventExecuter
>> exec,Class listenerInterface,String eventId). Takes the listener
>> interface for which the event should be fired. The event-id (specific to
>> the firing service) and an EventExecuter. The EventExecuter will than be
>> called by the CentralEvents service for each registered listener. It is
>> responsible of actually calling the listener methods.
>>
>> For example to fire an java.awt.event.ActionEvent you would typically
>> use this:
>>
>> final ActionEvent ev = new ActionEvent(this,2,"some command");
>> EventExecuter exec = new EventExecuter(){
>> public void executeEvent(Object listener){
>> ((ActionListener)listener).actionPerformed(ev);
>> }
>> };
>>
>> centralEventService.fireEvent(exec,ActionListener.class,"myser
>> vice.event.id") ;
>>
>>
>> It would be nice if you could give me some feedback on how useful you
>> find this and if so how to improve it.
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [HiveMind] CentralEventService
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Haven't looked at your code yet, but one thing to consider is that service may want to "quietly"
receive notifications for events ... but not want the event listener interface to be part of their
service interface. The core implementation could implement the listener method. When I was
visualizing this kind of event framework, I was picturing services implementing Initializable, and
registrying for events from the callback method, possibly via inner classes and such.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Christian Essl [mailto:christianessl@yahoo.de]
> Sent: Saturday, September 20, 2003 2:05 AM
> To: commons-dev maillinglist
> Subject: [HiveMind] CentralEventService
>
>
> Howard suggested a Service which produces EventHanddlers.
> Following on that
> I suggested a Central Event Service:
>
> > A Service where (all) Services can register themself with the
> > event-type
> > (listener interface) and an event-id they are interested in and the
> > firing >Service just imforms the central event Service when
> an event
> > should be fired. The CentralEventService keeps all the
> listeners and when
> > asked to fire >provides the EventAction whith the listeners
> to fire the
> > Event. This would certainly be a bit slower, but it would free the
> > service of managing their >own listeners and thus provide
> some further
> > decoupling. If ie a Service is never actually used it is not just
> > activated to register a listener. If a >threaded service
> fires Events and
> > a Singleton-Service has to listen currently it has to make sure to
> > register with each instance. In case of a central
> >EventService this
> > would not be needed. You could also add some additions to
> such a Service.
> > Ie you could make Event-groups or you are interested only
> >in events on
> > the current thread etc.
>
> Attached is a hivemindmodule (only in source) which implements such a
> Service. (This is not realy tested yet - it should just give
> you a better
> idea of what I mean with such a Service).
>
> To register events you use a contribution to the configuration-point
> hivemind.events.CentralEvents. The contribution will produce an
> EventListener which will invoke a method on a target Service (it uses
> java.beans.EventHandler)
> For example:
>
> <contribution configuration-id="hivemind.event.CentralEvents">
> <event target="hivemind.event.centraltest.Listener1"
> <!-- the target
> service id -->
> interface="java.awt.event.ActionListener" <!--
> the Interface of the
> listener service id -->
> action="doAction" <!-- the method which should
> be called on the target
> service when an event happens -->
> event-property="actionCommand" <!-- the
> argument to the action which is a
> property of the event given (see java.beans.EventHandler -->
> event-id="some.event-id" /> <!-- The event id
> to which is listend (this
> is specific to the event-fiering-service) -->
> </contribution>
>
> The Service which fires an event will use the
> hivemind.event.CentralEvents
> service. The method fireEvent(EventExecuter exec,Class
> listenerInterface,String eventId). Takes the listener
> interface for which
> the event should be fired. The event-id (specific to the
> firing service)
> and an EventExecuter. The EventExecuter will than be called by the
> CentralEvents service for each registered listener. It is
> responsible of
> actually calling the listener methods.
>
> For example to fire an java.awt.event.ActionEvent you would
> typically use
> this:
>
> final ActionEvent ev = new ActionEvent(this,2,"some command");
> EventExecuter exec = new EventExecuter(){
> public void executeEvent(Object listener){
> ((ActionListener)listener).actionPerformed(ev);
> }
> };
>
> centralEventService.fireEvent(exec,ActionListener.class,"myser
> vice.event.id")
> ;
>
>
> It would be nice if you could give me some feedback on how
> useful you find
> this and if so how to improve it.
>
>
>
RE: [HiveMind] CentralEventService
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Haven't looked at your code yet, but one thing to consider is that service may want to "quietly"
receive notifications for events ... but not want the event listener interface to be part of their
service interface. The core implementation could implement the listener method. When I was
visualizing this kind of event framework, I was picturing services implementing Initializable, and
registrying for events from the callback method, possibly via inner classes and such.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Christian Essl [mailto:christianessl@yahoo.de]
> Sent: Saturday, September 20, 2003 2:05 AM
> To: commons-dev maillinglist
> Subject: [HiveMind] CentralEventService
>
>
> Howard suggested a Service which produces EventHanddlers.
> Following on that
> I suggested a Central Event Service:
>
> > A Service where (all) Services can register themself with the
> > event-type
> > (listener interface) and an event-id they are interested in and the
> > firing >Service just imforms the central event Service when
> an event
> > should be fired. The CentralEventService keeps all the
> listeners and when
> > asked to fire >provides the EventAction whith the listeners
> to fire the
> > Event. This would certainly be a bit slower, but it would free the
> > service of managing their >own listeners and thus provide
> some further
> > decoupling. If ie a Service is never actually used it is not just
> > activated to register a listener. If a >threaded service
> fires Events and
> > a Singleton-Service has to listen currently it has to make sure to
> > register with each instance. In case of a central
> >EventService this
> > would not be needed. You could also add some additions to
> such a Service.
> > Ie you could make Event-groups or you are interested only
> >in events on
> > the current thread etc.
>
> Attached is a hivemindmodule (only in source) which implements such a
> Service. (This is not realy tested yet - it should just give
> you a better
> idea of what I mean with such a Service).
>
> To register events you use a contribution to the configuration-point
> hivemind.events.CentralEvents. The contribution will produce an
> EventListener which will invoke a method on a target Service (it uses
> java.beans.EventHandler)
> For example:
>
> <contribution configuration-id="hivemind.event.CentralEvents">
> <event target="hivemind.event.centraltest.Listener1"
> <!-- the target
> service id -->
> interface="java.awt.event.ActionListener" <!--
> the Interface of the
> listener service id -->
> action="doAction" <!-- the method which should
> be called on the target
> service when an event happens -->
> event-property="actionCommand" <!-- the
> argument to the action which is a
> property of the event given (see java.beans.EventHandler -->
> event-id="some.event-id" /> <!-- The event id
> to which is listend (this
> is specific to the event-fiering-service) -->
> </contribution>
>
> The Service which fires an event will use the
> hivemind.event.CentralEvents
> service. The method fireEvent(EventExecuter exec,Class
> listenerInterface,String eventId). Takes the listener
> interface for which
> the event should be fired. The event-id (specific to the
> firing service)
> and an EventExecuter. The EventExecuter will than be called by the
> CentralEvents service for each registered listener. It is
> responsible of
> actually calling the listener methods.
>
> For example to fire an java.awt.event.ActionEvent you would
> typically use
> this:
>
> final ActionEvent ev = new ActionEvent(this,2,"some command");
> EventExecuter exec = new EventExecuter(){
> public void executeEvent(Object listener){
> ((ActionListener)listener).actionPerformed(ev);
> }
> };
>
> centralEventService.fireEvent(exec,ActionListener.class,"myser
> vice.event.id")
> ;
>
>
> It would be nice if you could give me some feedback on how
> useful you find
> this and if so how to improve it.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org