[ http://mc4j.org/jira/browse/STS-276?page=comments#action_10472 ] Gary Moselen commented on STS-276: ----------------------------------
This fix is working fine for us now, thanks. > 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
