为什么 ConfigurationAdmin 规范使用它自己的事件机制，而不是 EventAdmin？

Question

我想了解为什么 ConfigurationAdmin 规范定义了自己的事件调度机制，而不是使用在 OSGi Compendium 中也定义的 EventAdmin 规范。

ConfigurationAdmin 规范提到它将 ConfigurationEvents 发送到在服务注册表中注册的 ConfigurationListeners。

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.

鉴于 ConfigurationEvent 的属性都是原始的，这似乎是 EventAdmin 的一个很好的候选者。

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) {
        // ...
    }
}

我正在设计一些使用某种事件处理机制的服务。我认为我的选择是使用 EventAdmin（在 Compendium 中提供），并滚动我自己的（如 ConfigurationAdmin）。

我想知道是什么设计决定导致 OSGi 联盟为 ConfigurationAdmin 创建一个单独的事件机制，而不是 EventAdmin 提供的已经创建的事件机制，如果我需要考虑选择我的事件机制时的相同因素。

好像是重复的工作。

EventAdmin 可以同步或异步发送事件（sendEvent 和postEvent），并且已经提供了响应事件的接口（EventHandler）。
ConfigurationAdmin 异步或同步发送 ConfigurationEvents 取决于用于响应事件的接口（ConfigurationListener、SynchronousConfigurationListener），而不是调用的方法。

我考虑过的一种可能性是 OSGi 联盟不想让 Compendium 中定义的服务依赖于其他 Compendium 服务，基于 ConfigurationAdmin 没有问题的事实，具体取决于服务注册表, 定义在 Core.

这似乎符合我的理解，即服务不能保证在运行时存在；因此让 ConfigurationAdmin 依赖于 EventAdmin 等同于 "You cannot use this optional service (ConfigurationAdmin) unless this other optional service (EventAdmin) is guaranteed to be in the runtime as well" 这有点矛盾。

Answer 1

有几个原因：

配置管理是在事件管理之前设计的
像 Configuration Admin 这样的类型安全的事件接口比使用属性更容易使用
如您所见，服务相互依赖并不好。实现应该能够自由选择服务，而不是人为地限制。

为什么 ConfigurationAdmin 规范使用它自己的事件机制，而不是 EventAdmin？

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

osgi