Не может найти сервис, потому что пакет OSGi не активируется
У меня есть проблема при обнаружении услуг, которые предоставляются некоторыми пакетами OSGi, которые не активируются. Позвольте мне описать ситуацию:
- Пакет A определяет интерфейс X
- Пакеты B, C, и D предоставляют услуги, с которыми та реализация соединяет интерфейсом X
- Сервисы этих пакетов регистрируются через Spring DM, таким образом, они только создаются, когда пакет активируется и Spring, DM инициализировал контекст приложения, определенный в пакете
- Пакет A активируется и в какой-то момент просит у реестра сервисов сервисы для интерфейса X. Это не находит никого, потому что пакеты B, C, и D не были перемещены в АКТИВНОЕ состояние (они только РАЗРЕШЕНЫ).
Я, может казаться, не заставляю пакеты B, C, или D запускать, и поэтому регистрировать свои сервисы. Принуждение их запуститься путем добавления их к config.ini не опция, потому что может быть любое количество пакетов, которые установлены в приложении (через Eclipse подобный p2 механизм обновления), та реализация взаимодействует через интерфейс X.
Приложением является Eclipse приложение RCP на основе 3.5, с помощью Spring 2.5.6 и Spring DM 1.2.1.
Как я вынуждаю эти пакеты быть активированными?
3 ответа
То, что у вас на самом деле есть проблема иерархии зависимостей, ваше предлагаемое хакерское решение на самом деле является всего лишь пластырем для решения лежащей в основе проблемы.
Что вам действительно следует учитывать, так это архитектуру вашей системы, так же эффективно, как и то, что у вас есть - это круговая зависимость (о: обсуждении в комментариях к вашему первоначальному сообщению). У вас есть (нравится вам это или нет) A требует обслуживания от (и в некотором смысле зависит от) B и C. Между тем, B и C напрямую зависят от A, и поэтому не может начать, пока не появится A.
В лучшем случае можно написать код в В и С, чтобы прослушать существование А, но это в лучшем случае маскирует (как я уже упоминал) основную проблему. На самом деле, следует подумать о том, чтобы разделить А на две связки, назовем их А1 и А2.
А1 должен обеспечивать интерфейс, который требуется (зависит от) от В и С. У A2 должны быть слушатели для сервисов, от которых зависят B и C. При запуске, если B и C являются требуемыми сервисами, A1 должен быть запущен, но A2 может начать работу в любое время позже, и все должно работать.
Я думаю, что нашел решение этой проблемы, хотя это кажется немного хакерским.
Я наткнулся на этот поток , где Адриан Колер подразумевал, что внешний "наблюдатель за пучками" может отвечать за активацию пучков, когда они устанавливаются во фреймворк.
Итак, моим решением было:
- добавить пользовательский заголовок в соответствующие манифесты пакета B, C и D, например, "MyApp-AutoStart: true"
- Создайте слушатель пакета, который отвечает, когда пакет переходит в состояние RESOLVED, и ищет заголовок
- Если значение заголовка "true", слушатель пакета вызывает
bundle.start()
Используя этот метод, пакеты, которые я хочу запустить, запускаются без необходимости прибегать к использованию config.ini, и они могут приходить и уходить, как им заблагорассудится, но их сервисы будут доступны при запросе.
Также посмотрите на файл felix fileinstall, который просматривает каталог пакетов, автоматически устанавливает и запускает их. Когда файл удаляется, пакет также останавливается и удаляется.