so you think it is better that we have another implementation of lifecyles for JSF portlets,
(from scratch or using decoratore around current class) which can support both ActionRequest and RenderRequest and map them to different neccessary phases of JSF, one mapping for those who get ActionRequest and another for those which only recieve RenderRequest.
am I correct?
On 10/29/06, Craig McClanahan (JIRA) <dev@myfaces.apache.org> wrote:
[ http://issues.apache.org/jira/browse/MYFACES-1383?page=comments#action_12445431 ]
Craig McClanahan commented on MYFACES-1383:
-------------------------------------------
> Looking at this issue again, it seems to me that it would be better to recreate the FacesContext
> between the execute and render phases of the lifecycle. We would need to preserve messages
> and some other things, but nothing to difficult to preserve. This would allow "wrappers" to update
> their wrapping when the external context changes.
I would recommend that this suggestion be implemented ... not just for consistency with the other bridges, but because the portlet lifecycle is different from a standard webapp lifecycle in one crucial respect. Consider the scenario where you have six portlets on a particular page, all created with MyFaces (yeah :-). On any given request, *one* of the six portlets will go through the Restore View through Invoke Application phases, while *all* six portlets will have the Render Response phase executed. Thus, it is important for portlet developers to understand that they need to be prepared to rerender their current contents at any time, whether or not they were the portlet that received this particular postback. The easiest way to do that is to treat a single portlet request as two JSF requests ... one for the execute part of the lifecycle, and one for the render part.
And that, by the way, is why the Lifecycle API has these two subsets of the overall lifecycle split into two methods.
> FacesContextFactoryImpl issue using trinidad any myfaces core
> -------------------------------------------------------------
>
> Key: MYFACES-1383
> URL: http://issues.apache.org/jira/browse/MYFACES-1383
> Project: MyFaces Core
> Issue Type: Bug
> Components: Portlet_Support
> Affects Versions: 1.1.5-SNAPSHOT
> Environment: pluto 1.1-dev, tomcat 5.5.17 running on linux 2.6.17
> Reporter: nicolas kalkhof
>
> trinidad won´t run in a portlet environment. problem is, that FacesContextFactoryImpl does not extend
> ServletFacesContextImpl. therefore this is an internal myfaces core problem that could hopefully be fixed.
> stacktrace of the crashing portlet using myfaces and trinidad:
> javax.portlet.PortletException:
> org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit
> at
> org.apache.myfaces.portlet.MyFacesGenericPortlet.handleExceptionFromLifecycle(MyFacesGenericPortlet.java:253)
> at
> org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:407)
> ....
> Nested Exception is java.lang.ClassCastException:
> org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit
> at
> org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender (MyFacesGenericPortlet.java:387)
> at
> net.portlets.logon.LogonPortlet.doView(LogonPortlet.java:88)
> ....
--
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
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Arash Rajaeeyan
