Here is not a solution, while it gives some insights on java sevelet spec and jsp spec:
http://today.java.net/pub/a/today/2005/08/04/jspcomponents.html?page=3#jsp_servlets_compatibility In this article, it referred to old resin versions, I believe. Probably this can be helpful for resin developers to consider the issue and help resolve the "already committed" or "illegal state" exceptions. By the way, for the issue in the post "[Resin-interest] Resin 3.1, RequestDispatcher, include() and forward()", I do not know how struts 1.3.8 is configured on your machine and your application code. However, the "illegal state" exception did disappear when we upgraded to struts 1.3.8 in the web app with resin 3.1.4. The code causing that exception previously is: <jsp:include page="/blah/blah/strutsAction.do"/> Hope this helps. Ilya Kasnacheev wrote: > В сообщении от 7 Март 2008 15:48 Mattias Jiderhamn написал(a): > >> If I understand your question: the reason the DispatchResponse is >> committed is that you have called .flush() explicitly on the original >> HttpServletRequest (HttpResponse). >> > Yeah, that's what I did exactly. It would have committed it even if I didn't, > provided I print enough text into out. > > >> This is nothing strange. Why could you want to create a wrapper to >> "hide" the commited state, so that you can perform forward??? >> forward means "instead of" >> include means "also" >> > Well, the problem is that: > include is like > page <- include page > but including struts1 action is like > page <- include (forward -> forward -> forward -> forward -> page) > > The problem is that resin would not let me to forward, normally, when I > include() such chain and buffer is already committed. > This is wrong for two reasons: first, forward() in included servlet does not > mean "instead of including page" but "instead of included page", and second, > inclue()ing document should I guess yield same result as fetching it via HTTP > and then pasting. > > >> You cannot first generate or include content, flush it to the client >> (sent over the network to the web browser) and then say "Oh wait, I >> changed my mind, I want to send this content instead" (=forward). >> > Nope. I've changed my mind inside included document, I want to send different > content *to be included*. > > In fact, included document should have own distinct stream which itself might > be committed or not, can be reset and so on.. > Resin cheats this for speed and thus have only one stream for both main and > included documents. > But that breaks struts. > > >> If your design requires that the response is not commited, there is >> something wrong with your desing. >> > Sorry, can't do anything with that. Need to do actual work instead of > rewriting struts. > > >> An alternative approach, if for some reason you must do it this way, is >> to create wrapper classes that put the included content in a buffer >> (think ByteArrayOutputStream) until you are sure you want to send it to >> the client, then you write the buffer to the actual response. >> > > What about my anonymous wrapper? See reply to original post. > > > _______________________________________________ > 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
