Разумно ли использовать разные уровни запуска для управления зависимостями между пакетами OSGi?

Моя команда пытается разработать новую систему на основе OSGi, и теперь у нас более 50 комплектов, и их количество растет. Проблема в том, что между связками существует зависимость. Например, при запуске пакета A он зарегистрирует службу в OSGi, а при запуске пакета B он будет использовать эту службу. Поэтому мне нужен запуск пакета A раньше, чем пакета B. Чтобы это произошло, я установил начальный уровень пакета A меньше, чем пакет B.

Мы пытались использовать ServiceTracker, чтобы не устанавливать начальные уровни, но когда количество сервисов растет, становится трудно управлять и понимать всю систему.

Однако я нашел в Интернете эту статью: OSGi и начальные уровни. Я не уверен, что в нем есть два предложения:

  • Порядок старта в пределах начального уровня не определен!
  • Вообще, при работе со стартовыми уровнями никогда не зависеть от порядка старта. Думайте об уровнях запуска как о проблеме управления, а не о времени разработки.

Означает ли это, что стартовый уровень не будет определять порядок старта? Тогда когда мне его использовать?

Разумно ли использовать разные уровни запуска для управления зависимостями между пакетами OSGi?

Можно сделать все пакеты динамическим модулем (используйте ServiceTracker для отслеживания всех используемых им сервисов), но это требует больше времени и требует старших разработчиков, и систему становится трудно отлаживать.


person Chase Fang    schedule 01.07.2011    source источник


Ответы (3)


Мой ответ аналогичен ответу Бертрана: вам следует подумать об использовании абстракции на основе компонентов более высокого уровня для вашего решения: SCR, iPOJO, Blueprint и т. Д.

Использование начальных уровней для управления зависимостями немного похоже на использование приоритетов потоков в Java для исправления состояния гонки. Конечно, вы можете заставить что-то работать, вроде как, какое-то время, но в процессе вы сойдете с ума - и в конечном итоге все равно проиграете.

Начальные уровни полезны. Канонический пример - если вам нужно отобразить экран-заставку при запуске приложения с графическим интерфейсом на основе OSGi, поместив его код в пакет. Без начальных уровней невозможно гарантировать, что экран-заставка будет отображаться, когда он должен быть, но при использовании начальных уровней это становится тривиальным.

Тем не менее, я использовал начальные уровни для устранения ошибок упорядочивания зависимостей, обнаруженных в сторонних пакетах (например, Spring), хотя это не связано с упорядочиванием услуг, а с предположениями о поиске ресурсов (с Spring, XSD для настраиваемой интеграции Spring). пространство имен).

person Richard Steele    schedule 02.07.2011
comment
Моя команда использовала начальные уровни для решения аналогичных задач. Это отличный способ найти проблемы, и это полезное краткосрочное решение, если у вас нет времени на немедленное устранение основной проблемы. - person Jon7; 04.07.2011
comment
+1 к ответу rsteele. В зависимости от начального заказа вводит крайнюю хрупкость. Другой вариант использования начальных уровней - это оптимизация. Ваши пакеты должны всегда РАБОТАТЬ независимо от того, в каком порядке они запускаются ... однако иногда пакету может потребоваться больше или меньше работы в зависимости от его порядка запуска. Таким образом, вы можете использовать начальные уровни для оптимизации производительности вашего приложения, но не зависите от них в плане реальной функциональности. - person Neil Bartlett; 04.07.2011
comment
Спасибо, Нил. Я не рассматривал вопрос эффективности, но это имеет большой смысл. - person Richard Steele; 05.07.2011

Использование начальных уровней для управления зависимостями между службами - плохая идея - среда выполнения компонентов служб (SCR) - гораздо лучший способ управления этим, и, если все сделано правильно, позаботится обо всех зависимостях, порядке запуска, перезапуске компонентов, когда требуются их службы. перезапускаются и т. д.

Если вы используете Maven, подключаемый модуль Apache Felix SCR (http://felix.apache.org/site/scr-annotations.html) упрощает создание служб, управляемых SCR, с помощью всего лишь нескольких аннотаций Java. Код Apache Sling (http://sling.apache.org) полон примеров, использующих это.

person Bertrand Delacretaz    schedule 02.07.2011
comment
Мы не используем Maven, и мы используем Equinox вместо felix. Есть еще предложения? - person Chase Fang; 13.08.2011
comment
Equinox не должен иметь никакого значения в отношении SCR, и если вы не используете Maven, вы можете использовать Bnd напрямую (aqute.biz/Bnd/Bnd) - это то, что плагины Maven, о которых я упоминал, используют под капотом. - person Bertrand Delacretaz; 10.01.2013

Хорошее резюме о начальном уровне / проблеме зависимости, которое объясняет, почему вам следует избегать определения зависимостей между вашими пакетами с начальными уровнями.

http://wiki.osgi.org/wiki/Avoid_Start_Order_Dependencies

person Come get some    schedule 21.12.2012