Являются ли отдельные пакеты OSGI для обычной практики api и внедрения?

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

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

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

Это лучший способ достичь этого?

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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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