On Jan 12, 2010, at 4:10 PM, glassfish_at_javadesktop.org wrote:
>>
>> On Jan 12, 2010, at 3:25 PM,
>> glassfish_at_javadesktop.org wrote:
>>
>>>> Check out the javax.ws.rs.ext.ExceptionMapper
>>>> interface.
>>>
>>> Thank you. I spent some time looking at this
>> interface and don't
>>> think it will change anything for me. It looks
>> like I would create
>>> an exception mapper if I wanted JAX-RS to know
>> about an existing
>>> exception in my application. I am throwing an
>> exception that
>>> extends WebApplicationException, and the
>> constructor does the same
>>> thing as the example code in the Jersey
>> documentation.
>>>
>>
>> I think an ExceptionMapper might be an acceptable
>> workaround. It is
>> possible to support an ExceptionMapper for
>> WebApplication and in that
>> mapper you could add an entity, if one is not
>> present, e.g. a String
>> with one space character.
>
> I still don't understand how this will be different than extending
> WebApplicationException, which is part of JAX-RS and lets me provide
> the Response object in the constructor.
>
There might be cases where WebApplicationException is thrown directly
or from extending classes e.g. by the runtime. Having an
ExceptionMapper operating on WebApplicationException allows you to
catch all cases (for which there is sub-classes mapped).
>
>>> I don't think the problem is Jersey or JAX-RS. I
>> think when
>>> GlassFish sees an application returning an HTTP
>> error code, it first
>>> looks to see if the application has defined error
>> pages to display.
>>> If not, then it displays its own error pages. This
>> is undesirable
>>> for REST APIs since it totally rewrites the headers
>> and body. The
>>> only way I could find to get around it is to make
>> sure I output an
>>> entity body when returning an error. Then
>> GlassFish seems to let it
>>> through.
>>>
>>
>> Another solution is to add error pages to the
>> web.xml:
>>
>>
>> ttp://java.sun.com/developer/EJTechTips/2003/tt0114.ht
>> ml
>>
>> But ideally an option to switch off such default page
>> support would be
>> most useful.
>
> In my message above, I talked about application defined error pages,
> the same thing you mentioned here. My message is about creating a
> REST web service that returns an error as part of the API, and not
> wanting GlassFish to do anything but pass it to the client as-is. I
> don't want to return a web page.
> I want to return exactly what my programming told GlassFish to
> return, so defining error-pages in web.xml completely defeats the
> purpose.
Agreed, it was a suggestion to workaround GF restrictions.
Paul.