OSGi 配置管理服务答案

【问题标题】：OSGi ConfigurationAdmin ServiceOSGi 配置管理服务
【发布时间】：2017-07-20 18:09:42
【问题描述】：

似乎有两种方法可以从 OSGi 服务注册表获取配置管理服务。一种是通过实例化 BundleContext，然后从中获取 ServiceReference，然后从中获取 ConfigurationAdmin：

BundleContext bc = FrameworkUtil.getBundle(ManagedService.class).getBundleContext();
ServiceReference ca = bc.getServiceReference(ConfigurationAdmin.class);
ConfigurationAdmin configAdmin = (ConfigurationAdmin) context.getService(ca);

另一种方法是使用蓝图并简单地创建对 ConfigurationAdmin 的引用，如下所示，然后在 bean 中引用它：

<reference id="configAdmin" interface="org.osgi.service.cm.ConfigurationAdmin" />

这两种方法是否等效？还是前一种方法提供了后者没有的东西？是否有任何 Blueprint 参考文档描述了实例化 ConfigurationAdmin 的操作（似乎找不到）？

【问题讨论】：

标签： osgi blueprint-osgi

【解决方案1】：

这些不是“实例化”配置管理服务。它们是从 OSGi 服务注册表获取 Configuration Admin 服务的服务对象的方法。两种方式都将返回相同的服务对象。第一种方式使用低级 OSGi API 与 OSGi 服务注册表交互。第二种方式使用蓝图。

关于蓝图，我建议在 OSGi 中使用声明式服务进行依赖注入。

【讨论】：

生成的 configAdmin 对象是否等效？
没试过DS。这是否提供了一种类似的简单方法来获取配置管理服务对象？
@JWoodchuck 不，这并不容易。这更容易。

【解决方案2】：

通常，您会获得与蓝图、DS 或低级 API 相同的服务对象。

但问题是您用于低级 API 的简单方法在 OSGi 中效果不佳。在 OSGi 中，服务和包可以随时来来去去。

所以正确的代码应该总是对被删除的服务做出反应。你不应该长时间持有服务对象而不对被删除的服务做出反应。

另一件事是您可能依赖于您获得的服务。因此，您必须应对启动 Activator 时服务可能不存在的事实。

当您将其扩展到捆绑提供和使用的少数服务时，几乎不可能使用低级 API 正确实现。

所以我强烈建议您使用蓝图或 DS。最近我尝试尽可能使用 DS，因为它可以以最好的方式应对 OSGi 的动态。它使编写正确的 OSGi 代码变得非常容易。

【讨论】：