Hi Jan,
They why does GF return an error page rather than no entity, which
kind of adds to the confusion?
[I am seem to be having a deja-vu moment that we may have discussed
this before! ]
IMHO servlet makes it hard for frameworks to build on top of if they
have to decide to call setStatus or sendError.
The following would be more consistent:
1) GF does not return a default error page;
2) deprecate sendError; and
3) if the status code set in setStatus is >= 400 and there is no
entity then if there is an error page for that status
code then that error page will produce the response entity.
I think i can work around things in Jersey for GF v3, but this may
break things for GF v2.1 since response headers are not sent.
Do you know if this is fixed in GF v2.1.1?
Also do you know how i can obtain the GF version being used?
Paul.
On Oct 15, 2009, at 9:04 PM, Jan Luehe wrote:
> On 10/15/09 10:05, 魔 wrote:
>> well,it seems the specification of HttpServletResponse has told us
>> that the SetStatus(int) method should not set a error code for the
>> response.
>> here is the reference for the SetStatus(int) method:
>> void setStatus(int sc)Sets the status code for this response. This
>> method is used to set the return status code when there is no error
>> (for example, for the status codes SC_OK or SC_MOVED_TEMPORARILY).
>> If there is an error, and the caller wishes to invoke an error-page
>> defined in the web application, the sendError method should be used
>> instead. And I also believe it would be better if the
>> setStatus(404) returns the error page declared in the web.xml .
>>
>
> The intended behaviour of HttpServletResponse#setStatus was clarified
> in response to bullet 5 of the comments posted at
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=2885
> ("Possible HttpServletResponse Javadoc mistakes and inconsistencies")
>
> HttpServletResponse#setStatus now reads:
>
> * <p>If this method is used to set an error code, then the
> container's
> * error page mechanism will not be triggered. If there is an error
> and
> * the caller wishes to invoke an error page defined in the web
> * application, then {_at_link #sendError} must be used instead.
>
>
> Jan
>
>> forlml.
>> ----- Original Message ----- From: "Paul Sandoz"
>> <Paul.Sandoz_at_Sun.COM>
>> To: <dev_at_glassfish.dev.java.net>
>> Sent: Thursday, October 15, 2009 9:07 PM
>> Subject: Re: Servlet error pages and sendError, setStatus
>>
>>
>>
>>> On Oct 15, 2009, at 2:48 PM, Paul Sandoz wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> Attached is a simple Web application with two servlets and a JSP
>>>> error page for 404 response status codes.
>>>>
>>>> The SetStatusServlet does the following when servicing a request:
>>>>
>>>> response.addHeader("X-FOO", "foo");
>>>> response.setStatus(404);
>>>>
>>>> The SendErrorServlet does the following when servicing a request:
>>>>
>>>> response.addHeader("X-FOO", "foo");
>>>> response.sendError(404);
>>>>
>>>>
>>>> I used GF v3 preview for testing with the following results:
>>>>
>>>>
>>> Correction, i used GF v3 Prelude.
>>>
>>> GF v2.1 has the same behavior.
>>>
>>> Same for Tomcat and GF v3 b66 except that the X-FOO response
>>> header is present in both case.
>>>
>>> Paul.
>>>
>>>
>>>> 1) When SetStatusServlet serves the request the default GF 404
>>>> error page is returned, not the error page
>>>> declared in the web.xml. The X-FOO header is present.
>>>>
>>>> 2) When SendErrorServlets serves the request the error page
>>>> declared in the web.xml is returned. The X-FOO
>>>> header is not present.
>>>>
>>>> Is this an issue or a spec requirement.
>>>>
>>>> If this is a spec requirement should we have a GF feature to
>>>> relax this. So when say a response is returned with no response
>>>> entity (no bytes written to the servlet response output stream)
>>>> that error pages can be invoked.
>>>>
>>>> Paul.
>>>>
>>>> < WebApplication15 .zip
>>>>> ---------------------------------------------------------------------
>>>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>