Я хочу понять, почему спецификация ConfigurationAdmin определяет свой собственный механизм для отправки событий вместо использования спецификации EventAdmin, которая также определена в OSGi Compendium.
В спецификации ConfigurationAdmin упоминается, что она будет отправлять ConfigurationEventsк ConfigurationListeners, зарегистрированным в реестре служб.
Слушатель событий конфигурации.Когда запускается ConfigurationEvent, он асинхронно доставляется всем ConfigurationListener.
Объекты 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, основанные на том факте, что ConfigurationAdmin не имеет проблем в зависимости от реестра Сервиса, который определен в Core.
Мне кажется, это согласуется с пониманием того, что сервисы не гарантированно существуют.во время выполнения;поэтому зависимость ConfigurationAdmin от EventAdmin будет означать «Вы не можете использовать эту дополнительную службу (ConfigurationAdmin), если эта другая дополнительная служба (EventAdmin) также не гарантированно находится во время выполнения», что является своего рода противоречивым.