Re: [Resin-interest] Resin 3.1, RequestDispatcher, include() and forward()

2008-02-28 Thread Ilya Kasnacheev
В сообщении от 27 Февраль 2008 19:30 Huitang Li написал(a):
 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.

Well, I've switched to struts 1.3.8 as you suggested, but exception is still 
in place. I guess I'll have to redesign my app a bit.


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


Re: [Resin-interest] Resin 3.1, RequestDispatcher, include() and forward()

2008-02-27 Thread 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.


 ___
 resin-interest mailing list
 resin-interest@caucho.com
 http://maillist.caucho.com/mailman/listinfo/resin-interest
   


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest