What I wanted to say is that the spec and TCK should be clear about the fact that PATCH has to work on the client side. I say so because non-standard http methods did not work in Jersey until I proposed that patch years back, so apparently there was nothing in the TCK which tried out this methods and I like to have it waterproof this time.
-----Original Message-----
From: Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
Sent: Montag, 17. April 2017 14:48
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: HTTP PATCH on the client
Not sure where are you going with this, but the question was whether this is a problem for implementations.
Having something in the specification is one thing, being able to implement that specification on a standard platform, is the other.
In any way, the conclusion for now has already been stated - patch on the client stays.
Regards,
Pavel
On 15/04/2017 15:19, Markus KARG wrote:
> Pavel,
>
> actually I did not follow the Java SE 9 mailing list (the Java SE 9 and Java EE 8 schedules change so often that I don't see any sense anymore in staying up-to-date), so thank you for letting me know abot the incubation status.
>
> The question is, whether this is really a problem for JAX-RS? Implementations which currently utilize HttpUrlConnection in their client (like Jersey) already, well, do a really really bad thing and I am very sorry for having proposed that Jersey patch back then. ;-) On the other hand, this means that implementations are free to do other bad things stll, like dynamically checking the current JRE version: If it is 8, the existing trick still should work. If it is 9, the implementation can use the new incubated API. If it is 10, hopefully it finally finds a stabilized HTTP Client. Or, the implementation could simply allow the application programmer to decide which underlying technology stack to use, e. g. Jersey could provide modules for Apache HttpClient, the existing trick upon HttpUrlConnection, and the Java 9 incubated API.
>
> So for me, this is just one tweak more around another JRE insufficiency in the JAX-RS implementations. The essential point wrt to JAX-RS API is that the spec PDF clearly must tell anybody that ANY compliant JAX-RS client MUST provide all needed technology to perform PATCH methods. Otherwise adoption of the PATCH method makes not much sense.
>
> -Markus
>
>
> -----Original Message-----
> From: Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
> Sent: Freitag, 14. April 2017 12:11
> To: jsr370-experts_at_jax-rs-spec.java.net
> Subject: Re: HTTP PATCH on the client
>
> If you'd follow Java SE 9 mailing lists, you'd know that it won't be part of Java SE 9 distribution.
>
> Http Client will be distributed as an incubator module to gather community feedback and soften some edges in the API.
>
> Regards,
> Pavel
>
> On 14/04/2017 12:04, Markus KARG wrote:
>> If you are right with Java SE 9, the question is, what Oracle's plans with the new http Client is? Is it ready to be used?
>>
>> -----Original Message-----
>> From: Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
>> Sent: Freitag, 14. April 2017 11:44
>> To: jsr370-experts_at_jax-rs-spec.java.net
>> Subject: Re: HTTP PATCH on the client
>>
>> This will most likely stop working when running on Java SE 9 on module path, since it removes (well, almost) the possibility to access private fields on classes provided by the platform.
>>
>> Anyway, let's keep the API in current state (patch methods on the
>> client
>> side) for now, since there are no major objections in doing that.
>>
>> Thanks for your responses.
>> Pavel
>>
>>
>> On 13/04/2017 19:27, Markus KARG wrote:
>>> I think it should actually be possible to do http PATCH with HttpUrlConnection when it is patched in the way Jersey does it already. Using that patch Jersey Client is able to do SEARCH and PROPFIND, so it should also do PATCH.
>>>
>>> -Markus
>>>
>>> -----Original Message-----
>>> From: Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
>>> Sent: Donnerstag, 13. April 2017 16:13
>>> To: jsr370-experts_at_jax-rs-spec.java.net
>>> Subject: HTTP PATCH on the client
>>>
>>> Dear experts,
>>>
>>> as you might know, we recently introduced support for @PATCH and corresponding methods in the Client part of the API.
>>>
>>> There is one catch - HttpUrlConnection doesn't support making PATCH requests.
>>>
>>> Its known JDK issue and it won't be fixed. HttpUrlConnection was supposed to be replaced by HttpClient in Java SE 9, but .. that won't happen and it wouldn't fix our issue, since JAX-RS 2.1 implementation is stuck on Java SE 8 for now.
>>>
>>> That doesn't mean PATCH on the client cannot be implemented, the
>>> only issue is that the implementation would need to use something
>>> else than HttpUrlConnection, implying that there must be some other
>>> HTTP (client
>>> side) framework involved, or it could be re-implemented using standard Java networking API.
>>>
>>> Jersey already has some means how to overcome that limitation, but by default we still do use HttpUrlConnection.
>>>
>>> Sergey, what about CXF? Do you use HttpUrlConnection on the client side?
>>>
>>> Does anyone else know how is this handled in other implementations?
>>>
>>> We still could support @PATCH on the server side without having it on the client, so dropping that part is certainly an option, but we'd like to hear your thoughts.
>>>
>>> Thanks and regards,
>>> Pavel
>>>
>>>
>