Send me the trace please. Enable a Logging in/out interceptor or use a
tcp trace utility. Also make sure @Produces has two distinct String
values, not "application/xml, application/json"
Sergey
On 15/09/11 22:37, KARR, DAVID wrote:
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Thursday, September 15, 2011 2:27 PM
To: [email protected]
Subject: Re: Why isn't a service similar to another one not respecting
the "Accept" header?
I think I know the reason.
Are you seeing this issue during the tests ?
When doing something like this:
WebClient wc = WebClient.create("http://bar";);
wc.accept("application/json");
wc.get();
wc.accept("application/xml");
wc.get();
?
When a single instance is used, it accumulates header values, for those
headers which can have multiple values. The earlier version probably
did
not do it.
So the above is equivalent to
wc.accept("application/json").accept("application/xml");
wc.get();
wc.get();
or
wc.accept("application/json", "application/xml");
wc.get();
wc.get();
Thus if you prefer to use a single WebClient instance, then do
webClient.reset() between the .accept() calls.
I'll also add resetHeader() or replaceHeader to make things simpler for
cases like this, as reset would also reset queries.
Sorry, but my test case is even simpler than this. I just send a single value for the "Accept" header of
"application/xml". It doesn't seem to have any effect. If I instead use the ".json" extent on the request,
that works fine. This may be moot as the latter may be easier for our scenarios than setting the "Accept" header, but
I am somewhat concerned that the "Accept" header doesn't appear to be recognized anymore.
On 15/09/11 22:08, Sergey Beryozkin wrote:
Actually, reproduced, hmm, looks like a regression possibly caused by
the optimizations around JAXB-related providers -
Sergey
On 15/09/11 21:53, Sergey Beryozkin wrote:
Works for me OK.
I have @Produces({"application/json", "application/xml"})
and then use WebClient to accept json or xml, works as expected.
How does a request URI look like ? Does Accept has only a single
value,
can you capture the http trace ?
Thanks, Sergey
On 15/09/11 21:42, Sergey Beryozkin wrote:
Testing now...
Cheers, Sergey
On 15/09/11 21:18, KARR, DAVID wrote:
-----Original Message-----
From: KARR, DAVID
Sent: Thursday, September 15, 2011 11:23 AM
To: [email protected]
Subject: Why isn't a service similar to another one not
respecting the
"Accept" header?
I've had a CXF-based REST service in production for a little
while. It
changes its response format either with the "Accept" header, or
by
extension. I get xml with "Accept:application/xml" or if I add
the
".xml" suffix to the request. Similarly, I get JSON with the
analogous
values for JSON. This service is using Jackson for its JSON
representation.
I now have another service that will go to production soon. Using
the
suffix for xml or json works fine. However, it seems to ignore
the
"Accept" header. My "@Produces" annotation has both
"application/json"
and "application/xml", in that order. I get JSON by default, and
I
still get JSON if I send "Accept:application/xml" as an HTTP
header.
Just to make sure, I retested this same mechanism with the other
service, and it correctly changes the format based on the
"Accept"
header.
One difference between the two services is that the new service
isn't
using Jackson, it's using the default (Jettison, I assume).
Otherwise,
the "jaxrs:server" and other configuration is almost identical
between
the two services.
Another difference is that the new service is using CXF 2.4.2, and
the
older service is using CXF 2.3.3.
Before I start pasting in my configuration and code, are there
any
simple reasons why this might not be working?
