[
https://issues.apache.org/struts/browse/WW-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Husted resolved WW-785.
---------------------------
Resolution: Fixed
Fix Version/s: (was: 2.1.1)
2.1.0
I'm resolving this as fixed become moving to FreeMarker 2.3 was suppose to
address the issue, and because the requester didn't respond to the request for
an updated patch, if one is still needed.
> 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.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.
-
You can reply to this email to add a comment to the issue online.
