Блог

Я хочу понять, почему спецификация ConfigurationAdmin определяет свой собственный механизм отправки событий вместо использования спецификации EventAdmin, которая также определена в сборнике OSGi.

В спецификации ConfigurationAdmin упоминается, что он будет отправлять ConfigurationEvents в ConfigurationListeners, зарегистрированные в реестре служб.

Прослушиватель событий конфигурации. Когда запускается ConfigurationEvent, оно асинхронно доставляется всем ConfigurationListeners.

Объекты ConfigurationListener регистрируются в реестре службы Framework и уведомляются объектом ConfigurationEvent при запуске события. Объекты 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 Alliance создать отдельный механизм событий для ConfigurationAdmin вместо уже созданного механизма событий, предоставляемого EventAdmin, и нужно ли мне учитывать те же факторы при выборе моего механизма событий.

Это похоже на дублированную работу.

• EventAdmin может отправлять события синхронно или асинхронно ( sendEvent и postEvent ) и уже предоставляет интерфейс для реагирования на события ( EventHandler ).
• ConfigurationAdmin отправляет ConfigurationEvents асинхронно или синхронно в зависимости от интерфейса, используемого для ответа на событие ( ConfigurationListener , SynchronousConfigurationListener ), а не вызываемого метода.

Одна из возможностей, которую я рассматривал, заключалась в том, что Альянс OSGi не хотел, чтобы службы, определенные в Compendium, зависели от других служб Compendium, основываясь на том факте, что у ConfigurationAdmin нет проблем с зависимостью от реестра служб, который определен в Core.

На мой взгляд, это согласуется с пониманием того, что существование сервисов не гарантируется во время выполнения; поэтому создание зависимости ConfigurationAdmin от EventAdmin было бы равносильно «Вы не можете использовать эту дополнительную службу (ConfigurationAdmin), если эта другая дополнительная служба (EventAdmin) также гарантированно находится во время выполнения», что отчасти противоречиво.

Есть несколько причин:

• Configuration Admin был разработан до Event Admin
• Типобезопасный интерфейс событий, такой как Configuration Admin, проще в использовании, чем использование свойств
• Как вы поняли, нехорошо, если службы зависят друг от друга. Реализации должны иметь возможность свободно выбирать сервисы и не быть искусственно ограничены.