tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Fennell <newsgro...@tfenne.com>
Subject Re: Includes that Forward
Date Fri, 07 Jul 2006 13:40:12 GMT
I guess I look at it the other way around.  I want to be able to design 
things that don't have to know whether they are being included or not.  
The real case that I'm dealing with here is that I have the equivelant 
of a Struts action.  In some cases the Action will be accessed directly 
by a user hitting the associated URL.  In other cases, it'll be 
included into a JSP essentially as a component for the page.  The 
action does some pre-processing and then forwards to a JSP.  This is 
pretty normal behaviour - you wouldn't usually hav an action *include* 
a JSP would you?

On resin this works like a charm.  On Tomcat, when including said 
Action the result is a huge stack trace because after the included 
action has forwarded to it's view and rendered, the outer action/view 
tries to complete rendering into an output stream that has been closed 
:(

So the only solution as it stands is to start coding up stuff that 
checks "am I being accessed as a REQUEST or am I being accessed as an 
INCLUDE" and then modifying execution to produce the *same* behaviour.  
This strikes me as breaking encapsulation quite a bit, and I don't like 
it.

-t

On 2006-07-07 09:03:42 -0400, David Smith <dns4@cornell.edu> said:

> Personally, I think it's bad design to have an include do a forward and 
> then expect the forward content to replace the include.  A forward, 
> even from an include, should replace the entire content of the would be 
> response.
> The behavior you are looking for could be done easily (and more 
> cleanly) with a little jsp logic that essentially chooses to render or 
> perform a third tier include.
> 
> This is purely my opinion though.  I'll take the way Tomcat handles the 
> case over the way Resin and Jetty handle it.
> 
> --David
> 
> Tim Fennell wrote:
> 
>> Hi,
>> 
>> I'm wondering what the expected behaviour is when a JSP that is 
>> included from another JSP then forwards to a third JSP?  As an example:
>>    - start.jsp
>>        - some content on start.jsp
>>        - _include_ included.jsp
>>            - some content on included.jsp
>>            - _forward_ to forwarded.jsp
>>                - content on forwarded.jsp
>>            - some content (on included.jsp) after the forward
>>        - some content on start.jsp after the include
>> 
>> Does the above example make sense?  I was able to dig up this bug 
>> (which was closed INVALID) for Tomcat 4:
>>     http://issues.apache.org/bugzilla/show_bug.cgi?id=12578
>> 
>> I'm using Tomcat 5.5.17 and what happens is that *only* the content on 
>> the inner-most forwarded page is output to the response.  Actually - in 
>> my case it's some code deep down in the framework causing exceptions to 
>> be thrown, but I believe it's the same problem as exhibited by the test 
>> case I've put together using three JSPs.
>> 
>> Now, granted, the spec does say that on Forward the response buffer 
>> should be cleared, and after the forward it should be closed.  So it's 
>> arguable that Tomcat is doing the right thing.  However, I'll point out 
>> that Resin and Jetty 6 both do different things here - so clearly how a 
>> Forward is handled *inside* of an Include is open to a lot of 
>> interpretation.  I think the problem is that the specification doesn't 
>> really address the case of a Forward happening nested inside an Include 
>> :/
>> 
>> Personally I feel like the only sensible option (from a user's 
>> perspective) is to treat each include in the manner of a nested 
>> transaction.  So in the example above, I would expect the content from 
>> the outer (start.jsp) page to be rendered, along with the content from 
>> the inner most (forwarded.jsp), but that the content from included.jsp 
>> would be omitted in keeping with how the servlet specification defines 
>> the semantics of a Forward.
>> 
>> Are you guys open to discussing how this is handled in Tomcat?  Btw. if 
>> this is a dicussion more appropriate for the dev list, just let me know 
>> and I'll post there instead.
>> 
>> -Tim Fennell
>> http://stripes.mc4j.org/
>> Stripes: Because web development should just be easier
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org


-- 
-Tim Fennell
http://stripes.mc4j.org/
Stripes: Because web development should just be easier



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message