[
https://issues.apache.org/struts/browse/WW-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Husted reassigned WW-785:
-----------------------------
Assignee: Ted Husted (was: Patrick Lightbody)
> Freemarker JSP Taglibs fails if action has param named "Request"
> ----------------------------------------------------------------
>
> Key: WW-785
> URL: https://issues.apache.org/struts/browse/WW-785
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - Tags
> 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
> Assignee: Ted Husted
> Priority: Minor
> Fix For: 2.1.1
>
> 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.
-
You can reply to this email to add a comment to the issue online.
