This is better:

http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/e52f33586140/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#l1271

only Trace is restricted in Java8 sun.net code, this is OpenJdk but the chances are good...So we'll get it working fine with the new Java 8 trunk

Sergey
On 21/08/15 11:16, Sergey Beryozkin wrote:
Looks like we are still out of luck here,

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/sun/net/www/protocol/http/HttpURLConnection.java?av=f#1068


Sigh...
Sergey
On 21/08/15 10:27, Sergey Beryozkin wrote:
Hi Dan

I thought, wow, did CXF ReflectionUtil was so powerful it could get the
'final' HttpUrlConnection 'methods' array modified, given that the
'methods' is checked in HttpUrlConnection.setRequestMethod, and trying
to modify 'methods' was my best but unlucky try, lol.

Let me only update the property name, just to make the code
(tooling/etc) which may rely on this property (temporarily at least) a
bit more 'respectable' :-), say,
"use.httpurlconnection.method.reflection".

Thanks, Sergey

On 20/08/15 19:04, Daniel Kulp wrote:

On Aug 20, 2015, at 8:55 AM, Sergey Beryozkin <sberyoz...@gmail.com>
wrote:
Yes, indeed, thanks,

and as to why HTTPUrlConnection keeps blocking HTTP verbs even with
the latest versions - you'd need to ask at Java forums. People use
new verbs like PATCH or WebDav verbs so it is strange that such verbs
are still not supported in JDK - at least they could've introduced a
property which, if enabled, would let HTTPUrlConnection accept any
HTTP verb.


I just added a property to our HttpURLConnection based conduit which
will use a bit of reflection to set the method if the call to
setRequestMethod throws the exception.   I’ve defaulted this to false
to keep the current behavior as it is a hack and may not work in
certain scenarios (security manager may prevent it, other JDK may have
different field name, etc…).

You can set a contextual property of “httpurlconnection.method.hack”
to true (or as a system property read at startup) and it will trigger
using the reflection.  That should allow things like PATCH to work
without that async client.

Dan




@Patch annotation has been added to save some users from typing their
own JAX-RS HttpMethod extensions - which is what JAX-RS recommends,
if JAX-RS API itself has no the annotation for a given HTTP method
then can support such a method with a JAX-RS HttpMethod-based
annotation

Cheers, Sergey
On 20/08/15 13:34, Jose María Zaragoza wrote:
2015-08-20 11:46 GMT+02:00 PatrikStas <patrik.s...@gmail.com>:
Hi everyone !

I've been trying to get the @PATCH method get working for a while
now but
with not further success.
I've noticed it haven't been present in CXF 3.0.2, but been added
to CXF
3.1.2 into the package package org.apache.cxf.jaxrs.ext; ( it's
missing in
documnetation tho )

When I try to use PATCH method to call my service, I get
*
Caused by: java.net.ProtocolException: Invalid HTTP method: PATCH
         at
java.net.HttpURLConnection.setRequestMethod(HttpURLConnection.java:428)*



The setRequestMethod is looking for methodn name in statically
defined list
of methods, defined as
*
     private static final String[] methods = {
         "GET", "POST", "HEAD", "OPTIONS", "PUT", "DELETE", "TRACE"
     };*

And since it doesn't find PATCH, it throws
*
         throw new ProtocolException("Invalid HTTP method: " +
method);*

Browsing forums and mailing lists, I found these posts here :

http://comments.gmane.org/gmane.comp.apache.cxf.user/25919

Saying I can use async transport and then the PATCH should work

*         String address = "http://localhost:"; + PORT +
"/bookstore/retrieve";
          WebClient wc = WebClient.create(address);

WebClient.getConfig(wc).getRequestContext().put("use.async.http.conduit",


true);
          Book book = wc.invoke("RETRIEVE", null, Book.class);*


However, even if I try to call my service like this, it's still
failing.

I think that you need to include cxf-rt-transports-http-hc

<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http-hc</artifactId>
<version>${cxf.version}</version>
</dependency>


Moreover even if this would work, I find it a bit hacky. Why is
PATCH not
supported, if it's been added to CXF ?

I have other services working properly, the only service which are
throwing
this exception are the ones annotated with @PATCH.

What is the problem ?

Thanks a lot in advance for any tips !
Patrik










--
View this message in context:
http://cxf.547215.n5.nabble.com/PATCH-Method-is-failing-tp5760309.html

Sent from the cxf-user mailing list archive at Nabble.com.


--
Sergey Beryozkin

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






Reply via email to