Hi Guillaume, So as to openly declare by bias I will state my interest in this conversation. My company commissioned Paremus to provide a DS solution for transaction control of JPA and JDBC resources which ultimately led to Aries tx-control.
Your proposal sounds great, it really does, however I will explain how we came to the decision to comission Paremus which I am hoping may then sway your decsion as to where it should be implemented. The product we develop was based upon SpringDM which given the future (or lack of it) forced us to look for an alternative, we decided to migrate to a DS based solution but soon realised there was a lack of transactional solutions for DS. At the time I was aware of the Everit transaction-helper and a partially completed transactional solution for DS, that being the aries-jpa JpaTemplate solution. I had some early conversations with Christian about adding new functionality to the JpaTemplate solution such as support for JDBC, not rolling back for specific exceptions, raised a few bugs on JIRA but wasn't confident that I could recomend it as a solution given the lack of tests and most importantly no specification to back the implementation. The solution we now have is tx-control backed by RFC-221 with a implementation that covers the extra functionality we asked for such as last gambit wins and has 2500+ lines of test code. Currently if one was to embark upon adopting OSGi we are faced with a multitude of choices Blueprint/DS/CDI/iPOJO ... and solutions provided by Aries/Pax/Enroute/Everit/Amdatu ... For you and perhaps many readers the choices are obvious but in my opinion it is not obvious and even more difficult to access the quality of the solutions. One thing that is indisputable is whether a solution is backed by a specification and therefore necessarily has controls to enforce a certain level of compliance => quality, this in my opinion is very important, although no guarantee it is probably the best assurance an adopter can have that the component/framework they are using will survive longer term. I have followed the Aries/Karaf/Pax forums closely enough over the past few years to see that there is tension between groups who belong and don't belong to the OSGi Alliance. I think this is really unfortunate because it has led and is continuing to led to fragmentation in the OSGi community as a whole which manifests itself in multiple solutions/options making it really difficult for an adopter of the technology to know which to choose. To add JMS support into the tx-control project would add to an already well designed solution, that already has good documentation, test support and not lead to yet more fragmentation. I presume the specification could be added to as needed if required. Unfortunately my company does not have an immediate need for transactional JMS otherwise I would be able offer more bribery in the form of $$ :) Tim J. -- View this message in context: http://aries.15396.n3.nabble.com/Re-PROPOSAL-New-pax-project-transx-tp4035366p4035371.html Sent from the Aries - Dev mailing list archive at Nabble.com.
