Hi Andy
Note that the other alternative is to use CXF Apache HTTP Client based
conduit, cxf-rt-transports-http-hc, if it is on the classpath then CXF
(Dan did it) will use HttpClient by default, and as far as I recall
(I've no editor opened right now) CXF RS Client (in AbstractClient code)
will instruct whatever HTTP conduit is loaded to run a non-async request
synchronously.
Have you tried cxf-rt-transports-http-hc ? My understanding CXF RS async
requests (those part of 2.0 API for ex) can only be truly async when
this conduit is loaded.
Dan can provide more info but I believe when the async requests run over
the HttpUrlConnection CXF may be blocking the thread (at the sync HTTP
Conduit level) and using the internal pool, something like that...
As far as enabling the reflective use of HttpUrlConnection by default:
it is probably a good idea indeed.
What will happen when CXF is run in a Java 9 VM though ?
Thanks, Sergey
On 14/07/17 18:36, Andy McCright wrote:
Hi All,
With more and more people using different HTTP methods (verbs) with the
JAX-RS client - particularly PATCH, but really any method they want - is
there any objection to making the "use.httpurlconnection.method.reflection"
true by default in CXF 3.2.X?
Here is some background:
Java SE's HttpUrlConnection's setRequestMethod() implementation restricts
callers to the following HTTP methods: GET POST HEAD OPTIONS PUT DELETE
TRACE - if any other HTTP method is passed in, then the caller will get a
ProtocolException.
This is very limiting and prevents users for invoking increasingly common
HTTP methods like PATCH, some of the WebDAV methods, etc. Ideally, the JDK
would alter the list of allows HTTP methods (or provide a mechanism for
users to specify a whitelist of allowed methods), but at best that won't
occur until Java 9.
CXF worked around this problem by adding the
"use.httpurlconnection.method.reflection" property - this can be set as a
system property or as a property on the Message object. When true, CXF
will reflectively modify the state of the HttpURLConnection object
(bypassing the setRequestMethod's parameter check) and set the user's
specified HTTP method.
With JAX-RS 2.1 adding out-of-the-box @PATCH support, I suspect more and
more users will want to use HTTP methods not in the JDK's current
whitelist. Rather than asking them to set this property, I think it might
make more sense to enable the property by default (they could always
disable if they feel it is a risk).
Any thoughts? If there are no objections, I can make the change.
Thanks,
Andy
