Получить декларативный сервис во время выполнения

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

Вариант использования аналогичен 3 пакетам, предоставляющим услуги версии 1.0, 2.0 и 3.0, но неизвестно, какой из них будет использоваться, пока пользователь не выберет один в пользовательском интерфейсе. Если пользователь выберет версию 2.0, потребитель будет потреблять продукты из пакета 2.0.

Мы используем аннотации BND, поэтому что-то с ними было бы идеально, но у меня есть ощущение, что нам нужно использовать OSGi API напрямую, а не использовать аннотации или декларативное внедрение сервисов.

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


java osgi declarative-services
person Hilikus    schedule 17.03.2014    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я работал в похожей системе раньше, и у нас была своя система «маршрутизации». В основном, когда вы регистрируете службы, добавьте номер версии в метаданные. Затем в этом механизме маршрутизации выберите правильный сервис. Ваши сервисы должны будут реализовать общий интерфейс, а в маршрутизаторе внедрить List из них.

person codesalsa    schedule 17.03.2014
comment
то есть вы имеете в виду службу, которая просто получает уведомление обо всех других зарегистрированных службах, а затем эта служба, которую вы называете механизмом маршрутизации, предоставит список всех накопленных служб через список? если это то, что вы имели в виду, дело в том, что я полагаю, что эта система маршрутизации - это просто реестр служб, который, как я полагаю, уже должен существовать в среде OSGi. - person Hilikus; 18.03.2014
comment
Ну, проблема в том, что во время выполнения вы хотите, чтобы все версии были доступны, и выбирали на основе запроса от пользователя, поэтому мы решили это. Маршрутизатор не предоставляет список, у него есть список. Он получает запрос, а затем возвращает правильную версионную реализацию для использования. - person codesalsa; 18.03.2014

arrow_upward
1
arrow_downward

Декларативная модель спецификации декларативных служб — это модель времени сборки, а не времени выполнения. Чтобы управлять зависимостями во время выполнения, вам нужно либо сделать это самостоятельно с помощью ServiceTracker, либо использовать другое решение для управления зависимостями.

Как один из его авторов, я предпочитаю менеджер зависимостей Apache Felix [1], который позволяет вам «объявлять» зависимости в коде Java (во время выполнения, например, на основе выбора, сделанного пользователем в пользовательском интерфейсе, например вы говорите). Он не использует аннотации Bnd, но код по-прежнему позволяет вам использовать декларативный стиль и предоставляет такие функции, как внедрение и/или обратные вызовы.

Другое решение, позволяющее это сделать, — Apache Felix iPOJO [2].

[1] http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html

[2] http://felix.apache.org/documentation/subprojects/apache-felix-ipojo.html

person Marcel Offermans    schedule 17.03.2014
comment
в настоящее время мы рассматриваем iPojo. что именно из этого может быть использовано для принятия этого решения во время выполнения. Я также рассмотрю Dependency Manager - person Hilikus; 18.03.2014
comment
Я не очень знаком с ним, но я понял, что (некоторое время назад) он добавил поддержку объявления зависимостей через Java API, как и менеджер зависимостей. - person Marcel Offermans; 18.03.2014