Chris Dolan created CXF-4378:
--------------------------------
Summary: 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
