我想理解为什么 ConfigurationAdmin 规范定义了自己的调度事件机制，而不是使用 EventAdmin 规范，该规范也在 OSGi Compendium 中定义。
ConfigurationAdmin 规范提到它将 ConfigurationEvents 发送到在服务注册表中注册的 ConfigurationListeners。
配置事件的侦听器。触发配置事件时，它将异步传递 到所有配置侦听器。
配置侦听器对象在框架服务注册表中注册并收到通知 触发事件时使用配置事件对象。 ConfigurationListener 对象可以检查收到的 ConfigurationEvent。
这似乎是 EventAdmin 的一个很好的候选者，因为 ConfigurationEvent 的属性都是原始的。
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(在纲要中提供)，并滚动我自己的(如ConfigurationAdmin)。
我想知道是什么设计决策导致OSGi联盟为ConfigurationAdmin创建了一个单独的事件机制，而不是由EventAdmin提供的已经创建的事件机制，以及我在选择事件机制时是否需要考虑相同的因素。
这似乎是重复的工作。
事件- 管理员可以同步或异步发送事件(
sendEvent和postEvent)，并且已经提供了一个响应事件的接口(EventHandler)。
ConfigurationAdmin 以 - 异步或同步方式发送 ConfigurationEvents，具体取决于用于响应事件的接口(
ConfigurationListener、SynchronousConfigurationListener)，而不是调用的方法。
我考虑过的一种可能性是，OSGi联盟不想使纲要中定义的服务依赖于其他纲要服务，基于配置管理员没有问题的事实依赖于核心中定义的服务注册表。
这似乎与服务不能保证在运行时存在的理解相一致;因此，让 ConfigurationAdmin 依赖于 EventAdmin 等同于"你不能使用此可选服务 (ConfigurationAdmin)，除非这个其他可选服务 (EventAdmin) 也保证在运行时中"，这有点矛盾。
有几个原因：
- 配置管理员是在事件管理之前设计的
- 类型安全事件接口(如配置管理员)比使用属性更易于使用
- 正如您所发现的，如果服务相互依赖，那就不好了。实现应该能够自由选择服务，而不是人为地限制。