Хорошо ли использовать OSGi DS для элементов пользовательского интерфейса?

Question

В настоящее время я пишу приложение, работающее в среде OSGi.

Для части визуализации я использую JavaFX. Каждый элемент пользовательского интерфейса является прикрепляемым представлением, которое расширяет BorderPane. Его содержимое описывается с использованием элемента fx: root в файле fxml. Некоторым из этих элементов пользовательского интерфейса необходимо обращаться к службам в контейнере OSGi (например, кнопка в представлении может инициировать действие сохранения, которое требует ссылки на PersistenceService).

Каков наилучший способ достичь этого?

Элементы пользовательского интерфейса автоматически генерируются каркасом, который я использую. единственным способом доступа к услугам являются BundleActivator или статический метод FrameworkUtil.getBundle().

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

Другое решение использует аннотации scr, предоставленные Apache Felix. Маркировка элементов пользовательского интерфейса как @Component и обращение к каждой необходимой службе через @Reference будет работать. Но разве это хорошая практика? Должен ли я их комментировать? Я всегда, хотя классы, на которые ссылаются @Component, управляются OSGi и всегда будут создаваться OSGi.

Answer 1

Прежде всего, если вы хотите объявить/ссылаться на свои услуги непосредственно в Java-коде, вам следует использовать , чтобы избежать многих проблем с характером ServiceReference.

SCR аннотации хороший способ сделать это, другой (который является более дружественным со старыми проектами, которые уже используют Spring или Blueprint) является использование непосредственно Blueprint или если вы хотите функциональность пружины spring osgi compendium и впрыснуть бобы <service> и <reference> с ваши стандартные аннотации @ Named/@ Component, @ Inject/@ Autowired.

Главное преимущество этой последней опции заключается в том, что контейнеры, такие как Karaf, могут автоматически загружать вашу конфигурацию пружины (учитывая, что она находится в файлах META-INF/spring/*. Xml) и регистрации/справочных услуг.

Вы можете, например, легко реализовать whiteboard pattern с помощью blueprint reference-list и отслеживать все предоставляемые услуги для определенного интерфейса.

Для аннотаций, я думаю, что дебаты больше касаются «аннотаций и файлов конфигурации», чем связанных с OSGi. Я лично считаю, что это вопрос выбора между навязчивыми аннотациями, которые связывают вашу реализацию с другими API-интерфейсами, в то время как другое решение (например, внешние файлы конфигурации .xml) будет менее навязчивым). Но, в конце концов, это большая дискуссия, чем OSGi. См. this other thread.