Request Scope for portlets? Sharing data tutorial does not work for portlet

Question

I created 2 identical applications, one that was a regular JSF web app, and one a JSR168 portlet. By following the "Sharing Data Between Two Pages" tutorial, I can get this technique to work without a problem in the web app, but the portlet (deployed locally using the pluto server) does not work. What is the difference between a regular app and a portlet app?
This shows that portlets apparently handle scope much differently than other applications, so any information relating to this would be helpful to pass along.

Answer 1

Portlet Life Cycle Differences
A portlet page is the same as a web application page in the Creator 2 application
model with differences only in the page life cycle. To best understand the life
cycle differences, you must first understand how a portal interacts with a portlet.
This interaction between portals and portlets is defined by the JSR-168 Portlet
specification. Typically a portal display in the web browser shows multiple
portlets. That is, when the portal page is displayed, there are actually multiple
portlets displaying or rendering their content. The job of the portal is to manage
how these portlets are displayed. Internally, the portal is responsible for telling
each portlet two things:
1. When to display itself
2. If there has been an action, such as a button press, performed inside that
portlet.
When a portal wants portlets to display their contents, the portal sends a render
request to each portlet showing in the portal. If one of the portlets showing in the
portal has a button tied to an action request, when that button is pushed, the
portal fires an action request for that portlet. In addition, the portal generates a
render request for the portlet and all other portlets on the page. You should note
that the portal implementation fires both action and render requests for each
action method on a portlet showing in the portal. The implication of this
interaction means the portlet page being rendered can not make assumptions
about the state of the values to be shown. Unlike a normal web application page,
a portlet page can't assume that the page being rendered in the Render Response
phase is the same page that was built in Restore View. If a portlet wants to
maintain state across repeated render requests, the portlet must use the session
bean to store stateful information.
The main point to remember is a portlet page must always be prepared to render
it's values from scratch or session data. This implies you should never bind
portlet page UI components to page bean properties or request bean properties.
Also, you should never rely on page bean instance variables that might be set
during an action event.
Hope this helps.