...
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 |
|---|
|
|
| Wiki Markup |
|---|
| {div:class=toc}
{toc:maxLevel=4|minLevel=2}
{div} |
| Info |
|---|
|
The 1.2.0 version use the namespace : org.apache.felix.ipojo.handlers.event instead of org.apache.felix.ipojo.handlers.event.EventAdminHandler. |
...
Event subscriber attributes
| 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 |
|
| Wiki Markup |
|---|
{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 |
| topics | YES* | The comma-separated-list |
|
Event publisher attributes
| 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.Objectby 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). | 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. |
Event publisher attributes
| 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 : |
|
| Wiki Markup |
|---|
{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. |
| topics | YES* | The comma-separated-list |
| 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.
The default value of this attribute is "false". |
* These attributes can be (re)defined in the instance configuration. |
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 :
...
