Resource Adapter for JMS 2.0 and Connector 1.7

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Resource Adapter for JMS 2.0 and Connector 1.7

bl4d3
Hi,
I wasn't able to find that info on your site. But do you have already a resource adapter which supports Connector 1.7 API and JMS 2.0?

Thanks in advance!
Reply | Threaded
Open this post in threaded view
|

Re: Resource Adapter for JMS 2.0 and Connector 1.7

IIT Software
Administrator
We don't provide them yet.
Reply | Threaded
Open this post in threaded view
|

Re: Resource Adapter for JMS 2.0 and Connector 1.7

bl4d3
In case it is helpful for others: swiftmq_jca16.rar can be still used with WildFly 8.1 (it works at least for me).   But I haven't tested if it would work when you use the JMS 2.0 API in the application in conjunction with swiftmq_jca16.rar.
Reply | Threaded
Open this post in threaded view
|

Re: Resource Adapter for JMS 2.0 and Connector 1.7

TheQL
In reply to this post by IIT Software
Hello!

Any update about JMS 2.0? We would be interested in that as well!
Reply | Threaded
Open this post in threaded view
|

Re: Resource Adapter for JMS 2.0 and Connector 1.7

IIT Software
Administrator
There will be a major update on SwiftMQ soon. But not concerning JMS 2.0 etc.
Reply | Threaded
Open this post in threaded view
|

Re: Resource Adapter for JMS 2.0 and Connector 1.7

TheQL
Ok, looking forward to that. Can you give a rough time frame on when we can expect JMS 2.0 to be supported nevertheless? I am getting pressured with this from our developers ;)
Reply | Threaded
Open this post in threaded view
|

Re: Resource Adapter for JMS 2.0 and Connector 1.7

IIT Software
Administrator
You can already use JMS 2.0 by using Apache Qpid JMS client which uses AMQP 1.0 as underlying protocol. Just connect to SwiftMQ.
Reply | Threaded
Open this post in threaded view
|

Re: Resource Adapter for JMS 2.0 and Connector 1.7

TheQL
I can forward that to our developers, but my gut feeling tells me we would prefer a native solution with SwiftMQ.
We definitely need XA transactions to work, not sure if that's possible in the workaround scenario.