On Feb 2, 2010, at 6:43 PM, Chris Carrier wrote:
> That seemed to work well for me. There is one problem I'm having with
> it though and that's that it is always rendering the error entity in
> XML (not JSON). This is what my ExceptionMapper looks like:
>
> @Provider
> @Component
> public class MyExceptionMapper implements
> ExceptionMapper<WebApplicationException> {
>
> @Override
> @Produces(MediaType.APPLICATION_JSON)
> public Response toResponse(WebApplicationException e) {
> MyObj errorResult = new MyObj();
> errorResult.setError("Some text);
> //errorResult.setRequest(uri.getPath());
> errorResult.setVersion("1.0");
>
> return
> Response
> .status(e.getResponse().getStatus()).entity(errorResult).build();
> }
> }
>
> Should the Produces annotation apply in this case? If not how do I
> tell it to map my object in JSON?
>
JAX-RS does not currently define @Produces semantics on
ExceptionMapper classes.
You need to specify the media type in the response builder:
return Response.fromResponse(e.getResponse()).type("application/
json").entity(errorResult).build();
For any complete solution you will need to check the status code and
if any entity exists for e as your application may, in the future say,
throw a WebApplicationException or an extension of.
Paul.
> Thanks!
> Chris
>
> On Tue, Feb 2, 2010 at 7:22 AM, Robert Koberg <rob.koberg_at_gmail.com>
> wrote:
>>
>> On Feb 2, 2010, at 6:21 AM, Paul Sandoz wrote:
>>
>>>
>>> On Feb 2, 2010, at 3:08 PM, Robert Koberg wrote:
>>>
>>>>
>>>> On Feb 2, 2010, at 2:15 AM, Paul Sandoz wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Jersey will always throw a WebApplicationException for HTTP
>>>>> error-based responses, and only the status code (and potentially
>>>>> some headers) will be set, the entity will not be set.
>>>>>
>>>>> So you can register an ExceptionMapper for
>>>>> WebApplicationException.
>>>>>
>>>>> JAX-RS/Jersey will re-throw any exception that is not mapped to
>>>>> the container.
>>>>>
>>>>> Thus for full mapping i recommend doing the following:
>>>>>
>>>>> - register an ExceptionMapper<WebApplicationException> to modify
>>>>> responses, perhaps specific to the HTTP status code.
>>>>>
>>>>> - register an ExceptionMapper<Throwable> to catch all other
>>>>> exceptions, perhaps with a generic response signaling a 500
>>>>> sever error.
>>>>
>>>>
>>>> In Tomcat, the only way I could see how to ensure all errors come
>>>> back as JSON, was to create a Tomcat specific Valve that extends
>>>> org.apache.catalina.valves.ErrorReportValve. For Tomcat at least,
>>>> the default error valve is hard coded to write out HTML (not even
>>>> XHTML).
>>>>
>>>
>>> Yes, the Tomcat layer can also produce error responses.
>>>
>>> Did you try using an ExceptionMapper? in what cases did it not
>>> work for you?
>>
>>
>> If I remember correctly, I needed it because I also had a custom
>> realm and authenticator at the tomcat level. So, I am guessing, the
>> exceptions were occurring before it got to Jersey.
>>
>> -Rob
>>
>>
>>>
>>>
>>> I forgot to mention an edge cases on mapping exceptions:
>>>
>>> - when writing the response only the mapping of
>>> WebApplicationException is performed, and only if the response has
>>> not been
>>> committed (one or more bytes written).
>>>
>>> perhaps that is a mistake and JAX-RS should relax it and any
>>> exception can be mapped if the response has not been committed?
>>>
>>> Paul.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>