aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [PROPOSAL] New pax project 'transx'
Date Wed, 21 Jun 2017 12:24:52 GMT
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:

I'll look into abstracting the transaction manager layer + LRC + recovery.
I think that's definitely a missing piece of software in this area.


2017-06-20 23:22 GMT+02:00 mit_jones <>:

> 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

Guillaume Nodet

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message