JSF webapps follow the JSF lifecycle (decode, validate, update, apply actions
and render phases). In these webapps, the same request is used for all the
phases. So, any request scoped information will be available for all the phases.
However, when this webapp is run as a portlet-app using the jsf-portlet bridge
in Portal environment, the portlet container dispatches two requests.
first for - decode, validate, update, apply actions phase
second - render phase
As a result, any request scoped information (objects, backing beans etc) that is
used in the decode, validate, update, apply actions phase is not available in
the render phase (because this is a new request)
A simple example would be 'alerts'
- User clicks on a button (associated with a action handler)on the UI
- Form is submitted, goes through the decode, validate, update phases of JSF
- Action handler is invoked in the 'apply actions' phase
- The handler performs action and sets a message/alert to be displayed
- This alert could be say, obtained via a value-binding of a backing bean
(request scope, already created in the above phases)
- Now, in the 'render phase', a new request is used by the portlet container and
so new backing bean obj. is created thus losing all the information set previously.
- The page does not display any alerts/messages
One of the main intentions of jsf-portlet bridge is to easily convert JSF
webapps to portlets. This is a big hinderance in that direction.