CODEWITHSUNDEEP
osgi
Zymus
Zymus

Reputation: 1698

Why does the ConfigurationAdmin specification use its own eventing mechanism, as opposed to the EventAdmin?

I want to understand why the ConfigurationAdmin specification defines its own mechanism for dispatching events, instead of using the EventAdmin specification, which is also defined in the OSGi Compendium.

The ConfigurationAdmin specification mentions that it will send ConfigurationEvents to ConfigurationListeners registered in the service registry.

Listener for Configuration Events. When a ConfigurationEvent is fired, it is asynchronously delivered to all ConfigurationListeners.

ConfigurationListener objects are registered with the Framework service registry and are notified with a ConfigurationEvent object when an event is fired. ConfigurationListener objects can inspect the received ConfigurationEvent.

This seems like it would be a fine candidate for the EventAdmin, given that the properties of the ConfigurationEvent are all primitive.

val event: Event = Event(Hashtable(mapOf<String, Any>(
    "type" to CM_UPDATED,
    "service.factoryPid" to "someFactoryPid.guid",
    "service.pid" to "somePid.guid"
)))

@Component
class ConfigurationListener : EventHandler {

    override fun handleEvent(event: Event) {
        // ...
    }
}

I'm designing some services which would make use of some sort of event handling mechanism. The choices I think I have are using the EventAdmin (provided in the Compendium), and rolling my own (like the ConfigurationAdmin).

I'd like to know what design decision was made that led the OSGi Alliance to create a separate event mechanism for the ConfigurationAdmin, instead of the already created event mechanism, provided by the EventAdmin, and if I need to consider the same factors when selecting my event mechanism.

It seems like duplicated work.

One possibility I'd considered was that the OSGi Alliance didn't want to make the services defined in the Compendium, depend on other Compendium services, based on the fact that the ConfigurationAdmin has no problem depending on the Service registry, which is defined in Core.

This seems to line up in my mind with the understanding that services are not guaranteed to exist at runtime; therefore making ConfigurationAdmin depend on EventAdmin would equate to "You cannot use this optional service (ConfigurationAdmin) unless this other optional service (EventAdmin) is guaranteed to be in the runtime as well" which is kind of contradictory.

Upvotes: 2

Views: 68

Answers (1)

Peter Kriens
Peter Kriens

Reputation: 15372

There are several reasons:

  • Configuration Admin was designed before Event Admin
  • A type safe event interface like Configuration Admin is easier to use than using properties
  • As you figured out, it is not nice if services depend on each other. Implementations should be able to freely chose services and not be artificially constrained.

Upvotes: 3

Related Questions