You could write a servlet Filter that will buffer the output, and after
the tiles execute the filter will determine whether to send the output
to the client.  If the filter determines that an error occurred then is
can forward to the displaySystemError.do.  You will have to write a
HttpResponseWrapper and pass that through the FilterChain.  This is not
recommended if you have large HTML pages because every request you will
have at some point the entire page in memory.

-james

On Fri, 2003-06-06 at 09:23, Hohlen, John C wrote:
> The "clearBuffer()" method didn't affect anything.  The error page was still
> surrounded by all the other Tiles being rendered.  I then tried "clear()"
> and it caused the following exception:
> 
> java.lang.IllegalStateException: response already committed at
> weblogic.servlet.jsp.JspWriterImpl.clear(JspWriterImpl.java:35) 
> 
> That's pretty much in-line with expectations according to documentation on
> "JSPInsider.com":
> 
> clear()
> This method clears the ENTIRE content of the current buffer. If the buffer
> has been already been flushed then the clear operation throws an IOException
> error since the page's data has already been irrevocably written to the
> client response stream. Also when not using buffering calling this method
> will throw an IOException error. 
> 
> clearBuffer() 
> Clears the current contents of the buffer. This function will not return an
> exception if the buffer has already been flushed. 
> 
> So I'm still stumped.  The behavior I'm looking for may not be possible.
> 
> JOHN
> 
> -----Original Message-----
> From: Mike Jasnowski [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2003 9:56 AM
> To: Struts Users Mailing List
> Subject: RE: [Tiles] Forwarding To JSP Error Page From Within Tiles
> (Help!)
> 
> 
> You might try buffering the output of your pages, so they aren't committed.
> But not sure that's the ideal solution.  Another possibility is on the
> error.jsp, you can programmatically clear the output writer of any content
> it may have already buffered, then write out the stuff in your error.jsp you
> want to display.
> 
>       out.clearBuffer();
> 
> There might be other solutions though.
> 
> HTH,
> Mike
> 
> -----Original Message-----
> From: Hohlen, John C [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2003 10:47 AM
> To: Struts-User (E-mail)
> Subject: [Tiles] Forwarding To JSP Error Page From Within Tiles (Help!)
> 
> 
> This is a continuation of a post I submitted yesterday as an "off topic"
> subject entiled:
> 
> "[OT] web.xml <error-page> configuration problem"   (Special thanks to David
> Graham for his many replies):
> 
> Currently, this isn't showing up in the archives so I couldn't provide a
> link. However, I feel this is no longer an "off topic", but rather a
> Tiles/JSP topic.  The issue I'm facing is how to forward to an error page
> (JSP) when a runtime exception (e.g. NullPointerException) occurs within my
> JSP Tile.  Currently, I've added the following directive to each of my JSPs:
> 
> <%@ page errorPage="/jsp/error.jsp" %>
> 
> I'd prefer to only specify this information in one place, but I can't figure
> out how to do that either.  The "<error-page>" setting in the web.xml
> doesn't appear to work for JSPs, just regular Java code inside the web
> container.  Now, when an exception occurs in a Tile JSP, my error screen is
> displayed, but it's inserted into the page with all the other Tiles
> displayed as well.  This can look really ugly depending on which Tile the
> exception occurs in.  What I would I would prefer to do is automatically
> forward to a brand new screen.  David Graham gave me the idea of redirecting
> to a Struts action:
> 
> <%@ page errorPage="/displaySystemError.do" %>
> 
> But this causes the following exception:
> 
> java.lang.IllegalStateException: Cannot forward a response that is already
> committed
> 
> I think that makes since b/c of the other Tiles (JSP Servlets) that have
> already been processed and committed HTML to the output writer.  So I'm
> stumped at this point.  Please reply if anyone has any bright ideas.
> 
> Thanks,
> 
> JOHN
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to