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

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

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

配置事件的侦听器。触发ConfigurationEvent时，将异步传递该事件 发送给所有ConfigurationListeners

ConfigurationListener对象在框架服务注册表中注册并得到通知 触发事件时使用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) {
        // ...
    }
}

val事件：事件=事件（哈希表（mapOf(
“类型”至CM_已更新，
“service.factoryPid”到“someFactoryPid.guid”，
“service.pid”到“somePid.guid”
)))
@组成部分
类ConfigurationListener:EventHandler{
覆盖趣味handleEvent（事件：事件）{
// ...
}
}

我正在设计一些使用某种事件处理机制的服务。我认为我可以选择使用EventAdmin（在概要中提供），也可以选择使用我自己的（比如ConfigurationAdmin）

我想知道是什么导致OSGi联盟做出了一个单独的事件机制来建立配置管理，而不是由EvestAdmin提供的已经创建的事件机制，如果我在选择我的事件机制时需要考虑相同的因素。 这似乎是重复的工作

• EventAdmin可以同步或异步发送事件（

  sendEvent

  和

  postEvent

  ），并且已经提供了响应事件的接口（

  EventHandler

  ）
• ConfigurationAdmin异步或同步发送ConfigurationEvents，具体取决于用于响应事件的接口（

  ConfigurationListener

  ，

  SynchronousConfigurationListener

  ），而不是调用的方法

我考虑过的一种可能性是，OSGi联盟不想让概要中定义的服务依赖于其他概要服务，因为ConfigurationAdmin依赖于核心中定义的服务注册中心没有问题

---

这似乎符合我的理解，即服务不保证在运行时存在；因此，使ConfigurationAdmin依赖于EventAdmin将等同于“您不能使用此可选服务（ConfigurationAdmin），除非此其他可选服务（EventAdmin）也保证在运行时”，这有点矛盾。

有几个原因：

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