struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nils-Helge Garli" <>
Subject Re: [s2] portlet code not using valuestack for looking up request attributes
Date Sat, 11 Aug 2007 05:59:07 GMT
Hm...this might be a tricky one. The portlet spec says nothing about
request wrappers, and trying to wrap the portlet requests might result
in undetermined behaviour. I tried onece, with pluto, but pluto relies
on it's internal implementation classes, so you'll get a
classcastexception if it encounters a wrapped portlet request that is
not it's own... To make it work, we would have to create separate
wrapper strategies for (possibly) each portlet container. Most portal
servers are using pluto, but it still might be some work, and not to
mention a big task maintaining it, as new version of the containers
are released.

What attribute lookups are failing? Couldn't they be placed as a
"real" request attribute to make it work?


On 8/11/07, James Holmes <> wrote:
> I'm moving a Struts 2 app from a standard Web app to being a portlet. During the process,
my Displaytag instances started failing. They weren't finding any data. I
> tracked down the problem to the fact that Displaytag looks for the list of data it displays
in request scope. This worked fine when run as a standard Web app because
> StrutsRequestWrapper.getAttribute() looks up objects on the Struts 2 valuestack. Portlet
requests are not wrapped with StrutsRequestWrapper, thus the getAttribute()
> method never gets called and objects on the Struts 2 valuestack are not interrogated.
> For consistency (and just because it's incredibly useful functionality), the Struts 2
portlet code should also look up request objects on the valuestack. I'm not sure if
> the portlet mock servlet code that Nils-H checked in to the trunk yesterday fixes this
issue. If not, I can open a JIRA ticket to address this.
> I wanted to check with everyone, most specifically Nils-H, about this before I opened
a JIRA ticket.
> Thoughts?
> James
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message