OSGi：Blueprint是否取代声明性服务？

Question

OSGi的新R4.2规范描述了蓝图服务，用于依赖注入和服务连接。

Blueprint是否取代声明性服务（它仍然是规范的一部分）， 或者他们打算一起工作？

蓝图是否已经可用于流行的实现（Felix和Equinox）？

Answer 1

我问自己同样的问题，在与参与该主题的其他人讨论这个问题时，男高音是虽然两者在某种程度上是重叠的，但使用时的用例却截然不同。 DS是一种轻量级解决方案，可以声明性地避免激活器和模型服务依赖。 BP基本上是一个针对企业部署的DI容器。对于那些不熟悉OSGi动态特性的“常规”Java开发人员来说，这种情况也更为常见（隐藏在代理服务器之后）。

实施明智，有两个项目正在进行（所有这些项目都是容器无关，而不是正式发布）。 Spring DM 2.0将提供一个实现（2.0.0.M1 already contains a working implementation）以及Apache作为其geronimo项目（slideshow）的一部分。

Answer 2

根据我在基于Felix的环境中的经验，DS是唯一成熟的依赖注入器，它提供与OSGi Compendium规范的其他部分（如ConfigAdmin）的一致性。

蓝图在我看来是OSGi规范中Spring DM的政治包含。

iPojo是基于Java注释而非XML描述符的替代方案，它隐藏了OSGi基础的一部分。

Answer 3

如果您以前使用过Spring，则使用Blueprint服务会更加熟悉。声明性服务不是那么强大，而是在OSGi容器中广泛采用。

Answer 4

另一个问题是蓝图服务 - 据我所知 - 都存在于一个容器中，即蓝图容器 - 而声明性服务在引用它们的包中可用。特别是对于Equinox，这会导致不同的行为。当您想要遵守equinox倡导的严格的类加载方法时，DS应该用于蓝图。