In fact a connectionfactory is exposed and optionally COnnectiosn can
becreated from those by configuration.
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
<[email protected] <mailto:[email protected]>>:
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?
--
--
------------------
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.
