[
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