You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "Nick Lothian (JIRA)" <pl...@jakarta.apache.org> on 2004/10/29 01:27:42 UTC

[jira] Commented: (PLUTO-80) request attributes cannot be shared between actionRequest and renderRequest

     [ http://issues.apache.org/jira/browse/PLUTO-80?page=comments#action_54774 ]
     
Nick Lothian commented on PLUTO-80:
-----------------------------------

This is as required by the specification - see http://nagoya.apache.org/eyebrowse/ReadMsg?listName=pluto-dev@jakarta.apache.org&msgNo=1529

I'd suggest sending comment to the JSR-168 comment list or the Pluto-Dev mailing list.

Closing this as it is not a Pluto bug

> request attributes cannot be shared between actionRequest and renderRequest
> ---------------------------------------------------------------------------
>
>          Key: PLUTO-80
>          URL: http://issues.apache.org/jira/browse/PLUTO-80
>      Project: Pluto
>         Type: Bug
>   Components: portlet container
>     Versions: Current CVS
>  Environment: Windows 2000 / Tomcat 4.1.30 / JDK 1.3.1_02-b02
>     Reporter: Bogdan Onoiu

>
> The specs say:
> "Request attributes are objects associated with a portlet during a single portlet request.
> Request attributes may be set by the portlet or the portlet container to express information that otherwise could not be expressed via the API. Request attributes can be used to share information with a servlet or JSP being included via the PortletRequestDispatcher."
> Does this mean that we cannot share objects between action and render via set/getAttribute methods?
> To reproduce the issue I describe check that in the testsuite the TestPortlet class sets: 
> request.setAttribute("portletaction","action1") in the end of the processAction(). If you try to get the value of "portletaction" attribute in the following render() method you get null.
> This is due to the fact that the pluto container is always issuing a client side redirect after finishing the processAction() therefor the original request response objects are lost and new ones are created for render() processing.
> in PortletContainerImpl
> try{
> redirect(location, portletWindow, servletRequest, servletResponse, _actionResponse);
> }
> finally{
> PortletInvokerAccess.releasePortletInvoker(invoker);                            
> PortletContainerServices.release();
> }
> generates a status 302 in the end.
> Can you specify if this is an implementation issue? If the object sharing is not ensured by the specs the whole design of a portlet application gets very complicated only to address this minor problem. The whole point of having the "processAction" specialization becomes cumbersome to be used when it could actually be straight forward.
> Ideally the specs would have allowed setting attibutes to request object in the same way as to the session object, eg: allowing portlet scope and application scope.
> Cheers,
> Bogdan

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira