Hi Paul
I have just committed the initial code to trunk/2.2.x-SNAPSHOT. Please see [1],
[2], [3].
What is there now should probably work for most of the cases (topics/queues, including the JMS transactions support). Transactions
will work if custom exceptions have not been caught by JAXRS mappers (won't be an issue once the JAXRS exception mapping code is
moved into fault interceptors). The remaining work will have to do with some internal cleanup (ex, CXF JAXRS uses HttpUtils to get
protocol headers which might've come over JMS). Plus possibly coming up with better JMS property names (see [1]). I'll also add a
custom context later on called ProtocolHeaders which will just reuse HttpHeadersImpl imternally, using ProtocolHeaders will give the
code which needs the headers a more transprot-neutral code.
here're some comments regarding [1] and [2].
- you only need to add a transportId to a given jaxrs endpoint, thus you can have the same bean getting data over different channels
(http/jms) by referencing it from say 2 endpoints.
- check a jaxrs:server/serviceName attribute - you don't have to use but this is how you can nominate a service name for a jaxrs
endpoint, default is {http://reverse.package.name}ServiceClassName
- see how a jms destination is configured, it uses queues, but topics can also
be configured. See [4] for more details
here're JMS properties which can help with matching a required method :
- "Content-Type" : default is "text/xml"
- "Accept" : default is "*/*"
- "OnewayMessage" : default is "false", that is a JMSReplyTo proeprty has to be set on the incoming message if "OnewayMessage" is
not set or false
- "org.apache.cxf.message.Message.REQUEST_URI" : default is "/"
- "org.apache.cxf.message.Message.HTTP_REQUEST_METHOD" : default is "POST"
as far as REQUEST_URI is concerned, it is initially matched against a
jaxrs:server/@address.
So if REQUEST_URI is not set or set to "/" then jaxrs:server/@address has to be set to "/". If REQUEST_URI is set to "/bar/foo" and
jaxrs:server/@address is set to "/bar" then it will be '/foo' which will be used to find a root resource class and its method...
I'd appreciate if you could try this feature and see if you can get data from
JMS topics...
Thanks, Sergey
[1] http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSJmsTest.java (JMS
client)
[2]
http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/resources/jms_server_config.xml
[3]
http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JMSServer.java
[4] http://cwiki.apache.org/CXF20DOC/jms-transport.html
Hi
Is it possible to use a JMS Transport for JAX-RS (JSR-311) web service
endpoint ?
I'm interested in implementing an ATOM consumer service using abdera
(AtomEntryProvider), for both HTTP (RESTful) and JMS (topic
subscription) transports.
Thanks
Paul
