Hi, all you need to do is this:
> add a cxf-rt-transports-http-hc (Maven) dependency and set a WebClient
> "use.async.http.conduit" property when doing the calls - or use
> WebClient async() switch to use JAX-RS 2.0 AsyncInvoker - and do not
> set that property at all
WebClient.getConfig(rsClient).getRequestContext().put("use.async.http.conduit",
true);
or set that property as a Bus property once, ex, assuming a default bus
is used,
BusFactory.getDefaultBus().put("use.async.http.conduit", true);
or, instead, do
Future<Book> f = webClient.async().get(Book.class);
Book b = f.get();
Sergey
On 21/10/15 09:20, Khare, Aparna wrote:
Hi,
I tried doing this
AsyncHTTPConduit conduit = (AsyncHTTPConduit)
WebClient.getConfig(rsClient).getConduit();
But this is also not working.
Can you please let me know when we can expect the fix as you mentioned that
this will be fixed in the coming release
Thanks,
Aparna
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
Sent: Tuesday, October 20, 2015 6:09 PM
To: users@cxf.apache.org
Subject: Re: Apache CXF overriding the Content-Type when using WebClient for GET
Hi
The overriding issue (well, there are actually cases when legacy 3rd
party servers do need a CT with GET :-)) was also fixed in 3.0.6 - it
was confirmed recently, re the async conduit:
add a cxf-rt-transports-http-hc dependency and set a WebClient
"use.async.http.conduit" property when doing the calls - or use
WebClient async() switch to use JAX-RS 2.0 AsyncInvoker - and do not set
that property at all
HTH, Sergey
On 20/10/15 13:30, Khare, Aparna wrote:
Thanks Sergey but what I found was that even if I pass some other Content-Type
it is not overriding and it is giving the same issue.
Meanwhile I will try using AsyncHTTPConduit
Thanks,
Aparna
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
Sent: Tuesday, October 20, 2015 4:53 PM
To: users@cxf.apache.org
Subject: Re: Apache CXF overriding the Content-Type when using WebClient for GET
I agree, that was done to bypass some perceived proxy issues too, but
see the conclusion at
http://cxf.547215.n5.nabble.com/Why-does-CXF-JAX-RS-set-content-type-on-GET-requests-with-no-body-td5759908.html#a5760854
I'm going to update the code just in time for the incoming 3.0.7/3.1.3
releases.
In CXF 3.0.4 you can do the following as a workaround:
- use CXF AsyncHTTPConduit (in the sync mode) - this is easy to set up
can provider more info if it can be of interest
- or temp set some valid CT value just to get passed the proxy
Thanks, Sergey
On 20/10/15 11:42, Khare, Aparna wrote:
Hi,
We are actually trying to hit a proxied endpoint
I have seen that the following request headers are sent from my code where I
use the webclient to make a GET call .The code snippet is already shared in my
previous mail
{
"name": "Accept",
"value": "*/*",
"$$hashKey": "0WF"
},
{
"name": "Content-Type",
"value": "*/*",
"$$hashKey": "0WI"
},
Whereas when I use the same with the browser or with REST Client it works.
I feel that web client adds the content-length header by default in case of
GET request .
The problem is the proxied endpoint(Third party api) would fail in case the
Content-Type Header */* is set.
To replicate the same I passed the same header in the REST client and it failed
there as well .My only concern is that the Content-Type should not be passed by
default .
Thanks,
Aparna
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
Sent: Tuesday, October 20, 2015 4:02 PM
To: users@cxf.apache.org
Subject: Re: Apache CXF overriding the Content-Type when using WebClient for GET
Hi
FYI, it is possible to disable CXF setting a CT by default in CXF 3.0.6
- and some work was done to ensure no CT is set for GET by default.
What exactly does not work ? Can you clarify please
Cheers, Sergey
On 20/10/15 11:21, Khare, Aparna wrote:
Dear Colleagues,
I'm using version 3.0.4 .I have seen that the Content-Type is
appended automatically in case of GET request.
The same thing works in REST client and same url does not work when I invoke
with webclient it fails
Please see my code snippet
WebClient rsClient = null;
try {
baseURI = new URI(client.getURL());
rsClient = WebClient.create(baseURI);
if (rsClient != null) {
prepareClient(rsClient);
processResponse(rsClient.get());
}
}
Thanks,
Aparna
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
