You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Michael-O <19...@gmx.net> on 2012/11/28 16:58:54 UTC
Invocation condition of ErrorReportValve
Hi,
why does the ErrorReportValve trigger the report on this condition only?
if ((statusCode < 400) || (response.getContentCount() > 0))
return;
So, even if I do a reponse.setStatus(404), this valve is executed. According to the Javadoc: if setStatus is invoked [1], the response should be left untouched in constrast to the sendErroor method. Especially this sentence makes it clear "If this method is used to set an error code, then the container's error page mechanism will not be triggered. "
Shouldn't that include a response.isError() check?
[1] http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#setStatus%28int%29
Thanks,
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Invocation condition of ErrorReportValve
Posted by Michael-O <19...@gmx.net>.
Am 2012-11-28 18:26, schrieb Mark Thomas:
>
>
> Michael-O <19...@gmx.net> wrote:
>
>> Hi,
>>
>> why does the ErrorReportValve trigger the report on this condition
>> only?
>>
>> if ((statusCode < 400) || (response.getContentCount() > 0))
>> return;
>>
>> So, even if I do a reponse.setStatus(404), this valve is executed.
>> According to the Javadoc: if setStatus is invoked [1], the
>> response should be left untouched in constrast to the sendErroor
>> method. Especially this sentence makes it clear "If this method is
>> used to set an error code, then the container's error page
>> mechanism will not be triggered. "
>>
>> Shouldn't that include a response.isError() check?
>>
>> [1]
>> http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#setStatus%28int%29
>
>>
> Yep. This sort of thing drives me nuts with the Servlet spec. The
> document is mean to be definitive but isn't. Half the requirements
> are in the Javadoc and the Javadoc is no longer included in the
> specification (for no good reason) and the spec lead refuses to add
> it back in. You used to be able to search one doc for a phrase,
> method, class, whatever and find all the references. Now it is right
> pain to figure out what the expected behaviour is.
>
> Raise a bugzilla entry for this one and it'll get looked at and
> (assuming there is a problem as there does appear to be from the
> fragment you quoted) it will get fixed.
Mark,
issue has been created:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54220
I have depicted a new possible condition based on the Javadocs and the
spec. Please have look.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Invocation condition of ErrorReportValve
Posted by Mark Thomas <ma...@apache.org>.
Michael-O <19...@gmx.net> wrote:
>Hi,
>
>why does the ErrorReportValve trigger the report on this condition
>only?
>
> if ((statusCode < 400) || (response.getContentCount() > 0))
> return;
>
>So, even if I do a reponse.setStatus(404), this valve is executed.
>According to the Javadoc: if setStatus is invoked [1], the response
>should be left untouched in constrast to the sendErroor method.
>Especially this sentence makes it clear "If this method is used to set
>an error code, then the container's error page mechanism will not be
>triggered. "
>
>Shouldn't that include a response.isError() check?
>
>[1]
>http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#setStatus%28int%29
Yep. This sort of thing drives me nuts with the Servlet spec. The document is mean to be definitive but isn't. Half the requirements are in the Javadoc and the Javadoc is no longer included in the specification (for no good reason) and the spec lead refuses to add it back in. You used to be able to search one doc for a phrase, method, class, whatever and find all the references. Now it is right pain to figure out what the expected behaviour is.
Raise a bugzilla entry for this one and it'll get looked at and (assuming there is a problem as there does appear to be from the fragment you quoted) it will get fixed.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org