Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Subject: Re: Enable reflective use of HttpURLConnection by default?
To: dev@cxf.apache.org
References: <CAB=WQ1GVaC_Fj1H8HXjVi_DR6fwDZJoia91bb38xtF94KzTa7Q@mail.gmail.com>
 <16762d6d-d8b5-409a-3736-947c1d8da26a@gmail.com>
 <CAB=WQ1EWKJwAMOLCPYSm-WEHmBHO6NRvo70iC3sW0NiNiKoWeA@mail.gmail.com>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <57206d33-2065-6e40-dde8-366530b39ede@gmail.com>
Date: Tue, 18 Jul 2017 18:58:06 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAB=WQ1EWKJwAMOLCPYSm-WEHmBHO6NRvo70iC3sW0NiNiKoWeA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
archived-at: Tue, 18 Jul 2017 15:58:24 -0000

Hi Andy

Thanks for the explanation too.
I've no objections to enabling this property by default. I guess it can 
be reviewed again later on if Java 9 (and JPMS) are used.
May be lets wait for a couple of days for Dan, Alessio others to respond,

I agree it is very reasonable to expect that various HTTP verbs just 
work with CXF clients...

Sergey

On 17/07/17 23:28, Andy McCright wrote:
> 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 <sberyozkin@gmail.com>
> 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
>>>
>>>
> 


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/