在 UI 元素上使用 OSGi DS 是一种好习惯吗？答案

【问题标题】：Is it good practice to use OSGi DS on UI elements?在 UI 元素上使用 OSGi DS 是一种好习惯吗？
【发布时间】：2016-07-01 13:32:33
【问题描述】：

我目前正在编写一个在 OSGi 环境中运行的应用程序。

对于可视化部分，我使用的是 JavaFX。每个 UI 元素都是扩展 BorderPane 的可停靠视图。其内容使用 fxml 文件中的 fx:root 元素进行描述。其中一些 UI 元素需要访问 OSGi 容器中的服务（例如，视图中的按钮可能会触发需要引用 PersistenceService 的保存操作）。

实现这一目标的最佳方法是什么？

UI 元素由我使用的框架自动生成。访问服务的唯一方法是BundleActivator 或静态方法FrameworkUtil.getBundle()。

我的方法是使用静态实用程序方法，但在网上阅读了更多内容后，我意识到您通常不想针对 OSGi 本身编写代码。

另一种解决方案是使用 Apache Felix 提供的 scr 注释。将 UI 元素标记为 @Component 并通过 @Reference 引用每个需要的服务都可以。但这是好的做法吗？我应该注释它们吗？我一直认为@Component 引用的类是由OSGi 本身管理的，并且总是由OSGi 实例化。

【问题讨论】：

标签： java javafx osgi apache-felix osgi-bundle

【解决方案1】：

首先，如果您想直接在 Java 代码中声明/引用您的服务，您应该考虑使用 ServiceTracker 以避免很多与 ServiceReference 的性质有关的问题。

SCR Annotations 是一个很好的方法，另一个（对已经使用 Spring 或 Blueprint 的遗留项目更友好）是直接使用 Blueprint 或者如果你想要 spring 功能 spring osgi compendium 并注入 beans @ 987654327@ 和 <reference> 与您的标准注释 @Named/@Component、@Inject/@Autowired。

最后一个选项的主要好处是，像 Karaf 这样的容器可以自动加载你的 spring 配置（考虑到它在 META-INF/spring/*.xml 文件中）和注册/引用服务。

例如，您可以使用blueprint reference-list 轻松实现whiteboard pattern，并跟踪针对特定接口公开的所有服务。

对于注释，我确实认为争论更多是关于“注释与配置文件”，而不是与 OSGi 相关。我个人认为，在将您的实现与其他 API 绑定的侵入式注释之间进行选择是一个问题，而其他解决方案（例如外部 .xml 配置文件，侵入性较小）。但归根结底，它比 OSGi 更像是一个大型讨论。见this other thread。

【讨论】：

谢谢！ ServiceTracker 看起来不错。不过，这并没有回答我的最后一个问题。 ServiceTracker 可以毫无疑问地解决这个问题，但我仍然很好奇注释 UI 元素是否是好的做法。但是 Spring 可以只注入 bean 对吗？
现在是 2016 年，建议直接使用 ServiceTracker 或 Spring DM 而不是声明式服务似乎不是一个好建议，至少从我的角度来看 ;-)
我同意@JérémieB。 ServiceTracker 是非常底层的，它将你的代码直接耦合到 OSGi，它很难正确使用并且很难测试。请使用带有标准注释的 DS。
谢谢。顺便说一句，我会避免使用 Felix 的遗留 SCR 注释并使用 OSGi 规范中的标准注释。
限制是 DS 拥有该类及其生命周期。这是必要的，因为如果您注入的服务消失并且您有强制引用，那么您的组件也必须消失。