OSGi 4.2 有什么新功能？

Question

OSGi 4.2 有just been released，它用一些新的 RFC 更新了 4.1 规范。那么，OSGi 4.2 有什么特别新的地方，哪些框架已经（或接近）支持 4.2，为什么您应该针对 4.2 框架而不是 4.1 来定位新开发？

Answer 1

在大多数情况下，OSGi 的单点版本（例如 4.1->4.2）并不会真正改变现有行为，因此可以肯定地说，如果您有一个依赖于 4.1 的应用程序，它将运行在4.2没有问题。新的是，一些项目已经标准化，应该能够在不同的 OSGi 引擎之间实现更好的互操作性（如Equinox、Felix 和Knopflerfish）。

事实上，虽然 OSGi 4.2 直到 2009 年 9 月 16 日才正式发布，但早期的草稿已经可供其他人参考，因此之前的产品版本（如 Equinox 3.5、Felix 1.8）已经对标准。与 802.11n 产品一样，它们符合早期的草案，但预计它们将在不久的将来被认证为完全符合 4.2 版本。

那么，4.2 中有什么新功能？

• 服务挂钩
• 框架启动

而且，在纲要中

• 远程服务
• 捆绑跟踪器
• 蓝图服务

服务挂钩

Service Hook API 允许您了解发生在服务层的事件。例如，您可以挂钩何时请求服务、何时交付服务等。您还可以导致事件未交付（例如，隐藏您无权查看的事件）但不能更改任何事件（因为这会使交付的类复杂化）。服务挂钩是核心规范的一部分，因此所有 OSGi 版本都需要符合此规范。

框架启动

虽然可以从现有 Java 应用程序以编程方式启动 OSGi 实例，但执行此操作的方式取决于您使用的 OSGi 运行时。特别是，配置项（例如存储临时数据的位置、捆绑引导委托策略应该是什么等）都以特定于引擎的方式定义。这整合了任何启动实用程序在框架上设置的属性。

远程服务

远程服务 API 允许 OGSi 服务在虚拟机之间进行通信（可能在不同的机器上）。它们如何通信（RMI、WebServices 等）的确切机制对提供者是开放的，因此它不同于专门规定在线格式的其他分布式技术（如 Corba）。显然，分布式服务与本地服务具有不同的语义（通信错误、序列化问题），如果需要，它可以由各个服务进行分发。

捆绑跟踪器

与 4.1 之前的 ServiceTracker 一样，BundleTracker 可用于监视系统中哪些包进出。动态 GUI 可以使用它来显示 OSGi 引擎的演变状态，而无需任何平台特定知识。

蓝图服务

蓝图服务类似于 Spring，因为它提供了用于配置捆绑包的依赖注入机制。在某些方面，它类似于声明式服务；但是蓝图服务以不同的方式做事。此外，与声明式服务（只能处理存在的服务）不同，蓝图服务可以提前为稍后上线的服务创建代理占位符。然后，对服务代理的调用将被阻塞，直到可以填充服务（而不是像声明性服务那样返回“null”）。如果您熟悉或熟悉 Spring IOC 和类似的依赖注入，那么 Blueprint 服务将立即可以理解。

Answer 2

早期的更改是highlighted here。

特别是 RFC 119 - 分布式 OSGi 特性很有趣：

此解决方案为分布式 OSGi 处理定义了最低级别的特性/功能，包括服务发现以及对外部环境的访问。

与EventAdmin（在 41 中引入）相结合，将允许更轻松地实现基于 OSGi 的分布式服务（目前已实现 with ECF）

Answer 3

This article 详细介绍了感兴趣的 RFC。引用，

首先要注意的是 这不是一个小版本，因为 版本号可能会建议。发布 4.2 实际上比去年的 R4.1 版本更重要。在 有些点我什至会说是 比 R4 版本更重要， 因为这样一种用法就变成了 更容易，尤其是对于没有 OSGi 专家。

Answer 4

当引用绑定不可用时，声明式服务是否实际上返回 null？在 Equinox 上，即使我将模式设置为动态，如果我的组件不能被“连接”，它也永远不会被实例化。正如你所说，我宁愿将它设置为“null”，这样我就可以有可选的引用绑定并使用动态发现......

此外，我错过了在绑定服务时轻松找到组件属性的可能性（我必须转到 Bundle 上下文、获取服务引用、迭代和比较——不切实际）。也许我错过了一些东西。