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 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.
> 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);
}
Paul.
> 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
>>>
>>> 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
>>
>