Historically I know that we assumed an e-OSGi environment if JTA was being used. And in fact in my limited OSGi scope I thought that Aries is e-OSGi. So to me, either:

1. Aries is not synonymous with e-OSGi
2. Aries is synonymous with e-OSGi and that interpretation of the e-OSGi spec is inaccurate.
3. Aries is synonymous with e-OSGi and that interpretation of the e-OSGi spec is accurate.

To me all of these cases come down to a RFE within Hibernate to allow OSGi environments (non-enterprise only?) to plug in a custom JtaPlatform. However, if (3) is the case I'd also consider that a problem with Aries.

I think the confusion here comes from the fundamental difference between Java EE and e-OSGi. In Java EE you must have a JPA container and a JTA runtime. In e-OSGi you can have both of these things, but you might not. Basically e-OSGi lets you pick and choose the pieces that you want to use.

The bundle org.apache.aries.jpa.container is an implementation of the OSGi JPA Service, which is defined in a chapter of the Enterprise OSGi specification. A different chapter in the same specification defines the OSGi JTA service (also available from Aries), which is what the OsgiJtaPlatform implementation is trying to find.

What the OsgiJtaPlatform currently does is a really good default. In the case where someone has asked to create a JTA EntityManagerFactory then the OSGi JTA service is a perfectly sensible go-to option. It's also right that in the absence of any available service that things go bang. It would be even better if we could guarantee the presence of the TransactionManager before creating the EntityManager, but that's just not possible with the specifications as they are.

The next version of the OSGi specification, however, will have a new chapter for the TransactionControl service. The Transaction Control service exists to try to simplify the process of doing transactional work with resources in OSGi. It also aims to fix the lifecycle mismatches around transactions and resources. This is where the need to replace the JtaPlatform comes in. The only good way to do two-phase XA work with a JPA provider is to tell it that it's in a managed JTA mode (which is pretty much the truth). The Aries Transaction Control implementation already replaces the TransactionCoordinator/Driver to get the right integration points, all that's left are the few places where the JtaPlatform is used directly.

In a perfect world Hibernate would be able to do everything using the special TransactionCoordinator and TransactionDriver, added by Transaction Control and I could ignore the JTA platform completely. I get that this would be a big change to Hibernate though, and so I am happy to roll my own JtaPlatform.