Event Admin Handlers

The goal of the Event Admin Handlers is to allow event communications between iPOJO component instances. The implementation of these handlers relies on an event admin services. It enables the iPOJO component to listen to a list of topics and to receive all related events. It also allows components to send events in an easy way.

{div:class=toc} -[TOC] -{div}

-**change in the 1.2.0** -The 1.2.0 version use the namespace : `org.apache.felix.ipojo.handlers.event` instead of `org.apache.felix.ipojo.handlers.event.EventAdminHandler`. +

Event Admin Handlers
+

+change in the 1.2.0 +

The 1.2.0 version use the namespace : org.apache.felix.ipojo.handlers.event instead of org.apache.felix.ipojo.handlers.event.EventAdminHandler.

-**change in the 1.7.0** -The `@Publisher` annotation is now deprecated and replaced by `@Publishes`. +

+change in the 1.7.0 +

The @Publisher annotation is now deprecated and replaced by @Publishes.

An example

Hereafter is presented a small example :

@Component
-@Instantiate
-public class MyComponent {
-
-    @Publishes( // or @Publisher before the 1.7.0
-      name="myPublisher",
-      topics="bar,nuts") 
-    private Publisher m_publisher;
-
-    @Subscriber(
-      name="mySubscriber",
-      topics="foo")
-    public void receive(Event e) {
-       // Event received
-       // Do something with the event
-    }
-}
+@Component
+@Instantiate
+public class MyComponent {
+
+    @Publishes( // or @Publisher before the 1.7.0
+      name="myPublisher",
+      topics="bar,nuts") 
+    private Publisher m_publisher;
+
+    @Subscriber(
+      name="mySubscriber",
+      topics="foo")
+    public void receive(Event e) {
+       // Event received
+       // Do something with the event
+    }
+}
 
 
 
@@ -213,43 +236,102 @@ The `@Publisher` annotation is now depre
 The handler will parse the description provided in the metadata, and register for you the EventHandler in the OSGi Registry. On one hand, your POJO will receive each event through the handler. With this handler you can specify different callback methods for different topics. On the other side, the handler instantiates and injects configured Publisher references in your POJO, so you can send events transparently through these publishers.
 EventHandler Specification
 Here you can find all configuration options of the EventAdmin handler. As seen before, the handler contains two components : the event subscriber and the event publisher. These components can be configured, using several attributes, as described below. Some of these attributes can be (re)defined in the instance configuration.
-Handler namespace : org.apache.felix.ipojo.handlers.event
+Handler namespace : org.apache.felix.ipojo.handlers.event
 Event subscriber attributes
-{div:class=borderedTable}
-| Attribute name | Required | Description |
-|--|--|--|
-| name | YES | The name of the event subscriber, acting as a unique           identifier. |
-| callback | YES | The name of the POJO's method that will be called each time an             event is received. This method takes only one parameter, of typeorg.osgi.service.event.Eventby default, but this type can be overridden by defining the             data-key and/or the data-type attributes. |
-| topics | YES* | The comma-separated-list of the topics that the handler will           listen to. Each event sent on a topic present in this list will be          sent to the specified callback method. |
-If an event is received and it does not contain such a key, it          is ignored (with a warning message). |
-Data events that are not corresponding to the specified type            will be ignored (with a warning message). |
-| filter | NO* | The event filter is used to filter incoming events before           sending them to the callback. The syntax of this field is           described in the OSGi EventAdmin Specification. If you don't            specify a filter, all events sent on the listened topics will be            considered. |
-* These attributes can be (re)defined in the instance configuration.
-{div}
+
+    
+        
+            
+            
+            
+        
+    
+    
+        
+            
+            
+            
+                    
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+    
+Attribute name Required Description
name yes The name of the event subscriber, acting as a unique identifier.
callback yes The name of the POJO's method that will be called each time an event is received. This method takes only one parameter, of type org.osgi.service.event.Event by default, but this type can be overridden by defining the data-key and/or the data-type attributes.
topics yes The comma-separated-list of the topics that the handler will listen to. Each event sent on a topic present in this list will be          sent to the specified callback method. The topics can be set in the instance configuration.
filter no The event filter is used to filter incoming events before sending them to the callback. The syntax of this field is described in the OSGi Event Admin Specification. If you don't specify a filter, all events sent on the listened topics will be considered. The filter can be set in the instance configuration.
data-key no The data key is used when you want to receive data events. This attribute's value is the key corresponding to the received data in the event's dictionary. If you use this attribute, the parameter passed to the callback method is the the value associated to this key, not the whole event. This attribute is generally used with the **data-type** attribute to specify the received object type. If an event is received and it does not contain such a key, it is ignored (with a warning message).
data-type no This attribute is associated to the data-key attribute. It specifies the type of objects (java.lang.Object by default) that the callback expects. It is used to determine the unique callback method (in case of multiple methods with the same name) and to check type compliance at event reception. Data events that are not corresponding to the specified type will be ignored (with a warning message).
+
 Event publisher attributes
