Hi Sergey, Thanks for the suggestion. I'll definitely give cxf-rt-transports-http-hc a try.
As for what will happen in Java 9 with using reflection, it will work by default now that Oracle has decided to ship with the "kill-switch" enabled (i.e. the JPMS module system will be disabled by default). However, if a user were to enable JPMS, then this reflection approach would also fail. So wrt to this transport, PATCH and other "non-standard" HTTP methods will not work with JPMS enabled. Given that, your suggestion to use Apache HTTP Client makes more sense. Still, I'll plan to change the default for 3.2 to use reflection unless anybody objects. Thanks again, Andy On Sat, Jul 15, 2017 at 11:38 AM, Sergey Beryozkin <[email protected]> wrote: > 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 >> >>
