Community
Participate
Working Groups
Need to see what effort is needed to support JTA transaction type in persistence units.
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,
Created attachment 227130 [details] Some unsuccessfull tries to integrate jndi+jta with gemini jpa
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
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
Finally going to try to get to this. Shooting for M2.
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,
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.
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,
