aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mit_jones <tim.jo...@mccarthy.co.nz>
Subject Re: [PROPOSAL] New pax project 'transx'
Date Tue, 20 Jun 2017 21:22:23 GMT
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.

Mime
View raw message