Bug 356508

Comment 1 Charlie Mordant 2013-01-15 11:08:42 EST

It seems very an easy task to do: just injecting a custom eclipselink transaction.session.customizer when exporting entitymanagerfactory: http://fogbugz.atomikos.com/default.asp?community.6.1070.3#discussTopic1072

The Atomikos bundles are already OSGIfied and tested (as they said). 

Let's see if we can do this dynamically (for example, if bundle gemini-tx is present, export the EMF with the session customizer).

May I help for something?

Regards,

Comment 2 Charlie Mordant 2013-02-15 08:54:33 EST

Created attachment 227130 [details]
Some unsuccessfull tries to integrate jndi+jta with gemini jpa

Comment 3 Charlie Mordant 2013-02-15 08:55:12 EST

I found some interesting post in the eclipselink forum more or less related to the issue:

* To instatiate a session customizer in eclipselink:
http://wiki.eclipse.org/EclipseLink/Examples/JPA/Tomcat_Web_Tutorial#Session_Customizer

* To make eclipselink aware of jndi (ie: gemini-naming) osgi services ref urls (necessary to lookup at jdbcatomikosdatasource) : http://www.eclipse.org/forums/index.php/mv/msg/242860/989315/

* The form of an atomikosdatasource (maybe integrating one in gemini-dbaccess): 
http://wiki.eclipse.org/Jetty/Howto/Configure_JNDI_Datasource

* Atomikos derbyEmbedded datasource:
http://www.atomikos.com/Documentation/ConfiguringDerby


It would also be nice (in a second time) to have a custom jta namespace like the aries one (maybe have a common one ?) see step 3:
http://aries.apache.org/modules/jpaproject.html

Comment 4 Charlie Mordant 2013-02-15 09:03:12 EST

Additionnally, gemini-jpa lack of JTA support is blocker for me as I try to make some view to model bundles Karaf & Virgo compliants and that my View bundles requires transactions...

Regards, Charlie

Comment 5 Michael Keith 2013-06-13 18:34:30 EDT

Finally going to try to get to this. Shooting for M2.

Comment 6 Charlie Mordant 2013-06-15 09:58:20 EDT

Is there a way to make standards namespaces with apache community (jta and maybe jta too)? It will make the transition more fluent between Karaf or Virgo.

I think it would be a very nice thing for the both worlds because both of these servers have their advantages (nice web console, nice isolation between kernel for Virgo, nice feature management for Karaf...).

Finally, it will allow cxf support for example then all camel plugins that are strong, useful ecosystems.

I'm aware that it's a part of a wider reflexion but it should begin with this JTA spec ;).

Best regards,

Comment 7 Michael Keith 2013-06-17 12:48:06 EDT

All JPA is going to do is assume that some container has a JTA data source made available to us. The actual name that is used does not matter from our JPA perspective, so whether it is standard or not does not matter and will never be part of the JPA spec.

But I think you are just asking the question of name standardization for the sake of a user being able to specify a name that can be portable across the different containers, right? The OSGi JTA spec does specify that a transaction manager be  made available as a service under the fully qualified class name. The missing part is the transactional data source, but that would really be an additional spec that would merge the JTA spec with the JDBC data source factory spec. If that is what you are asking for then I agree that a new spec for that part would be nice, but nobody seems to have the time or the will to do that right now.

Comment 8 Charlie Mordant 2013-06-18 14:28:35 EDT

Hi Mike,

Yes, you're right, these JPA and JTA OSGi implementations are just exporting the right services (JTATransactionManger, EntityManager and their Factories).

As you say, as a bonus, an OSGI soft could be portable if the both worlds of OSGI-EE (I'm talking about Karaf & Virgo, embedding gemini-jpa/jta and the Aries counterparts).

Aries 'specific' API's have specific blueprint namespaces:
 <jpa:unit property="emf" unitname="myUnit" /> or <jpa:context.../> and <tx:transaction method="*" value="Required" />

It would be good to have a similar namespaces for Gemini, or OSGI in general:
xmlns:jpa="http://osgi.org/xmlns/jpa/v1.1.0 instead of 'proprietary xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.1.0 compliant for these both frameworks.

With these stuff, OSGI-EE would be portable, and as a bonus some apache-tied libraries (this is the case for cxf and camel for example) would be compliant, accessible and testable on these two implementations.

Regards,