This question also came up internally, and a colleague referenced the
portlet spec:
14.1.2.5 Action-scoped Request Attributes
The Java Portlet
Specification follows a model of separating concerns into different
request processing phases, such as the action phase, the event
phase, and the render phase. This provides a clean separation of the
action semantics from the rendering of the content, however, it may
create some issues with servlet-based applications that don’t follow
this strict Model View-Controller pattern. Such applications in some
cases assume that attributes that they set in the action phase will
be accessible again when starting the rendering. The Java Portlet
Specification provides the render parameters for such use cases, but
some applications need to transport complex objects instead of
strings. For such use cases the Java Portlet Specification provides
the action-scoped request attributes as container runtime option
with the intent to provide portlets with these request attributes
until a new action occurs. Section 8.4.4 Runtime Option
javax.portlet actionScopedRequestAttributes on page 51 describes
this option in more detail.
And 8.4.4 contains this info:
Portlets that want to leverage the action-scoped request attributes
must to set the container runtime
option
javax.portlet.actionScopedRequestAttributes to true, default is
false. In addition, the portlet may provide a value called
numberOfCachedScopes where the
following value element must be a
positive number indicating the number of scopes the portlets
wants to have cached by the portlet container. This value is a hint
to the portlet container that
the portlet container may not be
able to honor because of resource constraints. The order of the
values in the portlet deployment descriptor must be true,
numberOfCachedScopes, <number
of cached scopes>
...and it seems that another (more brute force) workaround goes
through the original HttpServletRequest.
