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

Question

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

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

配置事件的监听器。当触发ConfigurationEvent时，它将异步传递给所有ConfigurationListener。

ConfigurationListener对象向Framework服务注册表注册，并在触发事件时通过ConfigurationEvent对象通知。 ConfigurationListener对象可以检查收到的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联盟不希望根据ConfAdndium服务定义的服务，依赖于其他Compendium服务，这取决于ConfigurationAdmin没有问题，具体取决于Service注册表，核心。

这似乎在我的脑海中排列，理解是服务不能保证在运行时存在;因此，使ConfigurationAdmin依赖于EventAdmin将等同于“您不能使用此可选服务（ConfigurationAdmin），除非保证其他可选服务（EventAdmin）也在运行时”，这是一种矛盾。

Answer 1

有几个原因：

• Configuration Admin是在Event Admin之前设计的
• 像Configuration Admin这样的类型安全事件接口比使用属性更容易使用
• 如你所知，如果服务相互依赖，那就不好了。实现应该能够自由选择服务而不是人为约束。