Разумно ли использовать разные начальные уровни для управления зависимостями между пакетами OSGi? - PullRequest
7 голосов
/ 01 июля 2011

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

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

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

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

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

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

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

Ответы [ 3 ]

9 голосов
/ 02 июля 2011

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

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

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

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

7 голосов
/ 02 июля 2011

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

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

1 голос
/ 21 декабря 2012

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

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

...