6

OSGi Enterprise Release 5 规范引入了osgi.extender命名空间。这个命名空间使得假设 Blueprint 或 Declarative Services 等扩展器安装在框架中的捆绑包可以使用Require-Capability标头对这种依赖关系进行建模。

第 135.2 章osgi.extender 命名空间告诉我们，每个特定扩展器的能力值应该在相应的规范中指定。以蓝图为例：

Provide-Capability: osgi.extender;
  osgi.extender="osgi.blueprint";
  uses:="org.osgi.service.blueprint.container,org.osgi.service.blueprint.reflect"
  version:Version="1.0"

但是，第 112 章声明性服务规范没有指定 SCR 实现提供的功能。

Peter Kriens 在一篇关于需求和能力的博客文章中给出了一个例子，表明 SCR 的能力是osgi.component. 我假设最终这个值将在规范中正确定义。但在那之前我不能使用它。

由于Require-Capability和Provide-Capability标头是在 OSGi 核心版本 4.3 中引入的，因此该机制已经在框架实现中可用。所以，我希望我的包表达对 SCR 的要求，以便可以从 OBR 存储库中解析 SCR 实现。

我可以想象一个解决方案，我创建一个空包，一方面提供自定义功能，另一方面需要实现包。例如：

Provide-Capability: com.example.extender; extender=scr
Require-Bundle: org.apache.felix.scr; bundle-version=1.6.0

然后，任何包含声明性服务的捆绑软件都可以表达对此功能的需求。例如：

Require-Capability: com.example.extender; filter:="(extender=scr)"

当我部署包含声明性服务的包时，这是确保解决 SCR 的好方法吗？还有其他方法吗？

这个问题的一个好的解决方案是一个也可以应用于其他不提供功能的遗留包的解决方案。

4

1 回答 1

4

规范定义了 osgi.extender 命名空间，但需要更新各种扩展器规范（蓝图、DS）以强制实现提供适当的扩展器功能。现在，他们可能不会。

所以现在，您的 DS 包现在可以“要求”解析（甚至安装）DS 实现包。

OSGi 正在为 Blueprint 和 DS 的下一次更新进行工作，这些更新将要求 osgi.extender 功能。

于 2012-10-24T21:40:25.077 回答