[ 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