Enterprise OSGi frameworks : Maturity comparison Apache Aries vs. Eclipse Gemini [closed]

Question

Question: As of today, which of the two Enterprise OSGi frameworks is more mature: Apache Aries or Eclipse Gemini?

I have done some basic research of Aries and Gemini Enterprise OSGi capabilities. I have also gone through a similar this question: Gemini and Apache Aries blueprint container.

My requirements and findings below. Will highly appreciate your additional inputs.

1. Blueprint container: Both Aries and Gemini seem equally mature in terms of implementation against the Blueprint specification.

2. Web development (will be developing against JSR 286 using Spring Portlet MVC):
   Although Gemini Web has roots in Spring DM (hence my initial preference towards the Gemini framework), I believe that Aries should be equally capable of working with Spring Portlet MVC based Web applications.

3. JPA: This is my biggest area of concern. Although I was initially more inclined towards Gemini (due to its roots in Spring DM and support from active SpringSource community), I feel that the Gemini JPA maturity is quite LOW compared to Aries JPA. Reasons:

   • Gemini JPA only supports integration with EclipseLink as JPA provider. I would like to use Hibernate. Aries JPA supports Hibernate.
   • Referring to Gemini JPA limitations: especially limitation #5: Lack of support for JTA transactions. It seems that Aries JPA supports JTA ... But I have not been able to get into the details of the level of support.

4. JNDI: My new web applications would need to call into existing Session EJBs from a service tier hosted inside JBoss application server. Hence JNDI support is crucial for my OSGi enabled Web applications in the client tier.
   It seems that Gemini Naming is yet to be released whereas Aries has already got some capability in this area.

Answer 1

the same question came into my mind and I got the following results:

1: Gemini is based on Spring which has a much longer past and proved a lot. As I looked into the code Gemini seemed to a bit cleaner with more extension possibilities however I had problem with the namespace handlers. Even with the 1.0.0 version it did not wait for namespace handlers. Aries waits for NS handlers in the same way as it waits for required references. I asked the OSGi guys and they said that the next Blueprint spec may contain a standard NS handler API that in my opinion would help a lot. My conclusion was that I use Apache Aries but it is not a final decision. I review this topic in every quarter of the year. I also made some suggestions how to improve Blueprint and uploaded it to the OSGi bugzilla. I would like to implement these enhancements in the summer and as I looked into the code it would be much easier based on Gemini.

2: Gemini contains an embedded Tomcat. If you simply drop the bundles into an equinox it works pretty well. However it contains several dependencies to Spring that I wanted to avoid. I like Spring but I wanted as less dependencies as I needed. I do not think Aries has any major support in this topic. I finally started to use Jetty that works with Myfaces and Jersey till now. I have not tried anything else till now. Also I liked the configuration possibilities of Jetty more. A configuration bundle can be defined as an environment variable that can help a lot if you want to run integration-tests as part of your build lifecycle. If Gemini supports more configuration options (like coming from bundle) I will think of moving to that one.

3: As I like using JTA it was no option for me to use Gemini at all. I used Aries JPA for quiet a while and I was satisfied with it. As I work with many colleagues I am responsible for their effectiveness. With Aries JPA I had the problem that it did not wait for DataSourceFactory services (if db connection is defined in the persistence.xml) or the DataSource services (if jta-data-source or non-jta-data-source) is defined. It meant that the bundle starting order matters when you use Aries JPA.

It was not a problem until we used Glassfish and JNDI as Glassfish started the JNDI resources before our OSGI bundles. When we moved to clean OSGI container we started to have problems and my colleagues started to spend a big amount of time trying to get the right bundle start ordering.

On the end I simply bundled Aries JPA into a bundle and rewrote the parts I did not like. This means that I kept only the persistence.xml parser part and created an own project at http://everit.org/osgi/jpa/org.everit.osgi.jpa.container/index.html where I concentrated not having this troubles. Currently it works with Hibernate and I guess (have not tried) with Eclipselink and Compile time enhanced OpenJPA. The container written by me works well with the org.apache.aries.jpa.container.context and the aries jpa blueprint namespace handlers.

4: If you use an application server and you are sure that your JNDI environment starts before your bundles than use it. However you cannot catch the modification or remove a JNDI resource therefore I do not suggest to use it inside OSGi at all. If you needed it because of JPA I can suggest my container implementation :) that uses standard OSGi service trackers even if you use *-data-source in your persistence.xml with osgi:service/... expression. If you need a central configuration place I recommend that you should check the Configuration tab of felix-webconsole, the Metatype and Configuration Admin parts of OSGi specification. If you define a configuration setting with the help of Metatypes they will be available on the feilix-webconsole and via the Configuration Admin API you will be able to catch the configuration change events. I tested and felix-webconsole worked for me on Equinox-Jetty pair as well.

Hope my input was useful!