[ http://issues.apache.org/struts/browse/WW-785?page=comments#action_37777 ] Don Brown commented on WW-785: ------------------------------
Patrick, are you going to have a chance to resolve this in the next few weeks? If not, I want to move it to Future. > Freemarker JSP Taglibs fails if action has param named "Request" > ---------------------------------------------------------------- > > Key: WW-785 > URL: http://issues.apache.org/struts/browse/WW-785 > Project: Struts 2 > Issue Type: Bug > Components: Views > Affects Versions: WW 2.1.7 > Environment: Windows XP (SP2), Tomcat 5.0.28, Java 1.4.2_07, > Freemarker 2.3.2, WebWork 2.1.7, Spring 1.2rc2 > Reporter: James Storey > Assigned To: Patrick Lightbody > Priority: Minor > Fix For: 2.0.0 > > Attachments: freemarker.jar, freemarker_request_conflict.patch, > webwork_freemarker_request_conflict_changes.tar.gz > > > I was trying to get a Freemarker variant of AppFuse with WebWork running, and > ran into a problem. > If an action (e.g., AppFuse UserAction) has an attribute named Request, this > overrides the 'internal' entry on the stack put there by FreemarkerManager, > which causes the FreeMarkerPageContext to fail, and raise an error that JSP > Taglibs are not supported outside of FreemarkerServlet. > I suspect this would happen in other cases as well, e.g., if using > FreemarkerServlet (native or WW version), with a url > http://host/path?Request=MessUp, though I didn't test this. > Looking through the logic, the problem is that Freemarker uses a not too > unique key of "Request" for the HttpRequestModel. To fix this requires > patches to both Freemarker (which I've submitted - see > http://sourceforge.net/tracker/index.php?func=detail&aid=1202918&group_id=794&atid=100794) > and to WebWork. The approach is the following. In addition to using > "Application" and "Request" as keys, I also store another copy using > ".freemarker.Application" and ".freemarker.Request", in > freemarker.ext.servlet.FreemarkerServlet and in > com.opensymphony.webwork.views.freemarker.FreemarkerManager. Then, in > freemarker.ext.jsp.TaglibFactory (maybe not needed, but done for consistency) > and freemarker.ext.jsp.FreeMarkerPageContext, I use the .freemarker. key > rather than the unqualified key, so that this picks up the correct > HttpRequestHashModel rather than whatever was put in by the application for > "Request". > Also, while I was making changes, I did 2 other things. First, though it > seemed to work okay, the setup code in FreemarkerManager was rather different > than that in freemarker.ext.servlet.FreemarkerServlet. I kept the same > structure as the original FreemarkerManager, but modified this to closely > match what is being done in freemarker.ext.servlet.FreemarkerServlet. I > actually did this first because I thought this was the problem, and then > tracked it down to the non-unique key, but it seemed that this cleanup would > be useful to make sure the Webwork invocation matched what Freemarker does > internally. > Next, I added an entry "param" for the HttpRequestParametersHashModel so that > from the template, you can simply do ${param.name} to get a name parameter > passed in. This is similar to what you'd do in a JSP, and seemed generally > useful. > Note that I did all this aimed at freemarker result type, and did not worry > about the com.opensymphony.webwork.views.freemarker.FreemarkerServlet, as > this is deprecated, and it isn't clear that JSP tag includes ever would have > worked for this. > I'll try to send a patch file for WebWork (based on 2.1.7) and a copy of the > patch file for Freemarker. > James Storey -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
