You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Sergey Beryozkin (JIRA)" <ji...@apache.org> on 2012/06/15 14:07:43 UTC

[jira] [Resolved] (CXF-4378) Refactor HttpURLConnection out of JAX-RS AbstractClient.setResponseBuilder()

     [ https://issues.apache.org/jira/browse/CXF-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Beryozkin resolved CXF-4378.
-----------------------------------

    Resolution: Duplicate

Please see https://issues.apache.org/jira/browse/CXF-3562
                
> 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