[ http://mc4j.org/jira/browse/STS-276?page=all ]
Tim Fennell resolved STS-276.
-----------------------------
Resolution: Fixed
In looking at this again, I see that you are completely on the mark. I've also
changed it so that if there is no prior action bean on the stack the request
attribute is set back to null.
> ActionBeans are not correctly restorded after processing HTTP includes
> ----------------------------------------------------------------------
>
> Key: STS-276
> URL: http://mc4j.org/jira/browse/STS-276
> Project: Stripes
> Issue Type: Bug
> Components: ActionBean Dispatching
> Affects Versions: Release 1.4
> Reporter: Gary Moselen
> Assigned To: Tim Fennell
> Fix For: Release 1.4.1
>
>
> Gareth works in my team, and I *think* we were using a custom version of
> Stripes 1.3 after I created that original issue and the upgrade to 1.4
> broke for us. *But* I've looked into the 1.4 source and this is what I
> think is happening (in summary the restoreActionBean() behaviour is I
> think broken):
> 1. We hit the first 'foo.action' and DispatchServlet calls
> resolveActionBean(), I didn't follow through the Interceptor code but I
> assumed that the request attribute for the actionBean is set at this point.
> 2. Then the saveActionBean is called, putting [FooBean] as the only
> element on the stack.
> 3. Then jsp:includes are processed, they resolve and put their
> actionBeans on the stack. So assuming we are rendering the last
> jsp:include, after which we will return to the containing page
> a) the last include (bar.action) resolves its ActionBean and saves
> itself to the stack.
> The stack looks like this [[BarBean], [FooBean]] and the
> actionBean request attribute is [BarBean]
> b) the page renders with the correct actionBean bound
> c) the actionBean is restored ( restoreActionBean() ) as the last
> jsp:include is exiting, the stack is popped we get [BarBean] off the
> stack and the stack is [[FooBean]], then the request attribute is set to
> what we popped [BarBean]
> So everything works fine as we descend into the nested includes but the
> behaviour as we exit is not correct, it's restoring the ActionBean that
> has just been used.
> I know we had this going so I don't really know how versions and custom
> builds got mixed up, but all I think that needs to be changed is to
> reverse these two lines in DispatcherServlet:
> // Resolve the ActionBean, and if an interceptor returns a resolution,
> bail now
> Resolution resolution = resolveActionBean(ctx);
> saveActionBean(request);
> becomes:
> saveActionBean(request);
> Resolution resolution = resolveActionBean(ctx);
> so that the actionBean in effect *before* the new actionBean is resolved
> is saved to the stack if any, rather than the just resolved actionBean.
> I just tested this with our pages and it works like this.
> thanks,
> Gary
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://mc4j.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
