[ http://issues.apache.org/jira/browse/MYFACES-1383?page=comments#action_12439903 ] Scott O'Bryan commented on MYFACES-1383: ----------------------------------------
Sorry it's taken so long for me to fix this issue. I'm hammered with Trinidad issues at the moment. I looked at this issue and am posting some possible solutions to the myfaces-dev list. Here is the technical ins and outs of the issue. The Faces' Lifecycle object is split into two faces: execute and render. During the execute phase, the faces application executes all phases of the lifecycle up to but not including the "Render Response" phase. When running from a portlet, this happens in the processAction method of the BridgePortlet which creates an ExternalContext with the Portal's ActionRequest/Response object. Once the processAction method is complete, the Portal then executes the portlet's "render" method. During this phase, the Portal must change the ExternalContext to contain the Portal's RenderRequest/Response. The issue here is that the Trinidad FacesContextFactory wraps the MyFaces FacesContextFactory class. Inside of this Factory, Trinidad retrieves the MyFaces' FacesContext object and wraps it in it's own object. This is essentially issue one. The MyFaces Bridge portlet assumes that the current FacesContext object is the one provided by MyFaces which exposes functionality to change the ExternalContext. This is not the case because what is returned is the Trinidad FacesContext which does not have this functionality. Normally, we could simply "wrap" the Trinidad FacesContect object in our own and change the ExternalContext. The problem is that Trinidad's FacesContext wraps the ExternalContext as well, allowing functionality for a special resource resolver on the dispatch method. Simply changing the external context to an "unwrapped" version is not sufficient. There are a number of approaches we can take to this issue and I'm going to ping the Dev list for MyFaces to see if people have a preference. None of the changes should be particularly complex, but with the way Faces is designed, it is bad that our Faces Bridge portlet assumes these objects are not wrapped. > 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
