myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
Date Thu, 06 Sep 2007 05:16:16 GMT
On 9/5/07, Andrew Robinson <andrew.rw.robinson@gmail.com> 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 <andrew.rw.robinson@gmail.com> 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 <andrew.rw.robinson@gmail.com> 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 <andrew.rw.robinson@gmail.com> 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?
> > > >
> > >
> >
>

Mime
View raw message