You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Marc de Jonge (JIRA)" <ji...@apache.org> on 2014/02/27 11:04:19 UTC

[jira] [Created] (FELIX-4439) ConfigurationAdmin should send events through the EventAdmin

Marc de Jonge created FELIX-4439:
------------------------------------

             Summary: ConfigurationAdmin should send events through the EventAdmin
                 Key: FELIX-4439
                 URL: https://issues.apache.org/jira/browse/FELIX-4439
             Project: Felix
          Issue Type: New Feature
          Components: Configuration Admin
    Affects Versions: configadmin-1.8.0, configadmin-1.6.0
            Reporter: Marc de Jonge


According to the OSGi compendium specifications 4.3.0, section 104.8.1 (page 88), the ConfigurationAdmin should send events through the EventAdmin when it is available.

Copy of the text:

Configuration events must be delivered asynchronously by the Configuration Admin implementation, if present. The topic of a configuration event must be:

org/osgi/service/cm/ConfigurationEvent/<event type>

The <event type> can be any of the following:
- CM_DELETED
- CM_UPDATED
- CM_LOCATION_CHANGED

The properties of a configuration event are:
• cm.factoryPid – (String) The factory PID of the associated Configuration object, if the target is a
Managed Service Factory. Otherwise not set.
• cm.pid – (String) The PID of the associated Configuration object.
• service – (ServiceReference) The Service Reference of the Configuration Admin service.
• service.id – (Long) The Configuration Admin service's ID.
• service.objectClass – (String[]) The Configuration Admin service's object class (which must
include org.osgi.service.cm.ConfigurationAdmin)
• service.pid – (String) The Configuration Admin service's persistent identity, if set.

I'd like to use the EventAdmin for this information, because it is guaranteed to have no side effects and to be informative only.

Now of course I could use the ConfigurationListener for this, but it seems that this has some unwanted side effects. Unbounded configurations now seem to bind to my listenening bundle, while I only want to present some configuration status on a Web UI. There is another bundle to which the configuration should bind, but I use DS to do so. Maybe this is another issue...



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)