Thx for the openness. I think I do understand what you mean. You stated your goals clearly, but mine are different. What I need right now is JMS Pooling + Narayana integration. I have no interest now in DS integration and no interest in supporting the Geronimo TM. Just for the record, I don't have any real problem with the Geronimo TM but for the fact that I'm the only one having done commits on it for the past 5 years.
That said, I think it would be fairly easy to implement on top of the being discussed project. The two projects can be easily layered as shown by the quick integration I just wrote: https://github.com/gnodet/aries/blob/tx-control-jms/tx-control/tx-control-provider-jms-xa/src/test/java/org/apache/aries/tx/control/jms/xa/JMSTest.java I'll look into abstracting the transaction manager layer + LRC + recovery. I think that's definitely a missing piece of software in this area. Guillaume 2017-06-20 23:22 GMT+02:00 mit_jones <[email protected]>: > 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.c > om/Re-PROPOSAL-New-pax-project-transx-tp4035366p4035371.html > Sent from the Aries - Dev mailing list archive at Nabble.com. > -- ------------------------ Guillaume Nodet
