On 01/24/2012 08:53 AM, Alan Wright wrote:
> We are running a struts based application inside Resin.
> In cases where a runtime error occurs for jsp pages (eg expected objects
> referenced on the page not found in the session) it seems that the
> response has already been generated partially when the error occurs and
> then the error page as specified in our resin.xml gets added to the
> response and sent to the client browser.
> Because we are using gzip, this results in content encoding errors in
> the browser because it seems as if the error page is gzipped inside the
> main response which is also gzipped (I am guessing that this is what is
> occuring). If the gzip filter is disabled we get the part complete
> response with the error page tagged onto the end and a non functioning
> web page.
> Error pages are specified in resin.xml for the application as follows:
> Is this something that Resin should be able to handle, or is it just
> inevitable in the face of jsp runtime errors? Is there something we
> should do or configure to prevent the response being sent untill the jsp
> has processed without error?
Runtime errors are tricky because of the flushed buffer issue.
You can increase the JSP buffer size (though I'd generally not recommend
it because it chews up memory.)
When possible it's best to verify everything before rendering anything.
So if it's a known possibility that data could be missing, to add a
check at the top. That wouldn't help true runtime errors, though.
I don't think there's much Resin can do besides the above. Once the data
is flushed, it can't really be fixed.
> Thanks for any suggestions.
resin-interest mailing list