Hi Scott, Thanks for the detailed answer/explanation. They were really helpful to verify my understanding and also enriching the same.
My consolidated response to your last 2 mails are embedded below. Regards, Sourav -----Original Message----- From: Scott O'Bryan [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2008 12:27 PM To: MyFaces Discussion Subject: Re: Myfaces Portlet does not work when a bean is stored in Requestscope ... Souravm, Just a clairification, the request bean you have, is it not getting preserved between a single Action->Render or is it just not getting preserved in subsequent renders? <Sourav> It does not get preserved in single Action->Render. I'm not sure - Whether this should be responsibility of the Portal server to preserve the bean within the same request scope when the bean is declared to be of request scope. - Or it is responsibility of the bridge If it is the responsibility of the bridge, then my take is the root cause of this problem again goes back the issue#1 (replicating parameters/attributes from ActionRequest to RenderRequest). The entire JSF lifecycle execution (except render) happens within processAction() method which runs with the ActionRequest. So the bean creation, execution of bean's methods (which in turn populate the result to be displayed in the resultant response page created in render phase) also happen within this scope. So if the bean in its latest state needs to be stored and used in the render phase the bean has to be stored either in session (which works fine in case of session scoped bean) or it has to be explicitly set in RenderRequest. </Sourav> The first issue, in bridges before JSR-301 is actually a portal issue. The JSR specification does not say whether request attributes set in the action request have to be available in the render request. IMO, if they are not, request attributes are basically pointless. Pre-JSR 301 bridges were ignorant of this fact and just did what the portal did. The JSR-301 bridge DOES define this behavior and I believe he have special code to handle these issues. This code is NOT in the MyFaces 1.1 bridge. <Sourav> I see your point. However, going back to the comment you made in last mail (whether this is a valid usecase or not, or should this scenario has to be handled through Render URL), I don't think using a RenderURL is a right solution. This is because following reasons - a) RenderURLs are to be directly called only when there is no processing needs to be done for a Portlet, only the previous view has to be rendered. In my understanding, this is to be used especially for the pages with multiple portlets. This ensures that in case one Portlet sends an ActionRequest, all other portlets in the same page does not need to go through the action processing for the previous request (instead they can just repeat the render phase of Portlet Lifecycle with the result from previous action). b) Secondly, not sure how valid is the assumption that the first request to a Portlet will always be Render Request. Even during first time bringing up the portlet in a page there may be need of doing some processing based on the Portlet Preference which ideally should be handled in processAction() phase of Portlet lifecycle. So ideally this assumption should be relooked at. I surely feel this usecase should be supported (standard struts-portlet bridges support it). I'll really appreciate if you can discuss this in next JSR 301 meeting. </Sourav> As for the second issue, this is also something that is now handled by JSR-301, but the original attempt at JSF to define a bridge did NOT make this a requirement. In order to maintain compatibility with existing applications, the 301 bridge will preserve request attributes on subsequent "non-direct" render requests, but we also had to add a way to disable this functionality for beans that did not expect to be preserved. <Sourav> I've not really tested preserving the request for subsequent non-direct render request. As I mentioned above, I found problem even in storing the same bean within the single Action->Render sequence. However, my view is, if request parameters (in a managed bean) needs to be stored for subsequent render requests, it crosses the boundary of a single http request. Then the managed bean has to be scoped at session level. </Sourav> For issue #1, I think it would probably be appropriate to add some code to fix this. What it would entail is storing the RequestMap in a global map with a key that you would set as a render parameter. You'll need to be careful to clean up anything that might "leak". <Sourav> I agree with you on this. I'm planning to create this map in actionProcess() method in case the VIEW_ID request parameter is null (the VIEW_ID null is the flag to identify that it is a non-JSF action request). </Sourav> For issue #2, existing portlet applications in the 1.1 space DEPEND on this behavior. Changing it would break those applications. We chose to break it for JSR-301 because we though it more appropriate to preserve these parameters, but we added several mechanisms (one annotation based and one FacesConfig based) to allow these attributes to be easily excluded. <Sourav> I see your point. Hope JSR 301 and JSR 286 together can bring more predictable and intuitive behavior for Portal-JSF combination. </Sourav> Hope that helps, Scott souravm wrote: > Hi All, > > I have a simple JSF application exposed as Portlet (in JBoss Portal Server > 2.6.4) using MyFacesGenericPortlet. The JSF application has a managed bean > with Request scope. > > The application works perfectly when it is run outside Portal environment. > > But within Portal environment it does not work as the Manages Bean, though > gets initiated and do all the processing properly during the initial > lifecycle phases, during the render phase it further gets initiated and the > previous instance gets lost. > > The same works perfectly fine in Portal environment when the Managed Bean is > declared in session scope. > > Not sure whether this is the problem of MyFacesGenericPortlet or the Portal > Server where it is running. Or is it by design ? > > Any insight/viewpoint on this would be highly appreciated. > > Regards, > Sourav > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, > please notify the sender by e-mail and delete the original message. Further, > you are not to copy, disclose, or distribute this e-mail or its contents to > any other person and any such actions are unlawful. This e-mail may contain > viruses. Infosys has taken every reasonable precaution to minimize this risk, > but is not liable for any damage you may sustain as a result of any virus in > this e-mail. You should carry out your own virus checks before opening the > e-mail or attachment. Infosys reserves the right to monitor and review the > content of all messages sent to or from this e-mail address. Messages sent to > or from this e-mail address may be stored on the Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** >
