That will work with MOST implementations, but not all of them. In
JSR-168, portlet session attributes are prefixed with a standard prefix
and the PORTLET ID (not namespace). In most portals, the PortletId and
the Namespace are the same thing, but this is NOT enforced by the spec
and there is no way to get at the PortletId.
The only real way to do it if you are looking for portability is to use
the in-protocol resource request that will hopefully be in JSR-286 and
access the real PortletRequest object. Until then, if you need to pass
information to a servlet from a portlet, you're best off using your own
scheme (using the namespace) and post it to the Global Scope session
yourself.
In addition, there is no guarentee that the session you used in
accessing the portal will be available when you run the Servlet.
Certainly in the case of Pluto, this is generally correct, but any
portal server which uses WSRP to connect to the portlet, this will NOT
be the case. Instead, the portlet's web application will exist on an
entirely different server and when the browser connects to that server
directly (rather then through the portal server) and the browser and
servlet engine will actually assign a brand new session. There are ways
of handling this, but there are no standard ways just yet.
Scott
Jörn Zaefferer wrote:
It is possible to access a portlet session from a servlet in the same
webapp. You need to pass the portlet namespace in the request to the
servlet, and use that namespace to find the portlet session in the
"global" session, which is nothing more then the normal http session.
The JSR 168 spec defines the pattern to "hide" portlet sessions, I
don't have the exact format at hand, but its not difficult to figure
that out.
There is still another, bigger step involved to restore the faces
context with that information, but at least its possible to access
your managed beans with session scope, which may solve your problem.
