我想到了同样的问题,我得到了以下结果:
1:Gemini 是基于 Spring 的,它的历史要长得多,并且证明了很多。当我查看代码时,Gemini 似乎更干净,有更多的扩展可能性,但是我遇到了命名空间处理程序的问题。即使是 1.0.0 版本,它也不会等待命名空间处理程序。Aries 等待 NS 处理程序的方式与等待所需引用的方式相同。我问过 OSGi 的人,他们说下一个蓝图规范可能包含一个标准的 NS 处理程序 API,在我看来这会很有帮助。我的结论是我使用 Apache Aries,但这不是最终决定。我每年每个季度都会回顾这个话题。我还提出了一些如何改进 Blueprint 的建议并将其上传到OSGi bugzilla. 我想在夏天实现这些增强功能,当我查看代码时,基于 Gemini 会容易得多。
2:Gemini 包含一个嵌入式 Tomcat。如果您只是将捆绑包放入春分点,则效果很好。但是,它包含我想避免的对 Spring 的几个依赖项。我喜欢 Spring,但我希望尽可能少地依赖。我不认为白羊座在这个话题上有任何主要的支持。直到现在,我终于开始使用与 Myfaces 和 Jersey 一起使用的 Jetty。到目前为止,我还没有尝试过其他任何东西。我也更喜欢 Jetty 的配置可能性。配置包可以定义为一个环境变量,如果您想在构建生命周期中运行集成测试,它会很有帮助。如果 Gemini 支持更多的配置选项(比如来自捆绑包),我会考虑转向那个。
3:因为我喜欢使用 JTA,所以我根本没有选择使用 Gemini。我用 Aries JPA 安静了一段时间,我很满意。当我与许多同事一起工作时,我对他们的效率负责。使用 Aries JPA,我遇到的问题是它没有等待 DataSourceFactory 服务(如果在 persistence.xml 中定义了 db 连接)或定义了 DataSource 服务(如果 jta-data-source 或 non-jta-data-source)。这意味着当您使用 Aries JPA 时,捆绑包的起始顺序很重要。
直到我们使用 Glassfish 和 JNDI 才成为问题,因为 Glassfish 在我们的 OSGI 包之前启动了 JNDI 资源。当我们转移到清理 OSGI 容器时,我们开始遇到问题,我的同事开始花费大量时间尝试让正确的捆绑包开始订购。
最后,我只是将 Aries JPA 捆绑到一个包中,并重写了我不喜欢的部分。这意味着我只保留了 persistence.xml 解析器部分,并在http://everit.org/osgi/jpa/org.everit.osgi.jpa.container/index.html创建了一个自己的项目,我专注于没有这个麻烦. 目前它可以与 Hibernate 一起使用,我猜(还没有尝试过)与 Eclipselink 和编译时间增强的 OpenJPA 一起使用。我编写的容器适用于 org.apache.aries.jpa.container.context 和 aries jpa 蓝图命名空间处理程序。
4:如果您使用应用程序服务器,并且您确定您的 JNDI 环境在您的捆绑软件之前启动,而不是使用它。但是,您无法捕获修改或删除 JNDI 资源,因此我不建议在 OSGi 中使用它。如果您因为 JPA 而需要它,我可以建议我的容器实现 :) 使用标准 OSGi 服务跟踪器,即使您在带有 osgi:service/... 表达式的 persistence.xml 中使用 *-data-source 也是如此。如果您需要一个中央配置位置,我建议您检查 felix-webconsole 的 Configuration 选项卡,OSGi 规范的 Metatype 和 Configuration Admin 部分。如果您在 Metatypes 的帮助下定义配置设置,它们将在 feilix-webconsole 上可用,并且通过配置管理 API,您将能够捕获配置更改事件。
希望我的意见有用!