Paul Sandoz wrote:
>
> On Dec 1, 2008, at 10:27 AM, Craig McClanahan wrote:
>
>> Paul Sandoz wrote:
>>> Hi Rod,
>>>
>>> In addition to what Craig states, which i think is good advice, i am
>>> wondering if there is a way to configure servlet to stop
>>> automatically adding an HTML error page to responses.
>>>
>> From my experience, you get an error page from the app server *only*
>> when an exception is actually thrown out to the server itself. Using
>> an exception mapper in the manner I described avoids this, because
>> the exception is (correctly) *not* thrown to the server.
>>
>
> When you return a response for the mapped exception do you always set
> a response entity?
I do in my Jersey based code.
> I am guessing the underlying issue is that no response entity is set
> in the response, so the servlet engine looks at the status code and
> chooses a default response entity.
>
It's been a couple of years since I worked on Tomcat, but AFAIK it does
not pay any attention to the entity body (or lack thereof) when an
exception in caught by the container. It assumes that it can simply
replace the response if an exception is caught by the container. I
suspect GF and other servers do something similar.
>
>> In the poster's original example, AFAICT, there is no default
>> exception mapper for WebApplicationException (which is something we
>> in jersey-land should think about), so it *does* (again, AFAICT ... I
>> use the exception mapper techniques, so I have never encountered this
>> myself) get thrown out, and therefore causes the default app server
>> behavior.
>>
>
> WebApplicationException is never passed through to the servlet layer
> (tis a bug if that occurs). A WebApplicationException always contains
> a Response instance, and mapping only occurs if the Response does not
> contain an entity:
>
> private void mapWebApplicationException(WebApplicationException e,
> HttpResponseContext response) {
> if (e.getResponse().getEntity() != null) {
> onException(e, e.getResponse(), response);
> } else {
> if (!mapException(e, response)) {
> onException(e, e.getResponse(), response);
>
> }
> }
> }
>
> private static void onException(Throwable e,
> Response r,
> HttpResponseContext response) {
> // Log the stack trace
> if (r.getStatus() >= 500) {
> LOGGER.log(Level.SEVERE, "Internal server error", e);
> }
>
> if (r.getStatus() >= 500 && r.getEntity() == null) {
> // Write out the exception to a string
> StringWriter sw = new StringWriter();
> PrintWriter pw = new PrintWriter(sw);
> e.printStackTrace(pw);
> pw.flush();
>
> r = Response.status(r.getStatus()).entity(sw.toString()).
> type("text/plain").build();
> }
>
> response.setResponse(r);
> }
>
Hmm ... definitely worth further investigation. But shouldn't Jersey
swallow WebApplicationException *always* (by virtue of providing a
default ExceptionMapper), whether or not there was an entity?
>
> Paul.
Craig
>
>> Craig
>>> I am CC'ing the glassfish users list to see if anyone can help.
>>>
>>> Paul.
>>>
>>> On Dec 1, 2008, at 5:18 AM, Rod Fitzsimmons Frey wrote:
>>>
>>>> Hi there. I’m having some trouble wrapping my head around
>>>> ResponseBuilder and how it handles error flow conditions. My
>>>> apologies if this question belongs on another list: I’m a refugee
>>>> from rails and I’ve not quite internalized the various boundaries.
>>>>
>>>> My problem is that I’d like to respond to a REST request with a
>>>> particular error code and nothing else, but I can’t get rid of the
>>>> default Glassfish HTML error page. I’ve got a @Post method that
>>>> returns the created object, which is annotated with
>>>> @XMLRootObject. Works like a champ for the regular flow, but for
>>>> duplicate create requests I tried to send a 409 Conflict:
>>>>
>>>> if(userDAO.findUserByEmail(email) != null) {
>>>> throw new WebApplicationException(409);
>>>> }
>>>>
>>>> Which when invoked with curl gave me the 409 as desired, plus a big
>>>> XHTML error page. I have also tried changing the return type to a
>>>> Response and using
>>>>
>>>> return Response.noContent().status(409).build();
>>>> return Response.status(409).entity("").build();
>>>> return Response.status(409).build();
>>>>
>>>> all of which return the HTML error page. I’ve tried sending 409s
>>>> to a blank.html page in the web.xml but that didn’t work either (I
>>>> found out why in an archive search
>>>> here: https://jersey.dev.java.net/servlets/ReadMsg?listName=users&msgNo=484
>>>> <https://jersey.dev.java.net/servlets/ReadMsg?listName=users&msgNo=484>
>>>>
>>>> I have a feeling this is a RTFM moment but I can’t find the
>>>> appropriate M to FR. Any help would be greatly appreciated.
>>>>
>>>> Rod
>>>
>>
>