-{div:class=borderedTable}
-| Attribute name | Required | Description |
-|--|--|--|
-| name | YES | The name of the event publisher, acting as a unique identifier. |
-| field | YES | The name of the POJO's field that will be used to send events.            The field is initialized at component instantiation time. The type          of the field must be : org.apache.felix.ipojo.handlers.event.publisher.Publisher. Despite it creates a dependency between the component code and the handler, this system allows hiding the             whole complexity of event sending. |
-| topics | YES* | The comma-separated-list of the topics on which events will be sent. |
-The default value of this attribute is user.data. |
-The default value of this attribute is "false". |
-* These attributes can be (re)defined in the instance configuration.
-{div}
+
+    
+        
+            
+            
+            
+        
+    
+    
+        
+            
+            
+            
+        

+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+    
+Attribute name Required Description
name yes The name of the event publisher, acting as a unique identifier.
          field yes The name of the POJO's field that will be used to send events. The field is initialized at component instantiation time. The type of the field must be : org.apache.felix.ipojo.handlers.event.publisher.Publisher. Despite it creates a dependency between the component code and the handler, this system allows hiding the whole complexity of event sending.
topics yes The comma-separated-list of the topics on which events will be sent. Topics can be set in the instance configuration
data-key no The data key is used when you want to send data events. This attribute's value is the key, in the event's dictionary, in which sent data are stored. When you use the sendData method of the Publisher, the given object is placed in the event dictionary, associated with the specified data-key. The default value of this attribute is user.data.
synchronous no Determines if event sending is synchronous or not. By default, events are sent asynchronously, but you can specify there the desired behaviour of the Publisher.
 Instance configuration
-Some of the described attributes can be (re)defined in the instance configuration section of your metadata file. Its permits to configure event management instance by instance. The following properties are used by the handler :
- event.topics : overrides topics attribute,    available for both subscribers and publishers configuration
- event.filter : overrides filter attribute,    available for subscribers configuration only.
+Some of the described attributes can be (re)defined in the instance configuration section of your metadata file. Its permits to configure event management instance by instance. The following properties are used by the handler :
+
+event.topics : overrides topics attribute, available for both subscribers and publishers configuration
+event.filter : overrides filter attribute, available for subscribers configuration only.
+
 Publisher interface
