Re: Better handling of template exceptions in web applications.

On 4 August 2011 20:02, Daniel Dekany <[email protected]> wrote:

> Thursday, August 4, 2011, 2:56:04 AM, Geoff Shuetrim wrote:
>
> > The suggestion to just set the buffer size to something big is a
> > lot simpler than trying to change the actual writer being used by
> > the response.  I will try it out and see if the performance impact
> > of always using a large buffer is manageable.
>
> Assuming the implementators of the Servlet API wasn't lame, why would
> any other solution be more efficient? You have to buffer the output
> somewhere if you don't send it immediately.
>

Only because, for the majority of pages, the huge buffer is not necessary
and so always allocating it is wasteful.  I have been using a buffering
writer that is like String writer except that it uses a different system for
dynamically increasing buffer size.  Then you have small buffers being used
for smaller pages and infrequent buffer size increases for the large pages.
What is optimal should, in the end, depend on the distribution of web page
sizes in the web application.


>
> > One last warning to anyone else looking to use this approach when
> > they are also using Stripes layout tags: the template process method
> > is called every time a template is used by the layout system.  That
> > means that if the template processing exception is thrown by one of
> > the content components used by a layout and not by the layout
> > itself, then any attempt to redirect the response in the
> > ServletExceptionHandler seems to be ignored.  What I have found to
> > work is to send appropriate HTML content to the response writer when
> > the exception is encountered and then that content is included in
> > the layout instead of the content that would have been generated by
> > the template that triggered the exception.  It is not ideal but I
> > cannot figure any way to get back to the original response and to
> redirect it.
>
> That's not good. Is it only so with FreeMarker? If Template.process
> fails, the exception should propagate up to the layout causing that to
> fail too... I guess...
>

I think it would happen for JSP pages also.  I was catching the
ServletException as soon as it was detected in the Servlet.doGet/doPost
methods and then dealing with it immediately by attempting to perform the
redirect to the error page.  That was failing. Now I am letting the
exception propagate up as you describe but even so, that is not sufficient.
I also need to be:

1.  Using the one buffering writer for all Template.process() calls,
throughout the recursion.
2. Only sending the content written to that buffer to the response writer
once I am sure that no ServletExceptions were raised through the recursion
process.  That is being managed in the postTemplateProcess method.
3. Keeping track of where I am at in the recursive set of Template.process()
calls, the writer being used for buffering the results of template
processing, and any ServletExceptions produced, as attributes of the
request.  It works now but is a fair bit more complex than I had
anticipated.

Regards

Geoff S

[snip]

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1

_______________________________________________
FreeMarker-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemarker-user