[
https://issues.apache.org/jira/browse/VELTOOLS-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498383
]
Nathan Bubna commented on VELTOOLS-83:
--------------------------------------
No interest in a patch to make the VVS switch between the two behaviors based
on a configuration option? I can see other people wanting this too, so it
seems most worthwhile to support this fully rather than just make it possible
via extension.
As for whether the current implementation is wrong... i would argue that the
real problem is that there was an exception during the template rendering stage
at all. often, this is a sign of too much "pull" and not enough "push"
happening in the webapp. if you're concerned about the users seeing an error
page, then this is a sign that the webapp is not ready for production anyway.
So i really do prefer the faster choice here and would encourage anyone
developing a significant webapp to do all database calls, business logic, and
other things that legitimately throw exceptions to ensure their app completes
those before beginning to render the view. In other words, i see the vanilla
VVS's error output as being for developers, not end users. Keep things put
into the view context as benign as possible. This is why most VelocityTools
that do anything likely to throw exceptions will catch them and return null.
Tools shouldn't throw any exceptions. Neither should the toString() of any
object you put into the context.
That said, i understand that there are always exceptions to such things and
smaller, simpler apps may find it most productive to do more "pull" work and
not worry about performance issues with buffering the whole view. So i'd be
quite happy to make this behaviour configurable. In fact, i'll probably look
into making a patch for this myself if you don't beat me to it. ;)
> VelocityViewServlet returns 200 OK on error
> --------------------------------------------
>
> Key: VELTOOLS-83
> URL: https://issues.apache.org/jira/browse/VELTOOLS-83
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
> Affects Versions: 1.3
> Reporter: bruce sherrod
>
> When VelocityViewServlet reports and error (e.g. if an exception is thrown
> from a $reference.method()), it returns a detailed error page with status 200.
> This interoperates with the web container poorly, as it cannot be caught and
> redirected to a nice error page in a production environment (e.g. through the
> <error-page> mechanism in web.xml).
> This is complicated by the fact that VelocityViewServlet writes directly to
> the HttpResponseServlet writer, so once the template processing has begun, it
> is no longer possible to call HttpServletResponse.sendError() and send, say,
> a "500 Internal Server Error", which would be more appropriate.
> Here is a patch: change VelocityViewServlet.mergeTemplate() so that it
> buffers to a StringWriter, and only writes to the HttpServletResponse writer
> after the merge is completed.
> This way, users can override VelocityViewServlet.error() to call
> response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR) if desired.
> protected void mergeTemplate(Template template,
> Context context,
> HttpServletResponse response)
> throws ResourceNotFoundException, ParseErrorException,
> MethodInvocationException, IOException,
> UnsupportedEncodingException, Exception
> {
> VelocityWriter vw = null;
> // write to a temporary string buffer, so that if we have to
> bail
> // and call HttpServletResponse.sendError(), we still can -- bs
> //Writer writer = getResponseWriter(response);
> StringWriter sw = new StringWriter();
> try
> {
> vw = (VelocityWriter)writerPool.get();
> if (vw == null)
> {
> vw = new VelocityWriter(sw, 4 * 1024, true);
> }
> else
> {
> vw.recycle(sw);
> }
> performMerge(template, context, vw);
> }
> finally
> {
> if (vw != null)
> {
> try
> {
> // flush and put back into the pool
> // don't close to allow us to play
> // nicely with others.
> vw.flush();
> // really write to the
> HttpServletResponse
> String output =
> sw.getBuffer().toString();
> Writer writer =
> getResponseWriter(response);
> writer.write(output);
> /* This hack sets the VelocityWriter's internal ref to the
> * PrintWriter to null to keep memory free while
> * the writer is pooled. See bug report #18951 */
> vw.recycle(null);
> writerPool.put(vw);
> }
> catch (Exception e)
> {
> velocity.getLog().debug("VelocityViewServlet: " +
> "Trouble releasing VelocityWriter: " +
> e.getMessage());
> }
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