-The Publisher interface is the link between the component code and the handler. It permits to publish events on the topics specified in the component's description (or instance configuration). The implemented methods are :
- public void send{color:#000000}(Dictionary    content);{color}
-This method is used to send a   standard event, with the specified content. Some specific properties    may be added in the content to satisfy EventAdmin specification.    (e.g., event.topic).
- public void sendData{color:#000000}(Object    o);{color}
-This method is the easier way to send   data. The given object is placed in the event dictionary according  to the data-key attribute (or its default value). Then, this  dictionary is sent as a normal event.
+The Publisher interface is the link between the component code and the handler. It permits to publish events on the topics specified in the component's description (or instance configuration). The implemented methods are :
+
+public void send(Dictionary content) : This method is used to send a    standard event, with the specified content. Some specific properties may be added in the content to satisfy EventAdmin specification (e.g., event.topic).
+public void sendData(Object  o) : This method is the easier way to send data. The given object is placed in the event dictionary according  to the data-key attribute (or its default value). Then, this  dictionary is sent as a regular event.
+
 Handler Architecture
 Here is shown the global architecture of the EventHandler : the interactions between the user components (i.e., POJO), the handler and the OSGi runtime environment.
-!handler-arch.png!
+
 EventHandler Features
 In this section, you will find some examples of the handler's features.
 Instance customization
@@ -287,19 +369,19 @@ This method is the easier way to send   
 
 
 Then you can use the sendData method of your configured publisher.
-import org.apache.felix.ipojo.handlers.event.publisher.Publisher;
-//...
-public class DataPublisher ... {
-    private Publisher m_publisher;
-
-    public void doSomething() {
-      // MyFavoriteType extends MyFavoriteInterface
-      MyFavoriteType data = new MyFavoriteType(...);
-      //...
-      // Send a data event
-      m_publisher.sendData(data);
-    }
-}
+import org.apache.felix.ipojo.handlers.event.publisher.Publisher;
+//...
+public class DataPublisher ... {
+    private Publisher m_publisher;
+
+    public void doSomething() {
+      // MyFavoriteType extends MyFavoriteInterface
+      MyFavoriteType data = new MyFavoriteType(...);
+      //...
+      // Send a data event
+      m_publisher.sendData(data);
+    }
+}
 
 
 
@@ -316,63 +398,65 @@ This method is the easier way to send   
     </component>
     <instance component="...DataEventSubscriber"/>
 </ipojo>
+
+
 
-import my.package.MyFavoriteInterface;
-//...
-public class DataEventSubscriber ... {
-  public void handleData(MyFavoriteInterface o) {
-     // Object received
-     //...
-   }
-}
+ 
+import my.package.MyFavoriteInterface;
+//...
+public class DataEventSubscriber ... {
+  public void handleData(MyFavoriteInterface o) {
+     // Object received
+     //...
+   }
+}
 
 
 
-Annotations use a different set of attributes:
- data-key is replaced by dataKey
- data-type is replaced by dataType
+Annotations use a different set of attributes:
+
+data-key is replaced by dataKey
+data-type is replaced by dataType
+
 Note on synchronous event sending
 By default, events are sent using asynchronous sending (a.k.a.post in OSGi EventAdmin). You can use synchronous sending by defining the synchronous attribute of your publisher to true.
 The behavior of synchronous event sending is particular when you specify several topics in the publisher description. The event is synchronously sent to each topic, one by one. So when you return from this function, you can be sure that the event has been delivered to each topic.
 Publisher instance information
 All events sent by a publisher contains the name of the component instance that sent them. Its enables to filter received events depending the sender instance. The instance name is accessible in the event dictionary by the key publisher.instance.name. Despite it goes against MOM principles, this property is useful to trace events and especially event sources.
 Configuring the handler with annotations
-It is possible to configure the handler with a simple annotations available in the annotation pack ('annotation' project in the iPOJO trunk). Here is an example of usage:
-{code:java}
-import org.apache.felix.ipojo.annotations.Component;
-import org.apache.felix.ipojo.handlers.event.Subscriber;
-import org.apache.felix.ipojo.handlers.event.Publishes
-import org.apache.felix.ipojo.handlers.event.Publisher;
-import org.osgi.service.event.Event;
-@Component
-public class PubSub {
-    @Publishes(name="p1", synchronous=true)
-    Publisher publisher1;
-@Publishes(name="p2", synchronous=false, topics="foo,bar", data_key="data")
-Publisher publisher2;
-
-@Publishes(name="p3", synchronous=true, topics="bar")
-Publisher publisher3;
-
-@Subscriber(name="s1", data_key="data")
-public void receive1(Object foo) {
-    // Process event
-}
-
-@Subscriber(name="s2", topics="foo,bar", filter="(foo=true)")
-public void receive2(Event foo) {
-    // Process event
-}
-
-@Subscriber(name="s3", topics="foo", data*key="data", data*type="java.lang.String")
-public void receive3(String foo) {
-    // Process event
-}
-
-
-
-}
-\\
+It is possible to configure the handler with a simple annotations available in the annotation pack ('annotation' project in the iPOJO trunk). Here is an example of usage:
+import org.apache.felix.ipojo.annotations.Component;
+import org.apache.felix.ipojo.handlers.event.Subscriber;
+import org.apache.felix.ipojo.handlers.event.Publishes
+import org.apache.felix.ipojo.handlers.event.Publisher;
+import org.osgi.service.event.Event;
+
+@Component
+public class PubSub {
+    @Publishes(name="p1", synchronous=true)
+    Publisher publisher1;
+
+    @Publishes(name="p2", synchronous=false, topics="foo,bar", data_key="data")
+    Publisher publisher2;
+
+    @Publishes(name="p3", synchronous=true, topics="bar")
+    Publisher publisher3;
+
+    @Subscriber(name="s1", data_key="data")
+    public void receive1(Object foo) {
+        // Process event
+    }
+
+    @Subscriber(name="s2", topics="foo,bar", filter="(foo=true)")
+    public void receive2(Event foo) {
+        // Process event
+    }
+
+    @Subscriber(name="s3", topics="foo", data*key="data", data*type="java.lang.String")
+    public void receive3(String foo) {
+        // Process event
+    }
+}

@@ -388,7 +472,7 @@ public class PubSub { may be trademarks or registered trademarks of their respective owners.

Attribute name	Required	Description
name	yes	The name of the event subscriber, acting as a unique identifier.
callback	yes	The name of the POJO's method that will be called each time an event is received. This method takes only one parameter, of type `org.osgi.service.event.Event` by default, but this type can be overridden by defining the data-key and/or the data-type attributes.
topics	yes	The comma-separated-list of the topics that the handler will listen to. Each event sent on a topic present in this list will be sent to the specified callback method. The topics can be set in the instance configuration.
filter	no	The event filter is used to filter incoming events before sending them to the callback. The syntax of this field is described in the OSGi Event Admin Specification. If you don't specify a filter, all events sent on the listened topics will be considered. The filter can be set in the instance configuration.
data-key	no	The data key is used when you want to receive data events. This attribute's value is the key corresponding to the received data in the event's dictionary. If you use this attribute, the parameter passed to the callback method is the the value associated to this key, not the whole event. This attribute is generally used with the data-type attribute to specify the received object type. If an event is received and it does not contain such a key, it is ignored (with a warning message).
data-type	no	This attribute is associated to the data-key attribute. It specifies the type of objects (`java.lang.Object` by default) that the callback expects. It is used to determine the unique callback method (in case of multiple methods with the same name) and to check type compliance at event reception. Data events that are not corresponding to the specified type will be ignored (with a warning message).

Attribute name	Required	Description
name	yes	The name of the event publisher, acting as a unique identifier.
field	yes	The name of the POJO's field that will be used to send events. The field is initialized at component instantiation time. The type of the field must be : `org.apache.felix.ipojo.handlers.event.publisher.Publisher`. Despite it creates a dependency between the component code and the handler, this system allows hiding the whole complexity of event sending.
topics	yes	The comma-separated-list of the topics on which events will be sent. Topics can be set in the instance configuration
data-key	no	The data key is used when you want to send data events. This attribute's value is the key, in the event's dictionary, in which sent data are stored. When you use the `sendData` method of the Publisher, the given object is placed in the event dictionary, associated with the specified data-key. The default value of this attribute is `user.data`.
synchronous	no	Determines if event sending is synchronous or not. By default, events are sent asynchronously, but you can specify there the desired behaviour of the Publisher.

- Rev. 1441864 by fmeschbe on Sun, 3 Feb 2013 06:44:40 +0000 + Rev. 1443855 by clement on Fri, 8 Feb 2013 06:49:16 +0000

Added: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/handler-arch.png ============================================================================== Binary file - no diff available. Propchange: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/handler-arch.png ------------------------------------------------------------------------------ svn:mime-type = image/png