On 9/5/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > 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>
This is not likely relevant. > <context-param> > <param-name>org.apache.myfaces.trinidad.CACHE_VIEW_ROOT</param-name> > <param-value>false</param-value> > </context-param> This second one is likely the relevant one. This disables an optimization that gives Facelets some problems, though generally only when transient components are in the page - specifically, Facelets template text. > 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. Indeed odd, and suggestive of something else going seriously wrong that's leading you down this path. > 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: Don't set this - it's an experimental flag, and just sending you further from the issue. (No idea why it's generating this exception). -- Adam > > 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? > > > > > > > > > >