On 26/06/13 11:52, Fabio Martelli wrote:
Il 26/06/2013 12:42, Sergey Beryozkin ha scritto:
Actually, it may be a CXF bug, looking into it...
Thank you for your help.
Unfortunately the target server is not CXF and it doesn't support
tunneling.

I have to suspend developments waiting for future feedback from your side.

Sure, I'll update you. You may want to work directly with Apache HTTP Client in meantime if it is urgent - as for the CXF bug it will be fixed in the next release (not far away):

https://issues.apache.org/jira/browse/CXF-5093

Thanks, Sergey


Thank you again.
Regards,
F.


Sergey

On 26/06/13 11:04, Sergey Beryozkin wrote:
Hi

Please see comments below,

On 26/06/13 10:05, Fabio Martelli wrote:
Il 25/06/2013 18:49, Sergey Beryozkin ha scritto:
Here is the way to do it

// truly async
@Test
    public void testRetrieveBookAsync() throws Exception {
        String address = "http://localhost:"; + PORT +
"/bookstore/retrieve";
        WebClient wc = WebClient.create(address);
        Future<Book> future = wc.async().method("RETRIEVE",
Book.class);
        Book book = future.get();
        assertEquals("Retrieve", book.getName());
    }



or

// async transport is used to do the sync call
    @Test
    public void testRetrieveBookAsync2() throws Exception {
        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);
        assertEquals("Retrieve", book.getName());
    }

and add the dependency:

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

Thanks to Dan for making it so flexible, very nice
Hi Sergey, thank you for your prompt reply.
I adopted the second solution. Read below

         // set request content type
client.accept("application/atom+xml").type("application/atom+xml");
         // configure async http conduit
WebClient.getConfig(client).getRequestContext().put("use.async.http.conduit",


true);
         // execute
         final Response res = client.invoke("PATCH", is);

The previous exception disappeared but, unfortunately, it's still not
working.
Now it seems that I missed the Content-Type header.

     <?xml version="1.0" encoding="utf-8"?>
     <m:error
xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata";>

         <m:code />
         <m:message xml:lang="en-US">Content-Type header value
missing.</m:message>
     </m:error>

Performing a print of all defined headers accessed by
client.getHeaders() I can found the Content-Type header defined and
well
valued.
The statement
client.accept("application/atom+xml").type("application/atom+xml") is
not enough?

I've tested a bit more, I think it may be an Http Client bug.
If I use AsyncConduit with say "POST" then I can see both "Content-Type"
& "Accept" headers. As soon as I replace "POST" with "RETRIVE" (custom
method that I use) I see the headers being lost...

Let me investigate a bit more...

By the way, one other option which might be worth trying: is the target
server implemented with CXF ? If yes then you can avoid using an Async
HTTPConduit and use say "POST" but also add a header
"X-HTTP-Method-Override: PATCH" or a query parameter, "_method=PATCH".

As a side note, I've investigated the possibility of updating
HttpURLConnection 'methods' field but it happens to be 'final' so no
luck there.

Cheers, Sergey

Thank you in advance for your help.

Best regards,
F.


Sergey

On 25/06/13 17:10, Sergey Beryozkin wrote:
Hi

The problem is that HTTPUrlConnection does not support HTTP
methods it
is not already statically aware of.

One option will be likely to use the HTTP async transport (which Dan
made to work even in the sync mode) - that one is based on Apache
HTTPClient, another option is to attempt to statically modify
HTTPURLConnection...


Let me experiment a bit and get back to you.

Thanks, Sergey

On 25/06/13 16:49, Fabio Martelli wrote:
Hi All,
I'm facing with the WebClient in order to send a PATCH request to an
OData service.
I tried with the following statement

final Response res = client.invoke("PATCH", obj);

but the following exception has been thrown

javax.ws.rs.client.ClientException:
javax.ws.rs.client.ClientException:
org.apache.cxf.interceptor.Fault: Could not send Message.
     at
java.net.HttpURLConnection.setRequestMethod(HttpURLConnection.java:428)


     at
org.apache.cxf.transport.http.URLConnectionHTTPConduit.setupConnection(URLConnectionHTTPConduit.java:119)





     at
org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:467)


     at
org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46)





     at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)





     at
org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain(AbstractClient.java:607)





     at
org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:1017)





     at
org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:855)
     at
org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:829)
     at
org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:294)
     .....

Is there someone that can help me to achieve my target?

Thank you in advance.

Best regards,
F.











Reply via email to