[
https://issues.apache.org/jira/browse/VELTOOLS-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497584
]
Nathan Bubna commented on VELTOOLS-83:
--------------------------------------
As Claude said, the writing output directly is the default for performance and
also for backwards compatibility at this point. However, i'd be open to a
patch that allows this to be configured to behave as you describe.
> 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]
