[jira] Updated: (WW-785) Freemarker JSP Taglibs fails if action has param named "Request"

["Don Brown (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/struts/browse/WW-785?page=all ]

Don Brown updated WW-785:
-------------------------

    Fix Version/s: 2.0.3
                       (was: 2.0.2)

> 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.3
>
>         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