用于配置服务的 OSGi 声明式服务与 ManagedService？答案

【问题标题】：OSGi Declarative Services vs. ManagedService for configuring service?用于配置服务的 OSGi 声明式服务与 ManagedService？
【发布时间】：2011-05-01 13:04:47
【问题描述】：

我最近偶然发现，OSGi 中的声明式服务可以将组件的配置设置为必需的，以便组件在激活时接收它，从而消除组件激活和配置之间的差距。我还意识到，您可以通过modified-方法接收配置更新。

在我看来，此功能与通过实现 ManagedService 接口并将其作为您提供的“服务”之一发布所提供的功能非常相似。

看来我可以完全忽略 ManagedService 并只使用 DS 配置注入。

是这些技术中的一种优先于另一种，还是有其他我没有看到的权衡？

【问题讨论】：

标签： configuration osgi declarative-services

【解决方案1】：

是的，您可以完全忽略 ManagedService 和 ManagedServiceFactory，而只使用声明式服务组件。是的，我会推荐这种方法。

只需将其视为不同的抽象级别。 MS/MSF 是用于配置管理的低级 API，即使您没有运行 DS 包，它也可用。这样做的好处是您可以编写可配置的服务，而无需依赖 DS，这对于某些“系统级”组件可能是可取的。

但是，如果您愿意依赖 DS，例如对于“应用程序级”组件，那么使用 DS 与配置管理的内置集成将使您的生活更轻松。

【讨论】：

好的，这就是我想要做的事情，但我注意到/有点担心何时无法创建 DS 组件，因为它的配置无效并抛出异常，因为 Equinox 一直在尝试实例化它&很多异常被抛出和记录。它看起来不干净。
如果组件的 activate 方法抛出异常，Equinox 不应继续尝试实例化组件。如果配置发生更改，它应该只重新尝试重新创建组件。至于日志——嗯，当然应该记录组件抛出的异常！
诱使 DS 将组件视为ManagedServiceFactory 而不是ManagedService 的正确方法是什么？换句话说，如果希望 DS 为每个适用的配置实例创建一个组件的新实例，那么诀窍是什么？是否需要编写元类型定义？
@seh：通过添加“configurationPolicy: require”，组件可以用作单例（即 MS）或工厂（即 MSF）。如果您使用与 component.name 相同的工厂 PID 创建工厂配置，那么您将获得工厂。如果您创建一个 PID 与 component.name 相同的单例配置，那么您将获得一个单例组件。
@seh：请注意，DS 从未真正为您的组件创建 ManagedService 或 ManagedServiceFactory。它通过使用 ConfigurationListener 监听 Config Admin 来工作。然而，内部细节并不重要......只需使用与 component.name 匹配的 PID/factoryPID 创建配置，它“就可以工作”。

【解决方案2】：

几个建筑的例子 declarative services 工厂：

1) 通过config admin ： carrot-osgi-scr-factory-cm

2) 通过component factory ： carrot-osgi-scr-factory-ds

看看用例的测试；

【讨论】：