Since there is no oficial release yet I think there is no Problem with
changes, also that
*ReflectiveConfigurationBasedConnectionFactoryProvider* also provides
the ConnectionFactory itself as an additional service seems reasonable.
The idea behind the Connection as a service is that user code that use
that connection get notified whenever the connection is dropped/renewed
withou the need to handle connection itself.
I also thing it is fine to provide JMS 1.1 and JMS 2.0
Factories/connections.
Am 03.07.2017 12:01, schrieb Guillaume Nodet:
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
<ops4j@googlegroups.com <mailto:ops4j@googlegroups.com>>:
I already started https://github.com/ops4j/org.ops4j.pax.jms
<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
<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
<https://github.com/gnodet/org.ops4j.pax.transx>
--
--
------------------
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
---
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 ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
