Java 在UI元素上使用OSGi DS是一种好的实践吗？

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

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

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

UI元素由我使用的框架自动生成。访问服务的唯一方法是

BundleActivator

或静态方法

FrameworkUtil.getBundle（）

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

---

另一个解决方案是使用ApacheFelix提供的scr注释。将UI元素标记为

@Component

，并通过

@Reference

引用每个所需的服务将起作用。但这是一种好的做法吗？我应该注释它们吗？我一直认为

@Component

引用的类是由OSGi本身管理的，并且总是由OSGi实例化和

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

例如，您可以轻松地使用和跟踪针对特定接口公开的所有服务

---

对于注释，我确实认为争论更多的是“注释与配置文件”，而不是OSGi。我个人认为，在将实现与其他API绑定在一起的入侵注释和其他解决方案（如外部.xml配置文件）之间进行选择是一个问题。但最终，这是一个比OSGi更大的讨论。请参阅。

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