Currently PageContext.handlePageException() uses a
RequestDisplacher.forward() to invoke the errorPage specified
for a JSP. If the response has been committed, you get useless
output because of the IllegalStateException thrown by the
forward() call.
Would it be a spec violation to test if the response is committed
and use include() instead if it is? I think I have heard that this
is how others avoid this problem.
All I could find in the spec is that handlePageException()
should "redirect" the to the error page. Does this mandate
that forward() should be used? If not, I think it would be a
big plus to make this change in 3.2b7.
Larry
> -----Original Message-----
> From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 10, 2000 3:10 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [Resend] Ready for 3.2b7?
>
>
> Hi Craig,
>
> I have been fighting fires all day and am just now getting to the
> item I mentioned in my e-mail last night. I agree that the new
> exception handling now implements the correct behavior :-), but the
> default output in debugging situations (showDebugInfo=true) is less
> than it was earlier.:-( It used to display the request that actually
> generated the error as well as the top level request. Now it only
> shows the top level request. Also, it appears that it can now
> throw "masking" IllegalStateExceptions in situations that it didn't
> before. I would like to see what can be done to achive the old
> default output with the new exception handling.
>
> Most working on JSP here at SAS aren't into looking at log files. It
> is much easier to punch in my extension.:-( I am not sure how
> important this is to the Tomcat community at large, but I view it
> as very important for SAS Institute's use of Tomcat 3.2. However, I
> have no problem making any updates to fix this local to SAS's copy of
> Tomcat 3.2 if it not deemed worth delaying beta7 to get it in.
>
> Thanks,
> Larry
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, November 10, 2000 2:29 PM
> > To: [EMAIL PROTECTED]
> > Subject: [Resend] Ready for 3.2b7?
> >
> >
> > (Resending because it didn't show back up in my inbox --
> sorry if you
> > get this twice)
> >
> > It's been a week now, and I've committed > 20 patches to
> the 3.2 tree,
> > ranging from simple tweaks to security problems to spec compliance
> > bugs. I believe that I've gotten all of the critical bug reports
> > submitted on the mailing lists or via BugRat. Does anyone
> know of any
> > I've missed (see below for one issue I know is outstanding)?
> >
> > What I'd like to do is build a "beta 7" release this
> > afternoon and post
> > it. That will give people a chance to pound on it. Any
> critical bugs
> > we find will need to be fixed, but we need to hold off on changing
> > non-essential stuff so we can get a final 3.2 release out the door.
> >
> > NOTE: One issue that's been discussed in the last couple of days is
> > problems supporting the "load balancing" feature for root
> webapps. I
> > haven't seen a proposed patch for this, but understand from
> > the comments
> >
> > of people that have tried kludges to work around it -- and it seems
> > unreasonable to risk destabilizing things at this late date.
> > I suggest
> > that any work on fixing this problem be deferred to a post-3.2-final
> > maintenance cycle.
> >
> > Craig McClanahan
> >
> > PS: Thanks to everyone for all the bug reports, and to Larry
> > and Nacho
> > for chipping in on the commits!
> >
> > PPS: When the 3.2 final release is completed, my personal focus is
> > going to return to the Tomcat 4.0 code base (which does not
> > suffer from
> > any of the bugs patched in 3.2, although I did find one 4.0
> bug along
> > the way :-). If and when bugs show up in 3.2 final, I will
> > be happy to
> > commit patches that people supply -- but any big debugging effort or
> > major new work on the 3.x track will need to be done by
> someone else.
> >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > 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]
