I just had another look at pax-jms. The main problem I have is that it exposes a JMS Connection as a Service. It should really be a ConnectionFactory instead. For correct XA support, we actually need the user to provide both a ConnectionFactory and an XAConnectionFactory, so that the wrapped connection factory created by pax-transx can actually work when there is no transaction. In addition, I suggest exposing a JMS 2.0 ConnectionFactory, which is easier to use. Fwiw, the pax-transx code offers JMS 2.0 support, even if the underlying JMS client library is JMS 1.1 only.
So I'm willing to work on pax-jms to incorporate the above things, mainly pooling + XA support, but it will have to be done in a slighly incompatible way I think. Thoughts ? I'll start working on a branch, as I'll need a way to expose the ConnectionFactory anyway. 2017-06-20 10:15 GMT+02:00 'Christoph Läubrich' via OPS4J < [email protected]>: > I already started https://github.com/ops4j/org.ops4j.pax.jms for JMS a > while ago so you are maybe interested in adding the pooling-feature there > also? > > In fact pooling and recovery can be nicly integrated into OSGi using the > service factory, so a switch over would be simply register/unregister a > service with a new underlying connection, pooling can be done with > ServiceFactorys that share a fixed set of connections. Just don't know if > this works well with XA > > > Am 15.06.2017 09:57, schrieb Guillaume Nodet: > > I began to work on a small project which aims at providing support for > pooled XA-enabled connections for JDBC and JMS. > > For JDBC, the problem was already solved in pax-jdbc by using either > pax-jdbc-pool-aries when deploying the Aries/Geronimo transaction manager, > and by using pax-jdbc-pool-narayana when using the Narayana transaction > manager. > > However, there's absolutely no support for JMS. > > So what I've been doing is to reuse the geronimo JCA connector, make it > independent on Geronimo TM and add support for Narayana, use a clone of the > old tranql adapter for JDBC and rewrite a new JMS 2.0 compatible adapter > for JMS. > > It's not in a usable state yet, but I wanted to give an heads-up. > My plan is to make the pooling almost transparent in OSGi, and reuse it > instead of the connection pooling I added to Karaf a few weeks ago which > does not support XA or recovery: > https://github.com/apache/karaf/tree/master/jms/pool > and maybe to plug it into pax-jdbc to replace pax-jdbc-pool-aries and > pax-jdbc-pool-narayana. > > The source code is currently available at: > https://github.com/gnodet/org.ops4j.pax.transx > > > Cheers, > -- > ------------------------ > Guillaume Nodet > > -- > -- > ------------------ > OPS4J - http://www.ops4j.org - [email protected] > > --- > You received this message because you are subscribed to the Google Groups > "OPS4J" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > -- > -- > ------------------ > OPS4J - http://www.ops4j.org - [email protected] > > --- > You received this message because you are subscribed to the Google Groups > "OPS4J" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- ------------------------ Guillaume Nodet -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
