在UI元素上使用OSGi DS是一种好的做法吗？

Question

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

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

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

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

我的方法是使用静态实用程序方法，但是在网上阅读了一些之后，我意识到您通常不希望针对OSGi本身编写代码。

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

Answer 1

首先，如果您想要在Java Code中直接声明/引用您的服务，那么您应该考虑使用ServiceTracker来避免许多ServiceReference性质的问题。

SCR注解是一个很好的方法，另一个(对已经使用Spring或Blueprint的遗留项目更友好)是直接使用Blueprint，或者如果你想要spring功能spring osgi compendium，并用你的标准注解@ <service> /@Component，@ inject /@Autowired注入beans <service>和<reference>。

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

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

对于注解，我确实认为争论更多的是“注解还是配置文件”，而不是OSGi。我个人认为这是一个介入式注解之间的选择问题，这些注解将您的实现与其他.xml绑定在一起，而其他解决方案(如外部API配置文件)的介入性会更小。但归根结底，这更像是一个大讨论，而不是OSGi。参见this other thread。