Hi Henrik
> Hi Sergey. Thanks again for the response. I stepped through the
> JAXRSOutInterceptor in the debugger and found out that the content type
> for the Response I had created was "octet/stream" instead of
> "application/xml". Once I created the appropriate content type entry in
> the MultivaluedMap returned by getMetadata() method, everything worked.
JAXRS spec requires "octet/stream" be set if no content type has been set by
the user code (either implicitly by specifying
@Produces or returning a custom Response, etc)....Please see more comments below
>
> While on that subject, is that the appropriate way of doing it? What I
> ended up doing was something like the code snippet below. Apologies for
> the bad formatting, I'm using Evolution to send the email...
>
> // "error" is our error placeholder bean sent back as the entity
> final Response newResponse = builder.entity(error.validate()).build();
> newResponse.getMetadata().putAll(oldResponse.getMetadata());
> final MultivaluedMap<String, Object> map = newResponse.getMetadata();
>
> if (! map.containsKey(HttpHeaders.CONTENT_TYPE))
> {
> final List<Object> contentTypes = new ArrayList<Object>();
> contentTypes.add("application/xml");
> map.put(HttpHeaders.CONTENT_TYPE, contentTypes);
> }
> else
> {
> final List<Object> contentTypes = map.get(HttpHeaders.CONTENT_TYPE);
>
> if (! contentTypes.contains("application/xml"))
> {
> contentTypes.add("application/xml");
> }
> }
>
> A little clumsy maybe, but I was trying to preserve whatever content
> types the original response had as well as making sure that the new
> response declares "application/xml". Any suggestions on how to clean
> this up and do it properly are appreciated. Anyway, after inserting this
> code snippet, things work all the way back to the browser, and I see the
> exception entity in XML form. Thanks,
This code is fine, and indeed, it is importnat that the headers which might'be
been set earlier on are not lost. Though you might
want to simplify it a bit, MultivaluedMap supports a putSingle() method, so you
can do :
final MultivaluedMap<String, Object> map = newResponse.getMetadata();
map.putSingle(HttpHeaders.CONTENT_TYPE, "application/xml");
given that it is "application/xml" which is required in this case ?
One thing I'm concerned a bit about is that if the generic exception reporting
logic is done in a ResponseHandler and/or
RequestHandler filters then even normal non-exceptional requests or responses will go through them, so you probably do some kind
of
a check to see if it's an exceptional invocation or not...I don't think it affects in any measurable way the overall performance
but
it's worth mentioning that few more options are available (sorry for not
mentioning them in the first place)...
First, all the exceptions which have not been mapped to responses by registered providers will be propogated (or is it
'propagated'
:-) ?)
to the container wrapped in ServletExceptions. So one other option is to register a simple ServletFilter which will only will
only
handle ServletExceptions and check the causes and write to the
HttpServletResponse as needed.
Another option is is to register a CXF out fault interceptor with the jaxrs:server. I'll be working on a test which will show how
to
do it. This fault interceptor will be executed only if the propogation has been disabled through a jaxrs:server property and if
no
matching ExceptionMappers are available. I'll let you know once the system test
is ready.
That said, I reckon using JAXRS filters should do well - may be I will add the
support for the in/out fault JAXRS filters too...
thanks, Sergey
>
> /Henrik
>
> On Tue, 2009-11-03 at 18:25 -0500, Sergey Beryozkin wrote:
>> Hi Henrik
>>
>> I reckon looking at the wire representation would really help in
>> figuring out what's going on. Also, can it be that say the XStream
>> writer needs to have some kind of close() method being called ?
>>
>> Please send a wget/browser request through a tcp trace utility and let
>> me know the details
>>
>> Thanks, Sergey
>>
>> -----Original Message-----
>> From: Henrik Martin [mailto:[email protected]]
>> Sent: 03 November 2009 22:03
>> To: [email protected]
>> Subject: Re: Would like to send custom XML back whenever a 400 or 500
>> category error happens
>>
>> Sergey, thanks for the response. I should have given you a little more
>> detail. In my handleResponse() method, I do return a Response, which
>> contains something similar to your suggested ExceptionInfo. It's just a
>> Java bean containing some properties and some XStream annotations. When
>> I run everything in the debugger, I can see that my entity (containing
>> the exception information) gets handled by our MessageWriter, and proper
>> XML gets generated (I'm printing it out inside the MessageWriter). This
>> is what's puzzling me, I never see the XML after that.
>>
>> I don't get any exceptions being thrown anywhere, so I don't think it's
>> a failure of any kind. Our MessageWriter is registered to handle any
>> type thrown at it. It basically uses XStream to stream out the beans
>> into XML. It seems to work fine. If I set the HTTP status code to 200
>> and return the exact same exception data, it gets streamed out properly
>> all the way back to the client. I'm curious to what the difference is in
>> execution path when I'm setting the HTTP status to a 400 or 500? I've
>> tried following along in the debugger, but there are so many levels of
>> calls that it's a little overwhelming. Is there some sort of error
>> handler in the CXF framework that takes different paths depending on the
>> value of the HTTP status code? Thanks,
>>
>> /Henrik
>>
>> On Mon, 2009-11-02 at 17:11 -0500, Sergey Beryozkin wrote:
>> > Hi Henrik
>> >
>> >
>> >
>> > For some reasons I can only see your message in Archives, but not
>> > Nabble.
>> >
>> >
>> >
>> > >>The handleResponse() method in
>> > >>my filter gets called, but I've found that if I return any kind of
>> > >>error, i.e. a category 400 or 500 type error, the XML that I'm
>> > returning
>> > >>as the content doesn't get rendered in the browser
>> >
>> > If one returns a custom Response from a filter, then its entity, if
>> any,
>> > will be
>> > serialized by the available writers.
>> >
>> > So if you set a String instance as a custom entity and you happen to
>> > have a custom message body writer which can
>> > wrap Strings then the browser would show it as a plain text sequence.
>> >
>> > Starting from CXF 2.2.4 it is possible to indicate that writers have
>> to
>> > be ignored. In meantime, the best way would be to return
>> > an object like ExceptionInfo which will be serialized by the
>> appropriate
>> > XML writer.
>> >
>> > Is it what might be happening in your case ?
>> >
>> > If you're thinking of doing JAXRS only then filters should do well.
>> >
>> > Cheers, Sergey
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
