Question

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

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

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

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取决于用于响应事件的接口（ConfigurationListener，SynchronousConfigurationListener）（而不是所调用的方法）异步或同步发送ConfigurationEvent。

我考虑过的一种可能性是，OSGi联盟不想让在Compendium中定义的服务依赖于其他Compendium服务，这是基于ConfigurationAdmin根据服务注册表而没有问题的事实，在Core中定义。

这似乎与我的想法一致，即不能保证服务会在运行时存在。因此，使ConfigurationAdmin依赖于EventAdmin等同于“除非确保其他可选服务（EventAdmin）也在运行时，否则您不能使用此可选服务（ConfigurationAdmin）”。

Answer 1

有几个原因：

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

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

1 个答案: