1. The o.a.j.container.ContainerValve receives the request.
2. The request is then inspected by the o.a.j.engine.core.PortalControlParameter.getPortletWindowOfAction() to see whether or not a portlet action has been requested.
3. If an action has been found the o.a.j.request.RequestContext.setActionWindow() is passed that action window, if not it is passed null.
4. Next the ActionValve checks to see if the there is an action window defined, if the there is there, the PortletContainer.processPortletAction() is called by passing in the action window and HttpServletRequest aand httpServletResponse objects.   The request and response objects are actually wrappers around the original request and response objects which can parse action and/or render parameters for a specific PortletWindow. These wrappers are generated by calling RequestContext.getRequestForWindow() and RequestContext.getResponseForWindow() respectively.
5. The container now handles the request. The container is responsible to generating an ActionRequest and an ActionResponse for the portlet action to be invoked.  Next the creates a new PortletInvoker object by passsing the PortletDefinition which was extract from the PortletWindow via the PortletEntity.   In Jetspeed's case, the PortletInvoker will be an instance of o.a.j.container.invoker.ServletPortletInvoker.  The  PortletInvoker.action() method is called passing in the previously generated ActionRequest and ActionResponse.
6. ServletPortletInvoker receives the ActionRequest and ActionResponse from the container.  From here the ServletPortletInvoker extracts the ServletRequest and ServletResponse from the ActionRequest and ActionResponse respectively.  
7. The PortletDefintion (which was provided at creation time to the ServletPortletInvoker) is queried for the WebApplication object which has the context path of the web app that controls this portlet.  
8. With the name of the webapp ServletPortletInvoker no dispatches the request to the actual web application represented by the context path.  NOTE:  All portlet applications must contain a definition in its web.xml for the o.a.j.container.JetspeedContainerPortlet.  However, Jetspeed's deployment tool will generally take care of this for you.
9. Once the JetspeedContainerServlet receives the request, it invokes Portlet.processAction(ActionRequest, ActionResponse) on your portlet.
10. After the PortletInvoker and the JetspeedContainerServlet are finished the container once again takes control.  The container gets the redirection location from the response using ActionResponse.getRedirectLocation().  The ActionResponse is now checked to see if the state or the mode of the portlet has changed and communicates this information PortletWindow we are invoking the action on.  These changes are also applied to the rediretion location and passed to the current ServletResponse.sendRedirect() method so that all the encoded portlet state information is preserved in the URL>

 

bottom