Являются ли отдельные пакеты OSGI для API и реализации распространенной практикой? - PullRequest
16 голосов
/ 22 июня 2011

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

Изначально я создал один пакет с экспортированным интерфейсом и зарегистрировал реализацию, используя классы активатора и реализации, которые не были экспортированы.Однако, если я обновляю пакет, пакеты, использующие зарегистрированную службу, перезапускаются после обновления при вызове PackageAdmin # refreshPackages (это автоматически при использовании fileinstall).

Я исправил это, создав отдельный пакет API..

Это лучший способ для достижения этой цели?

Будет ли у вас когда-нибудь пакет, экспортирующий его API и включающий реализацию в тот же пакет.Насколько я вижу, любой пакет bundle будет экспортировать все свои классы или вообще не будет.Чего мне не хватает?

Ответы [ 3 ]

20 голосов
/ 22 июня 2011

Лучше всего отделить пакеты API от их реализаций в OSGi.Если вы сделаете это, то любой пакет, который использует API, должен импортировать только классы из пакета API, что может позволить вам изменять реализации во время выполнения без перезапуска зависимых пакетов.

В идеале ваш пакет реализации должен реализовывать интерфейс и экспортировать реализацию как службу на предоставляемом API-интерфейсе.Это позволяет клиентским пакетам использовать службу без ссылки на пакет реализации.

9 голосов
/ 22 июня 2011

В Apache Sling мы делаем и то и другое: основные API находятся в своих собственных пакетах, но для более мелких вещей, таких как расширения или дополнительные компоненты, мы часто предоставляем реализацию по умолчанию в том же пакете, что и API.

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

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

0 голосов
/ 11 мая 2013

Если нет жестких требований, чтобы иметь возможность заменить реализацию во время выполнения, без перезапуска клиентских пакетов, я лично рекомендовал бы сохранять явную связь зависимости между API и реализацией (либо путем включения классов impl в пакет API, либо спакеты реализации импорта пакета API из пакета impl.).

ПБ с шаблонами, предложенными выше, состоит в том, что они разрывают цепочку зависимостей.Преимущества управления зависимостями выходят далеко за рамки простой API-совместимости, они также включают в себя обеспечение предсказуемого, согласованного поведения во время выполнения, а также совместимость с экосистемой развертывания, и все это требует управления зависимостями реализации.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...