Last notes on the night. I have been trying many different configurations and debugging more. I eventually got the client state to save correctly and the view to restore correctly by using:
<context-param> <param-name>org.apache.myfaces.trinidad.CLIENT_STATE_METHOD</param-name> <param-value>all</param-value> </context-param> <context-param> <param-name>org.apache.myfaces.trinidad.CACHE_VIEW_ROOT</param-name> <param-value>false</param-value> </context-param> The problem is that facelets then kept re-building the view between the execution of my action and the rendering of the view, which is very odd since my action and outcome were null. So I tried the following parameter, as that is where the facelets code was switching on its value to rebuild the view: <context-param> <param-name>facelets.BUILD_BEFORE_RESTORE</param-name> <param-value>true</param-value> </context-param> Once I did that I keep getting this exception: 22:53:59,902 ERROR [DebugPageHandler] redirecting to debug page java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to java.lang.String at org.apache.myfaces.trinidad.bean.util.StateUtils.restoreKey(StateUtils.java:73) at org.apache.myfaces.trinidad.bean.util.StateUtils.restoreState(StateUtils.java:142) at org.apache.myfaces.trinidad.bean.util.FlaggedPropertyMap.restoreState(FlaggedPropertyMap.java:194) at org.apache.myfaces.trinidad.bean.FacesBeanImpl.restoreState(FacesBeanImpl.java:327) at org.apache.myfaces.trinidad.component.UIXComponentBase.restoreState(UIXComponentBase.java:860) at org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:838) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:722) at org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96) at org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:832) at org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96) at org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:832) at org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96) at org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:832) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:722) at org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:550) at com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:345) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:266) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:81) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70) There seems to be some power struggle between facelets 1.1.11 and Trinidad 1.0.3, but I haven't yet been able to figure out what is going on that is causing all the issues. I have to give up for tonight. Hopefully the morning will shed some light, but I think at this point I need help from the Trinidad and Facelets team. On 9/5/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > Okay, I could really use some help, and I am confused on the Trinidad > code and how it is supposed to work. > > I stepped through the code on a PPR partial submit restore view. And > the code that starts to seem fishy is the > "StateManagerImpl$PageState.popRoot(FacesContext)" function. > > Code as follows: > UIViewRoot newRoot = (UIViewRoot) > fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE); > > // must call restoreState so that we setup attributes, listeners, > // uniqueIds, etc ... > newRoot.restoreState(fc, viewRootState); > > // we need to use a temp list because as a side effect of > // adding a child to a UIComponent, that child is removed from > // the parent UIComponent. So the following will break: > // newRoot.getChildren().addAll(root.getChildren()); > // because "root"'s child List is being mutated as the List > // is traversed. > List<UIComponent> temp = new > ArrayList<UIComponent>(root.getChildCount()); > temp.addAll(root.getChildren()); > newRoot.getChildren().addAll(temp); > return newRoot; > > As you can see, the state of the new UIViewRoot is restored, then the > children are added to the view root before this function returns, but > neither the restoreState nor the processRestoreState functions are > ever called on the children. > > As a result the view is never restored fully. That is where I am > getting the problem. > > My configuration: > > Facelets 1.1.11 > Trinidad 1.0.3-SNAPSHOT > Seam 1.2.1 > MyFaces 1.1.5 > > View root: the one Trinidad installs > ALTERNATE_VIEW_HANDLER: my own custom view handler that extends > SeamFaceletViewHandler which in tern extends FaceletViewHandler. > > State saving method is client. > > Using *.jsf view mapping with .xhtml file suffixes. > > Trinidad's USE_APPLICATION_VIEW_CACHE parameter set to false. > > setting the facelets BUILD_BEFORE_RESTORE parameter to true actually > "fixes" the error, but that is simply because the simple view I am in > really has no "real" state to store. But even with this set, the > children of UIViewRoot never have their state restored. > > My custom view handler creates my on view root that extends > UIViewRoot, but I don't touch any of the state methods. > > Looking in the client HTML, it gets a bit fishy as well. This is what I found: > > <span id="_mainForm_Postscript"> > <input type="hidden" value="!-1f9a06ef" > name="org.apache.myfaces.trinidad.faces.STATE"/> > > That value seems incredible small for a view state. > > I have tried server side state saving and have gotten the same result. > The code that seems very wrong in terms of it shouldn't be executed > ins in StateManagerImpl.java: > > UIViewRoot root = viewState.popRoot(context); // bug 4712492 > if (root != null) > { > _LOG.finer("UIViewRoot for token {0} already exists. Bypassing > restoreState", token); > return root; > } > > This always is true on my PPR requests and seems to be the cause of > the state never being restored. > > While in debug mode, if I force the root to be null, then everything > works. I really don't know for sure, but the above code seems to > completely break the restoring of the view state with the > configuration I have. > > On 9/5/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > > TreeState.saveState(FacesContext, UIXComponentBase) is being called, but > > > > TreeState.restoreState(FacesContext, UIXComponentBase) is never called. > > > > I'll have to look into this to see if it is something I caused or not. > > Does Trinidad depend on a custom UIViewRoot implementation (I have my > > own and a custom view handler that are worth looking into as the > > source of the issue)? > > > > On 9/5/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > > > It works fine outside of the facet, > > > > > > Broken: > > > > > > <tr:panelLabelAndMessage > > > label="Test help"> > > > <tr:inputText id="testHelp" value="#{testHelpText}" > > > simple="true" /> > > > <f:facet name="end"> > > > <cw:helpIcon for="testHelp" > > > messageId="test_help" /> > > > </f:facet> > > > </tr:panelLabelAndMessage> > > > > > > Works: > > > > > > <tr:panelLabelAndMessage > > > label="Test help"> > > > <tr:inputText id="testHelp" value="#{testHelpText}" > > > simple="true" /> > > > </tr:panelLabelAndMessage> > > > <cw:helpIcon for="testHelp" > > > messageId="test_help" /> > > > > > > Looks like a possible bug in the state saving of facets or at least in > > > the panelLabelAndMessage. Any ideas? > > > > > >