Anonymous | Login | Signup for a new account | 12-17-2024 08:55 PST |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0002481 | [Resin] | minor | always | 03-03-08 09:17 | 06-11-08 13:36 | ||||
Reporter | ferg | View Status | public | ||||||
Assigned To | ferg | ||||||||
Priority | normal | Resolution | fixed | ||||||
Status | closed | Product Version | 3.1.5 | ||||||
Summary | 0002481: RequestDispatcher forward | ||||||||
Description |
(rep by Ilya Kasnacheev and Huitang Li) This is an excellent finding. I got the same IllegalStateExceptions as well when jsp:include a struts1 action with resin 3.1.4. I tested with struts 1.0.x, 1.1.x, and 1.2.x, I got the same error. However, when I tried struts 1.3.8, this exception disappeared. I posted the similar question on the list several weeks ago, and I was suggested to use the switch flush="false", which actually did not make any difference. If anyone knows the solution for avoiding this exception with struts versions less than 1.3.x, please let me know. Thanks. Ilya Kasnacheev wrote: I've found one thing in resin 3.1 regarding RequestDispatcher, include() and forward() Let's suppose we have a ServletResponse, and we've wrote some text into its output stream, so it's now in "committed" state. That means, as J2EE spec tells, that we can no longer do forward() on it, or we'll get an IllegalStateException. In the meantime we can do include() on it, including the response from random URI into result document. So we include() a chain of struts1 actions into it. They're going to forward() the request until the end of chain is reached. As I've found out, this will result in a shower of IllegalStateExceptions being thrown. Interesting thing that, despite those exceptions, actions successfully transfer control from one to another, eventually finishing processing and writing everything they need to. Now the weird thing is: On the first side, include()d document can be thought as being processed independently. Basically it should behave as if you fetched that page by using HTTP and then printed it into output stream. So, forward() should work because there is no reason for it to not work - because it would work in the case of outside request. On the second side, include()d document gets unmodified ServletResponse from parent servlet, which have its buffer committed, and I guess there are no easy ways to tell whenever forward() was called from include()d servlet, where it is fine, or from the parent servlet, where it's a no-no I can't say I have a question about resin, I just wanted to share that bunch of facts and thoughts with you. P.S. Having said that, I find the original limitation on forward() rather annoying. I guess it's supposed to ensure cookies and headers neither being written into document nor discarded, and also prevent from outputting half of one html document and then outputting the whole another html document. That's the well known "We didn't want to let you shoot yourself in the foot so we duct taped your fingers together; and also, we wanted to prematurely optimise a bit" antipattern clearly. |
||||||||
Additional Information | |||||||||
Attached Files | |||||||||
|
Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
28 total queries executed. 25 unique queries executed. |