[ 
https://issues.apache.org/jira/browse/CXF-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294791#comment-13294791
 ] 

Chris Dolan commented on CXF-4378:
----------------------------------

Daniel, perhaps but the setResponseBuilder method looks like this:

{code}
HttpURLConnection conn = 
(HttpURLConnection)outMessage.get(HTTPConduit.KEY_HTTP_CONNECTION);
if (conn == null) {
    throw new ClientWebApplicationException("HTTP Connection is null"); 
}
...
for (Map.Entry<String, List<String>> entry : conn.getHeaderFields().entrySet()) 
{
    ...
}
{code}

So, the HttpURLConnection is currently unavoidable.

                
> 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

        

Reply via email to