最合适的OSGi平台？

我们使用Apache aries的蓝图很多.最近有很多与白羊座有关的虫子,但现在大多数都是固定的.Blueprint对我们来说效果很好,但与JavaEE相比,它对企业功能缺乏一点支持.它具有基本的容器管理事务,但在这方面几乎没有.

声明性服务似乎比蓝图更稳定,重量更轻.他们也真正拥抱OSGi的动态特性.另一方面,DS没有任何扩展,例如JPA和容器管理的事务.所以我不确定用它们编写真正的业务代码是多么困难.

我会非常小心双子座的蓝图.Springsource似乎完全放弃了OSGi.所以我担心双子座的蓝图会和春天的dm一样,而根本没有维持.当然,双子座现在处于日蚀状态,但我不确定社区是否能够支持这一点.

在中期,我真的想在OSGi上使用CDI和完整的JavaEE支持.已经有pax cdi在OSGi上提供对CDI的支持,并且有来自Apache Deltaspike的 JPA和容器管理事务的可移植扩展.不幸的是它还没有完全正常工作,所以现在这不是一个真正的选择.

所以我的建议是目前用Aries蓝图和DS做自己的概念证明,并在两者之间做出决定.与此同时,我会密切关注OSGi上的JavaEE支持,看看它何时可以准备好.

对于基本的OSGi平台,我认为felix和equinox都很不错.看看Apache Karaf可能也是有意义的,它在两个框架之上提供管理和企业功能.

这个可能不是最好的答案,但我认为如果我分享我的经验对你有用.几年前我的情况完全一样.我对Spring,JPA(Hibernate和EclipseLink)很有经验.我发现OSGi模块化很有用,所以我们开始基于OSGi的项目.

正如我以前使用Spring一样,很明显使用Blueprint(我们最终使用的是Apache Aries,因为它比Gemini Blueprint更稳定).我们这样做了两年.但是,我们遇到了很多问题,所以我开始根据规范实现一个新的Blueprint容器.我多次听说OSGi DS比较好,但之前我曾经是Spring的粉丝,这些教程并没有让我改变主意.我觉得ConfigAdmin会非常好用,但是使用Blueprint它不可能写出漂亮的代码(我知道有cm命名空间,但它对我们来说效果不好).

在EclipseCon,我和Peter Kriens交谈,他说服我在一个项目上试用DS.我这样做了,现在我对使用蓝图的时间感到非常难过(我不是故意伤害你,白羊座的人:)).声明性服务与ConfigurationAdmin一起设计用于OSGi模块化世界.我很确定我很了解你目前的感受,但如果我真的建议你不要犯同样的错误.尝试使用DS组件创建两个捆绑包,从felix-configadmin获取配置并感受功能.

从JPA开始,我们使用了第一个EclipseLink.因为太麻烦了,我们切换到了Hibernate.我写了一个适配器以便能够使用它(在GitHub上可用).据我所知,Hibernate现在在这个主题上有更多的支持,我从未尝试过.最后,我们决定离开JPA.我们将基础架构从JPA更换为Liquibase + QueryDSL.这些组件或多或少都可以在https://github.com/everit-org上准备好,我们需要处理文档.如果您有兴趣,为什么我们从JPA切换,请阅读此博客文章下的评论:http://blog.osgi.org/2013/12/attributes-attributes-and-attributes.html

我的答案简短:

如果您因为历史原因(这是一个错误,但我可以理解)而避免使用声明式服务,请使用Apache Aries或Gemini BP(您会发现更好).由于Apache Aries是为OSGi创建的,因此为Aries编写的所有命名空间处理程序都可以正常工作.Aries不支持为Spring编写的命名空间处理程序,因为Aries有自己的API.但是,ActiveMQ和其他项目具有Aries命名空间处理程序实现.再一次,我建议考虑使用DS而不是用Java编写代码.如果设计小模块,部署时间不会成为问题.另一方面,您将在配置和稳定性部分获得许多好处.

带有Hibernate的JPA可以在OSGi中使用.可以在这里找到一个例子:https://github.com/everit-org/osgi-hibernate.如果你谷歌,可以获得更多最新的例子.我建议你应该看看JPA的工作原理,但它不是OSGi友好的.

关于引擎:如果使用Felix,您可以确保您的代码可以在其他容器上运行,如Equinox或Knopflerfish.另外两个具有特殊功能,如果您使用,您可能会遇到以后无法移植代码的问题.我个人使用Equinox,但它有历史原因.