struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Brown (JIRA)" <>
Subject [jira] Updated: (WW-785) Freemarker JSP Taglibs fails if action has param named "Request"
Date Sat, 06 Jan 2007 22:08:17 GMT


Don Brown updated WW-785:

    Fix Version/s:     (was: 2.0.3)

> Freemarker JSP Taglibs fails if action has param named "Request"
> ----------------------------------------------------------------
>                 Key: WW-785
>                 URL:
>             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.x
>         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
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 ${} 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:
For more information on JIRA, see:


View raw message