OSGi ConfigurationAdmin服务

时间:2017-07-20 18:09:43

标签: osgi blueprint-osgi

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

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

另一个是使用Blueprint并简单地创建对ConfigurationAdmin的引用,如下所示,然后在bean中引用它:

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

这两种方法是否相同?或者前者的方法是否提供后者没有的任何东西?是否有任何Blueprint参考文档描述了它为实例化ConfigurationAdmin所做的工作(似乎找不到任何东西)?

2 个答案:

答案 0 :(得分:5)

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

关于Blueprint,我建议在OSGi中使用Declarative Services进行依赖注入。

答案 1 :(得分:1)

通常,您使用蓝图,DS或低级API获得相同的服务对象。

问题是,用于低级API的简单方法在OSGi中运行不佳。在OSGi中,服务以及捆绑包可以随时进出。

因此,正确的代码应始终对正在删除的服务做出反应。您不应该在较长时间内持有服务对象而不对要删除的服务做出反应。

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

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

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