我目前正在编写一个在 OSGi 环境中运行的应用程序。
对于可视化部分，我使用 JavaFX。每个 UI 元素都是一个扩展 BorderPane 的可停靠 View 。其内容使用 fxml 文件中的 fx:root 元素进行描述。其中一些 UI 元素需要访问 OSGi 容器内的服务(例如， View 中的按钮可能会触发需要引用 PersistenceService 的保存操作)。
实现这一目标的最佳方法是什么？
UI 元素是由我使用的框架自动生成的。访问服务的唯一方法是 BundleActivator 或静态方法 FrameworkUtil.getBundle()。
我的方法是使用静态实用程序方法，但在网上阅读了更多内容后，我意识到您通常不想针对 OSGi 本身进行编码。
另一个解决方案是使用 Apache Felix 提供的 scr 注释。将 UI 元素标记为 @Component 并通过 @Reference 引用每个所需的服务就可以了。但这是好的做法吗？我应该注释它们吗？我总是认为 @Component 引用的类是由 OSGi 本身管理的，并且总是由 OSGi 实例化。
最佳答案
首先，如果您想直接在Java代码中声明/引用您的服务，您应该考虑使用 ServiceTracker以避免 ServiceReference 本质上的许多问题。
SCR 注解是一种很好的方法，另一种方法(对于已经使用 Spring 或 Blueprint 的遗留项目更友好)是直接使用 Blueprint或者如果你想要 spring 功能 spring osgi compendium并注入(inject)bean <service>和<reference>使用标准注释 @Named/@Component、@Inject/@Autowired。
最后一个选项的主要好处是 Karaf 等容器可以自动加载 spring 配置(考虑到它位于 META-INF/spring/*.xml 文件中)并注册/引用服务。
例如，您可以轻松实现 whiteboard pattern与 blueprint reference-list并跟踪为特定接口(interface)公开的所有服务。
对于注释，我确实认为争论更多的是“注释与配置文件”，而不是与 OSGi 相关。我个人认为这是一个将您的实现与其他 API 绑定(bind)的侵入式注释与其他解决方案(例如外部 .xml 配置文件，侵入性较小)之间的选择问题。但最终，它比 OSGi 更值得讨论。请参阅this other thread .
关于java - 在 UI 元素上使用 OSGi DS 是一个好习惯吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/36022656/