Java 最合适的OSGi平台？

我们目前正在开发一种新的软件，我们认为OSGi模块化非常有用，因为软件本身可以很好地分解为模块化结构，以避免将来代码混乱，并且能够轻松地添加新功能并与现有功能挂钩

我一直在使用两个（可能是最流行的）OSGi平台，EclipseEquinox（使用双子座蓝图）和ApacheFelix（使用白羊座）。基本上，我现在正在做一个决定，我们应该使用哪一个

我们对Spring有着丰富的经验，因此我们希望继续使用Spring，以及注释（例如

@Autowired

用于同一捆绑包中的自动连接bean，

@servicerence

用于跨捆绑包的自动连接）、一些特定的Spring插件（例如数据JPA），Hibernate作为JPA提供者（到目前为止，我们只有将Hibernate作为JPA实现的经验，它具有我们需要的所有功能，因此我们希望避免切换到其他功能）、JMS消息传递（使用ActiveMQ客户端）和其他一些功能。 稍后，我们还希望能够实现我们自己的安全管理器（以控制对某些捆绑包的访问，例如基于它们的数字签名、嵌入了权限的证书）

到目前为止，我已经能够制作两个测试包（一个使用另一个提供的服务），并将它们作为Equinox上的SpringBean与Gemini BP一起使用。但是，我在注释方面遇到了一些问题（我不太喜欢在XMLs中连接Bean，尤其是在架构不太复杂的情况下——其中大多数是单例）

我也尝试过白羊座（但在那里启用Spring没有成功；可能只是还没有花足够的时间：））

---

对于这样的用例，您推荐哪种OSGi平台？

这一个可能不是最好的答案，但如果我与您分享我的经验，我认为它对您很有用。几年前，我也遇到了同样的情况。我对Spring，JPA（Hibernate and EclipseLink）很有经验。我发现OSGi模块化很有用，所以我们开始了基于OSGi的项目

正如我以前使用Spring一样，使用Blueprint是显而易见的（我们最终使用ApacheAries，因为它比GeminiBlueprint更稳定）。我们这样做了两年。然而，我们有很多问题，所以我开始基于规范实现一个新的Blueprint容器。我多次听说OSGiDS更好，但因为我以前是Spring的粉丝，所以这些教程并没有让我改变主意。我觉得ConfigAdmin会非常好用，但是使用Blueprint不可能编写好的代码（我知道有cm名称空间，但它对我们来说不太好）

在EclipseCon上，我和Peter Kriens谈过，他说服我在一个项目上尝试DS。我这么做了，现在我真的为我使用Blueprint感到难过（我不是有意伤害你们的，白羊座的家伙：））。声明性服务与ConfigurationAdmin一起设计用于在OSGi模块化世界中工作。我很确定我很了解你现在的感受，但如果我真的建议你不要犯我犯过的同样的错误。尝试使用DS组件创建两个捆绑包，从felix configadmin获得配置并感受其威力

从JPA开始，我们使用了第一次日食。由于车太多，我们转为冬眠。我编写了一个适配器来使用它（在GitHub上提供）。据我所知，Hibernate现在在这个主题上有了更多的支持，我从未尝试过。最后，我们决定离开JPA。我们即将将基础设施从JPA更换为Liquibase+QueryDSL。组件或多或少都准备好了，我们需要编写文档。如果您感兴趣，为什么我们从JPA转换，请阅读此博客帖子下的评论：

简言之，我的回答是：

• 如果您希望避免由于历史原因而使用声明性服务（这是一个错误，但我可以理解），请使用ApacheAries或GeminiBP（您发现更好的）。由于ApacheAries是为OSGi创建的，所以为Aries编写的所有名称空间处理程序都可以正常工作。Aries不支持为Spring编写的命名空间处理程序，因为Aries有自己的API。但是，ActiveMQ和其他项目具有Aries命名空间处理程序实现。再次，我建议考虑使用DS，而不是用XML编写java代码。如果您设计小模块，部署时间将不会成为问题。另一方面，您将在配置和稳定性方面获得很多好处
• 带有Hibernate的JPA可以在OSGi中使用。可以在此处找到一个示例：。如果你在谷歌上搜索，可以找到更多最新的例子。我建议您在JPA工作时四处看看，但它不是OSGi友好的
• 关于引擎：如果您使用Felix，您可以确保您的代码将在Equinox或Knopflerfish等其他容器上运行。另外两个具有特殊功能，如果使用，可能会遇到以后无法移植代码的问题。我个人使用Equinox，但它有历史原因
我们大量使用蓝图。最近有很多与白羊座有关的bug，但大多数都已经修复了。Blueprint对我们来说工作得很好，但与JavaEE相比，它缺乏对企业特性的支持。它有基本的容器管理事务，但在这方面没有更多
声明式服务似乎比blueprint更稳定、更轻量级。他们还真正拥抱了OSGi的动态特性。另一方面，DS没有任何扩展，例如JPA和容器管理事务。因此，我不确定用它们编写真正的业务代码有多困难
我会非常小心双子座的蓝图。Springsource似乎完全抛弃了OSGi。因此，我担心双子座的蓝图会像春天的dm一样，完全没有得到维护。当然，双子座现在正处于月食状态