我们目前正在开发一种新软件,我们认为OSGi模块化非常有用,因为软件本身可以很好地分解为模块化结构,以避免将来代码混乱,并能够轻松添加新功能并挂钩现有的.
我一直在玩两个(可能是最受欢迎的)OSGi平台,Eclipse Equinox(带有Gemini Blueprint)和Apache Felix(带Aries).基本上我现在正在做出决定,我们应该使用哪一个.
我们对Spring有很多经验,所以我们希望继续使用它,以及注释(例如@Autowired用于在SAME包中自动装配bean,@ ServiceReference用于跨包的自动装配),一些特定的Spring插件(例如Data JPA) ),Hibernate作为JPA提供者(到目前为止,我们只有Hibernate作为JPA实现的经验,它具有我们需要的所有功能,因此我们希望避免必须切换到其他东西),JMS消息传递(使用ActiveMQ客户端)和少数其他特性.
稍后,我们还希望能够实现我们自己的安全管理器(以控制对某些捆绑包的访问,基于例如他们的数字签名,其中嵌入了权限的证书)
到目前为止,我已经能够制作两个测试包(一个使用来自另一个的服务)并将它们视为Equinox上的Spring Beans与Gemini BP.但是,我在注释方面遇到了一些问题(我并不喜欢在XML中使用布线bean,特别是在架构不那么复杂的情况下 – 大多数都是Singletons).
我也尝试过Aries(但是没有成功在那里启用Spring;可能还没有花足够的时间在那上面:)).
您为此类用例推荐了哪个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,但它有历史原因.
