[ http://issues.apache.org/jira/browse/MYFACES-549?page=comments#action_12330980 ]
Tanju Erinmez commented on MYFACES-549: --------------------------------------- Hi folks, I haven't checked out zeroconfs demo but I have experienced a similar problem with liferay 3.6.1 ent and my demo app (which is attached in http://issues.apache.org/jira/browse/MYFACES-650). Once you have overcome this problem the next one is around at http://issues.apache.org/jira/browse/MYFACES-650). I think this particular problem occurs when client state saving is used. Server state mode works for me. The problem seems to be a liferay issue. I have noticed during debugging that the attribute map is not properly isolated from one RenderRequest to another. What basically happens, is that a serialized view is created and stored in the attribute map for subsequent processing in the very same RenderRequest of the first portlet. Now when the second portlet's RenderRequest is issued it finds an already serialized view in the attribute map and uses this one instead of creating its own. Consequently, the second portlet renders and writes out the state tree of the first portlet (you can see this if you compare the hidden field contents of the jsf_state_trees). Now, if you issue an action in the second portlet the restore view phase sees a mismatch between its current view and what the state tree represents. It just gives up and goes straight to the render phase (which again writes out the wrong serialized view). So basically, after startup you are set up on a wrong track and you gonna stay there for a long time without parole :-) A quick and dirty resolution would be simply to manually remove this serialized attribute whenever a lifecycle.render has been concluded. Specifically, you need to create a custom portlet class, override facesRender() and copy the entire method content over from MyFacesGenericPortlet. And then add the following request.removeAttribute(JspStateManagerImpl.class.getName() + ".SERIALIZED_VIEW"); // this is not related to the problem but it doesn't hurt to clean it up as well request.removeAttribute("org.apache.myfaces.renderkit.html.util.JavascriptUtils.OLD_VIEW_ID"); after nonFacesRequest(request, response); and lifecycle.render(facesContext); To recap this is not a myfaces problem and I don't have a proper setup right now handy with a virgin MyFacesGenericPortlet to create a patch. But if this topic is still burning interest I'll be glad to create one and submit it to this thread. Cheers, Tanju > faces navigation rules not working for two portlets on portal page > ------------------------------------------------------------------ > > Key: MYFACES-549 > URL: http://issues.apache.org/jira/browse/MYFACES-549 > Project: MyFaces > Type: Bug > Components: General > Versions: 1.1.1 > Environment: Linux 2.6.12, Java 1.5.0_04, Liferay Pro 3.6.1 (portla), > nightly build (20050909) > Reporter: zeroconf > Priority: Minor > Attachments: cardemo.war.zip > > I'm trying to write some JSF portlets within one portlet application > but encountered some problems concerning navigation rules when I > put more than one JSF portlet per portal page. > When I put just one portlet on my page everything concerning the > navigation rules (with <h:commandButton action="p1next" value="go on" > /> stuff) works fine and I get to the next view. > But when I put a second faces portlet on the page navigation and invoking > actions on backing beans in the second portlet just doesn't work at all. > If I remove both portlets and put the second portlet on the page again (so > that > I'm having just one portlet again) this portlet works fine as well. So I > assume > that navigation settings in faces-config.xml must be correct. It has > something to do > with the arrangement of two faces portlets on the portal page so that > the second one > stops working as expected. > I also tried to use distinct IDs for all ui-components and also > distinct <from-output>-values but that doesn't help > Thanks > zeroconf > Attached are the important parts of my web.xml, faces-config.xml and > portlet.xml > web.xml > ============================ > <?xml version="1.0"?> > <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web > Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd";> > <web-app> > <display-name>PROJECT_NAME</display-name> > <context-param> > <param-name>company_id</param-name> > <param-value>liferay.com</param-value> > </context-param> > <context-param> > <param-name>javax.faces.STATE_SAVING_METHOD</param-name> > <param-value>client</param-value> > </context-param> > <context-param> > <param-name>javax.faces.application.CONFIG_FILES</param-name> > <param-value>/WEB-INF/faces-config.xml</param-value> > </context-param> > <listener> > <listener-class>com.liferay.portal.servlet.PortletContextListener</listener-class> > </listener> > <listener> > <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class> > </listener> > <servlet> > <servlet-name>PROJECT_NAME</servlet-name> > <servlet-class>com.liferay.portal.servlet.PortletServlet</servlet-class> > <init-param> > <param-name>portlet-class</param-name> > <param-value>org.apache.myfaces.portlet.MyFacesGenericPortlet</param-value> > </init-param> > <load-on-startup>0</load-on-startup> > </servlet> > <servlet> > <servlet-name>FacesServlet</servlet-name> > <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> > <load-on-startup>1</load-on-startup> > </servlet> > <servlet-mapping> > <servlet-name>PROJECT_NAME</servlet-name> > <url-pattern>/PROJECT_NAME/*</url-pattern> > </servlet-mapping> > <taglib> > <taglib-uri>http://java.sun.com/portlet</taglib-uri> > <taglib-location>/WEB-INF/tld/liferay-portlet.tld</taglib-location> > </taglib> > </web-app> > faces-config.xml: > ================== > <?xml version="1.0"?> > <!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD > JavaServer Faces Config 1.1//EN" > "http://java.sun.com/dtd/web-facesconfig_1_1.dtd";> > <faces-config xmlns="http://java.sun.com/JSF/Configuration";> > <factory> > <faces-context-factory>org.apache.myfaces.context.MyFacesContextFactoryImpl</faces-context-factory> > </factory> > <!-- navigation for JSF portlet 1 --> > <navigation-rule> > <from-view-id>/jsp/jsf1/index.jsp</from-view-id> > <navigation-case> > <from-outcome>p1next</from-outcome> > <to-view-id>/jsp/jsf1/n1.jsp</to-view-id> > </navigation-case> > </navigation-rule> > <navigation-rule> > <from-view-id>/jsp/jsf1/n1.jsp</from-view-id> > <navigation-case> > <from-outcome>p1back</from-outcome> > <to-view-id>/jsp/jsf1/index.jsp</to-view-id> > </navigation-case> > </navigation-rule> > <!-- navigation for JSF portlet 2 --> > <navigation-rule> > <from-view-id>/jsp/jsf2/index.jsp</from-view-id> > <navigation-case> > <from-outcome>p2next</from-outcome> > <to-view-id>/jsp/jsf2/n1.jsp</to-view-id> > </navigation-case> > </navigation-rule> > <navigation-rule> > <from-view-id>/jsp/jsf2/n1.jsp</from-view-id> > <navigation-case> > <from-outcome>p2back</from-outcome> > <to-view-id>/jsp/jsf2/index.jsp</to-view-id> > </navigation-case> > </navigation-rule> > </faces-config> > portlet.xml > ============================= > <portlet> > <portlet-name>jsf2</portlet-name> > <display-name>jsf2</display-name> > <portlet-class>org.apache.myfaces.portlet.MyFacesGenericPortlet</portlet-class> > <init-param> > <name>default-view</name> > <value>/jsp/jsf2/index.jsp</value> > </init-param> > <supports> > <mime-type>text/html</mime-type> > </supports> > <portlet-info> > <title>jsf2</title> > <short-title>jsf2</short-title> > <keywords>jsf2</keywords> > </portlet-info> > </portlet> -- 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
