On 01/13/10 01:22 PM, glassfish_at_javadesktop.org wrote:
>> Earlier in this thread, you mentioned a quote from
>> the W3C
>> specification for HTTP response codes in the 4xx and
>> 5xx ranges:
>>
>> Except when responding to a HEAD request, the
>> server SHOULD include
>> an entity containing an explanation of the error
>> situation.
>> This is where the default error page comes into the
>> picture.
>>
>> If you don't have any error pages configured for your
>> app and want to
>> bypass the default error page, you could do something
>> like this in your
>> servlet's service method:
>>
>> try {
>> // some code here
>> } catch (Throwable t) {
>> response.setStatus(500);
>> response.flushBuffer();
>> // rethrow
>> throw new ServletException(t);
>> }
>> ld that work for you?
>>
>
>
> I am not writing a servlet -- I am writing a JAX-RS service so that does not work for me.
>
>
I know, my comment was more targeted towards the Jersey integration
servlet, and therefore Paul.
I'm not familiar with any Jersey implementation details, but I suspect
that when you output an entity body to the JAX-RS response (when
returning an error), this will commit the corresponding HTTP response,
and therefore, the web container's error page mechanism (and its
default error page) will be completely bypassed, even if a matching
error page
existed. In other words, the GlassFish web container won't "take over
the response",
as you put it.
If I understood your original request correctly, you wanted to be able
to get the above behaviour (of GlassFish not interfering with your
response) *without* having to provide an entity in the JAX-RS response.
As I mentioned earlier, the Servlet spec requires that the web
container use the sendError method to send 4xx and 5xx status
responses, so that the error mechanism may be invoked. sendError is
required to clear the response buffer and return the contents of the
error page. Note that the web container will *not* invoke sendError
semantics if the response has already been committed.
So the trick is to ensure that the response has already been committed
when it is returned through the web container. Apparently, outputting
an entity to the JAX-RS response has this effect, but perhaps the
Jersey integration servlet could commit (under the circumstances
mentioned in this thread) the response even if no entity body has been
written.
Jan
> However, if GlassFish is following the W3C and servlet specifications to the letter, then I should be including an entity body whenever returning an error status. When I return an entity body, GlassFish lets it through. I think this morning I tested with error pages configured in web.xml, and GlassFish allowed my response to be sent as-is to the client even though an error page was defined for that error number. That is what I want to happen. I suspect removing my entity body would have caused GlassFish to display the appropriate error webpage.
>
>
> Thanks,
> Ryan
> [Message sent by forum member 'rdelaplante' (ryan_at_ijws.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=380759
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>