[
https://issues.apache.org/jira/browse/CXF-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295613#comment-13295613
]
Sergey Beryozkin commented on CXF-4378:
---------------------------------------
> First off, I realized this is a bit of a wacky request. My use case may be an
> abomination, but my specific request is modest. :-)
Funny :-)
JMS is supported for JAX-RS endpoints on the server side and I do not see why
proxies can not use JMS. Obviously it's not about REST :-) but more about
reusing the existing code for doing messages not only over HTTP but optionally
over JMS - which does make sense IMHO.
Please also watch https://issues.apache.org/jira/browse/CXF-4350, Willem has
provided a patch for proxies to support the "jms" scheme, hope to work on
applying it next week.
As far as this issue is concerned, it happens to be a duplicate of
https://issues.apache.org/jira/browse/CXF-3562, which I've resolved just now by
applying the patch from Willem, so I'll close it as Duplicate.
Thanks
> Refactor HttpURLConnection out of JAX-RS AbstractClient.setResponseBuilder()
> ----------------------------------------------------------------------------
>
> Key: CXF-4378
> URL: https://issues.apache.org/jira/browse/CXF-4378
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Affects Versions: 2.6.1
> Reporter: Chris Dolan
> Priority: Minor
>
> First off, I realized this is a bit of a wacky request. My use case may be an
> abomination, but my specific request is modest. :-)
> My current project experimentally bridges JAX-RS request/response over a JMS
> bus. Services are declared with JAX-RS annotations on Java interfaces.
> Clients are created with JAXRSClientFactory, but with a proprietary URL
> schema instead of "http://"; and I have registered a proprietary Conduit
> implementation instead of the usual HTTPConduit.
> So far, so good. The request side of the JAX-RS client code is actually very
> nicely abstracted from the conduit, so there's no assumption about HTTP. On
> the response side, however, the AbstractClient.setResponseBuilder() method
> assumes that there must be an HttpURLConnection attached to the message. If
> the message already has its own InputStream (mine does) then this
> URLConnection is used just to get the header values back out.
> To work around this, I had to make a hack like this in my Conduit
> implementation:
> {code}
> MockHttpURLConnection conn = new MockHttpURLConnection(url);
> conn.putHeader("Yada", "yada-yada-yada");
> message.put(HTTPConduit.KEY_HTTP_CONNECTION, conn);
> {code}
> where MockHttpURLConnection basically just wraps a Map for header values.
> I request that AbstractClient be altered so it expects either a
> KEY_HTTP_CONNECTION or a new type of KEY_HTTP_HEADERS, which is perhaps a
> simple MultiMap or an actual Headers instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
