[
https://issues.apache.org/jira/browse/VELTOOLS-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna resolved VELTOOLS-83.
----------------------------------
Resolution: Fixed
Fix Version/s: (was: 2.x)
2.0
Ok, as of the next VelocityTools 2 release (hopefully 2.0 final), you can now
set
org.apache.velocity.tools.bufferOutput to true in your init params for the
VelocityViewServlet, and it will buffer the output as requested here. Default
for that is still false, though, at least for now.
> 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
> Fix For: 2.0
>
>
> 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]
