[Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
I am wondering if this is a bug or planned with UIXComponentBase: I was noticing that my custom component that extended CoreCommandLink stopped working after a partial update. When trying to figure out why, I noticed that the ID of the link changed between rendering and therefore the decode no longer worked. On first page rendering, the link ID was _id44. During decode, it was still _id44. During encode, it was _id108. It failed partial update because the ID changed, and therefore all further decodes failed since the client was now out of sync from the server. In UIComponentBase.getClientId, if the getId() returns null, a new ID is created and then setId is called. UIXComponentBase never calls setId, but instead caches it in a "_genId" property using the FacesBean. Therefore, anything extending UIComponentBase and has a generated ID will never have its ID change between requests on the same view. However, it seems that UIXComponentBase does not guarantee that a component with a generated ID will have a consistent ID. Here is my code: The cw:helpIcon extends CoreCommandLink If I give the helpIcon a hard coded ID, it works fine. Is this a bug, a shortcoming, or just not supported with UIXComponentBase? I seems like it could be a very big source of problems if IDs change between requests, as decodes will have a lot of problems. Should UIXComponentBase be calling setId after generating an ID in the getClientId function? This was found on 1.0.3-SNAPSHOT Any ideas? Thanks, Andrew
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
If it makes a difference, here is my renderer's code for this component:
public class HelpIconRenderer
extends CommandLinkRenderer
{
public final static String RENDERER_TYPE = "com.christws.HelpIcon";
private PropertyKey messageIdKey;
private PropertyKey forKey;
public HelpIconRenderer()
{
super(UIHelpIcon.TYPE);
}
/**
* @see
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.CommandLinkRenderer#findTypeConstants(org.apache.myfaces.trinidad.bean.FacesBean.Type)
*/
@Override
protected void findTypeConstants(Type type)
{
super.findTypeConstants(type);
messageIdKey = type.findKey("messageId");
forKey = type.findKey("for");
}
/**
* @see
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlRenderer#getStyleClass(org.apache.myfaces.trinidad.bean.FacesBean)
*/
@Override
protected String getStyleClass(FacesBean bean)
{
return "helpButton";
}
/**
* @see
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.CommandLinkRenderer#getPartialSubmit(org.apache.myfaces.trinidad.bean.FacesBean)
*/
@Override
protected boolean getPartialSubmit(FacesBean bean)
{
return true;
}
protected String getFor(FacesBean bean)
{
return toString(bean.getProperty(forKey));
}
protected String getMessageId(FacesBean bean)
{
return toString(bean.getProperty(messageIdKey));
}
/**
* @see
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.CommandLinkRenderer#getImmediate(org.apache.myfaces.trinidad.bean.FacesBean)
*/
@Override
protected boolean getImmediate(FacesBean bean)
{
return true;
}
/**
* @see
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlRenderer#shouldRenderId(javax.faces.context.FacesContext,
javax.faces.component.UIComponent)
*/
@Override
protected boolean shouldRenderId(FacesContext context, UIComponent component)
{
return true;
}
/**
* @see
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.CommandLinkRenderer#encodeEnd(javax.faces.context.FacesContext,
org.apache.myfaces.trinidad.context.RenderingContext,
javax.faces.component.UIComponent,
org.apache.myfaces.trinidad.bean.FacesBean)
*/
@Override
public void encodeEnd(FacesContext context, RenderingContext arc,
UIComponent comp, FacesBean bean) throws IOException
{
CoreIcon icon = FacesUtils.createComponent(CoreIcon.class);
icon.setTransient(true);
icon.setId(context.getViewRoot().createUniqueId());
icon.setName("help");
icon.setParent(comp);
org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(context,
icon);
super.encodeEnd(context, arc, comp, bean);
ResponseWriter writer = context.getResponseWriter();
String forValue = getFor(bean);
UIComponent forComp = ComponentUtils.findRelativeComponent(comp, forValue);
StringBuilder js = new StringBuilder(
"Help.register('").append(forComp.getClientId(context))
.append("', '").append(comp.getClientId(context))
.append("');");
RenderUtils.renderScript(context, js);
}
}
On 9/5/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> I am wondering if this is a bug or planned with UIXComponentBase:
>
> I was noticing that my custom component that extended CoreCommandLink
> stopped working after a partial update. When trying to figure out why,
> I noticed that the ID of the link changed between rendering and
> therefore the decode no longer worked.
>
> On first page rendering, the link ID was _id44. During decode, it was
> still _id44. During encode, it was _id108. It failed partial update
> because the ID changed, and therefore all further decodes failed since
> the client was now out of sync from the server.
>
> In UIComponentBase.getClientId, if the getId() returns null, a new ID
> is created and then setId is called. UIXComponentBase never calls
> setId, but instead caches it in a "_genId" property using the
> FacesBean.
>
> Therefore, anything extending UIComponentBase and has a generated ID
> will never have its ID change between requests on the same view.
> However, it seems that UIXComponentBase does not guarantee that a
> component with a generated ID will have a consistent ID.
>
> Here is my code:
>
>label="Test help">
>simple="true" />
>
>messageId="test_help" />
>
>
>
> The cw:helpIcon extends CoreCommandLink
>
> If I give the helpIcon a hard coded ID, it works fine.
>
> Is this a bug, a shortcoming, or just not supported with UIXComponentBase?
>
> I seems like it could be a very big source of problems if IDs change
> between requests, as decodes will have a lot of problems. Should
> UIXComponentBase be calling setId after generating an ID in the
> getClientId function?
>
> This was found on 1.0.3-SNAPSHOT
>
> Any ideas?
>
> Thanks,
> Andrew
>
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
I don't see how or why this is wrong... _genId should get state saved, so I don't understand why you're having problems unless your custom component has overridden state saving incorrectly. I've never seen a problem like this with any of our Trinidad components. -- Adam On 9/5/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > > I am wondering if this is a bug or planned with UIXComponentBase: > > I was noticing that my custom component that extended CoreCommandLink > stopped working after a partial update. When trying to figure out why, > I noticed that the ID of the link changed between rendering and > therefore the decode no longer worked. > > On first page rendering, the link ID was _id44. During decode, it was > still _id44. During encode, it was _id108. It failed partial update > because the ID changed, and therefore all further decodes failed since > the client was now out of sync from the server. > > In UIComponentBase.getClientId, if the getId() returns null, a new ID > is created and then setId is called. UIXComponentBase never calls > setId, but instead caches it in a "_genId" property using the > FacesBean. > > Therefore, anything extending UIComponentBase and has a generated ID > will never have its ID change between requests on the same view. > However, it seems that UIXComponentBase does not guarantee that a > component with a generated ID will have a consistent ID. > > Here is my code: > >label="Test help"> >simple="true" /> > >messageId="test_help" /> > > > > The cw:helpIcon extends CoreCommandLink > > If I give the helpIcon a hard coded ID, it works fine. > > Is this a bug, a shortcoming, or just not supported with UIXComponentBase? > > I seems like it could be a very big source of problems if IDs change > between requests, as decodes will have a lot of problems. Should > UIXComponentBase be calling setId after generating an ID in the > getClientId function? > > This was found on 1.0.3-SNAPSHOT > > Any ideas? > > Thanks, > Andrew >
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
The code is pretty simplistic for the component:
@FaceletComponent(namespace = "http://christws.com/components";,
tagName = "helpIcon",
type = UIHelpIcon.COMPONENT_TYPE,
rendererType = HelpIconRenderer.RENDERER_TYPE)
public class UIHelpIcon
extends CoreCommandLink
{
public final static String COMPONENT_FAMILY = "com.christws.HelpIcon";
public final static String COMPONENT_TYPE = "com.christws.HelpIcon";
public final static FacesBean.Type TYPE = new FacesBean.Type(
CoreCommandLink.TYPE);
public final static PropertyKey MESSAGE_ID_KEY =
TYPE.registerKey("messageId", String.class);
public final static PropertyKey FOR_KEY =
TYPE.registerKey("for", String.class);
static
{
TYPE.lockAndRegister(COMPONENT_FAMILY, COMPONENT_TYPE);
};
public UIHelpIcon()
{
super(HelpIconRenderer.RENDERER_TYPE);
}
/**
* @see
org.apache.myfaces.trinidad.component.UIXComponentBase#getClientId(javax.faces.context.FacesContext)
*/
@Override
public String getClientId(FacesContext context)
{
// TODO Auto-generated method stub
String id = super.getClientId(context);
return id;
}
/**
* @see javax.faces.component.UIComponent#getFamily()
*/
@Override
public String getFamily()
{
return COMPONENT_FAMILY;
}
public String getMessageId()
{
return ComponentUtils.resolveString(getProperty(MESSAGE_ID_KEY));
}
public void setMessageId(String messageId)
{
setProperty(MESSAGE_ID_KEY, messageId);
}
public String getFor()
{
return ComponentUtils.resolveString(getProperty(FOR_KEY));
}
public void setFor(String value)
{
setProperty(FOR_KEY, value);
}
/**
* @see org.apache.myfaces.trinidad.component.UIXComponentBase#getBeanType()
*/
@Override
protected Type getBeanType()
{
return TYPE;
}
/**
* @see
org.apache.myfaces.trinidad.component.UIXCommand#broadcast(javax.faces.event.FacesEvent)
*/
@Override
public void broadcast(FacesEvent event) throws AbortProcessingException
{
if (event instanceof ActionEvent)
{
HelpBean bean = FacesUtils.getBean(HelpBean.class, true);
bean.setCurrentHelpTopicKey(getMessageId());
}
super.broadcast(event);
}
}
As you can see, I haven't done anything to the state saving at all. I
haven't setup the maven component generation in my project yet so the
above component was hand-written, but I don't think I made any
mistakes, but not positive.
On 9/5/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> I don't see how or why this is wrong... _genId should get state
> saved, so I don't understand why you're having problems unless
> your custom component has overridden state saving incorrectly.
> I've never seen a problem like this with any of our Trinidad components.
>
> -- Adam
>
>
> On 9/5/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> > I am wondering if this is a bug or planned with UIXComponentBase:
> >
> > I was noticing that my custom component that extended CoreCommandLink
> > stopped working after a partial update. When trying to figure out why,
> > I noticed that the ID of the link changed between rendering and
> > therefore the decode no longer worked.
> >
> > On first page rendering, the link ID was _id44. During decode, it was
> > still _id44. During encode, it was _id108. It failed partial update
> > because the ID changed, and therefore all further decodes failed since
> > the client was now out of sync from the server.
> >
> > In UIComponentBase.getClientId, if the getId() returns null, a new ID
> > is created and then setId is called. UIXComponentBase never calls
> > setId, but instead caches it in a "_genId" property using the
> > FacesBean.
> >
> > Therefore, anything extending UIComponentBase and has a generated ID
> > will never have its ID change between requests on the same view.
> > However, it seems that UIXComponentBase does not guarantee that a
> > component with a generated ID will have a consistent ID.
> >
> > Here is my code:
> >
> > > label="Test help">
> >> simple="true" />
> >
> > > messageId="test_help" />
> >
> >
> >
> > The cw:helpIcon extends CoreCommandLink
> >
> > If I give the helpIcon a hard coded ID, it works fine.
> >
> > Is this a bug, a shortcoming, or just not supported with UIXComponentBase?
> >
> > I seems like it could be a very big source of problems if IDs change
> > between requests, as decodes will have a lot of problems. Should
> > UIXComponentBase be calling setId after generating an ID in the
> > getClientId function?
> >
> > This was found on 1.0.3-SNAPSHOT
> >
> > Any ideas?
> >
> > Thanks,
> > Andrew
> >
>
>
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
It works fine outside of the facet, Broken: Works: Looks like a possible bug in the state saving of facets or at least in the panelLabelAndMessage. Any ideas?
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
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: > > label="Test help"> > simple="true" /> > > messageId="test_help" /> > > > > Works: > > label="Test help"> > simple="true" /> > > messageId="test_help" /> > > Looks like a possible bug in the state saving of facets or at least in > the panelLabelAndMessage. Any ideas? >
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
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 temp = new
ArrayList(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:
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:
> >
> > > label="Test help">
> > >simple="true" />
> >
> > > messageId="test_help" />
> >
> >
> >
> > Works:
> >
> > > label="Test help">
> > >simple="true" />
> >
> > >messageId="test_help" />
> >
> > Looks like a possible bug in the state saving of facets or at least in
> > the panelLabelAndMessage. Any ideas?
> >
>
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
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: org.apache.myfaces.trinidad.CLIENT_STATE_METHOD all org.apache.myfaces.trinidad.CACHE_VIEW_ROOT false 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: facelets.BUILD_BEFORE_RESTORE true 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 temp = new > ArrayList(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
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
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: > > > org.apache.myfaces.trinidad.CLIENT_STATE_METHOD > all > This is not likely relevant. > > org.apache.myfaces.trinidad.CACHE_VIEW_ROOT > false > 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: > > > facelets.BUILD_BEFORE_RESTORE > true > > > 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 te
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
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 temp = new
> ArrayList(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.
This is the CACHE_VIEW_ROOT optimization. BTW, this
optimization *has* been tested with Facelets, though not
intensively with especially recent versions.
> As a result the view is never restored fully. That is where I am
> getting the problem.
No, it should be fully restored - all the children from the prior
request should still be there.
>
> 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:
>
>
> name="org.apache.myfaces.trinidad.faces.STATE"/>
>
> That value seems incredible small for a view state.
That's because its a token. Not the full 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.
It's actually a really valuable optimization, especially for PPR.
-- Adam
> 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:
> > >
> > > > > label="Test help">
> > > > >simple="true" />
> > >
> > > > > messageId="test_help" />
> > >
> > >
> > >
> > > Works:
> > >
> > > > > label="Test help">
> > > > >simple="true" />
> > >
> > > > >messageId="test_help" />
> > >
> > > Looks like a possible bug in the state saving of facets or at least in
> > > the panelLabelAndMessage. Any ideas?
> > >
> >
>
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
FYI, I started a new thread entitled "Major bug in facelets 1.1.11
with mark and sweep code?" that is on the facelets user list and CC'd
on this list as a result of my findings from this thread.
-Andrew
On 9/5/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> 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 temp = new
> > ArrayList(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.
>
> This is the CACHE_VIEW_ROOT optimization. BTW, this
> optimization *has* been tested with Facelets, though not
> intensively with especially recent versions.
>
> > As a result the view is never restored fully. That is where I am
> > getting the problem.
>
> No, it should be fully restored - all the children from the prior
> request should still be there.
>
> >
> > 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:
> >
> >
> > > name="org.apache.myfaces.trinidad.faces.STATE"/>
> >
> > That value seems incredible small for a view state.
>
> That's because its a token. Not the full 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.
>
> It's actually a really valuable optimization, especially for PPR.
>
> -- Adam
>
> > 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:
> > > >
> > > > > > > label="Test help">
> > > > > > >simple="true" />
> > > >
> > > > > > > messageId="test_help" />
> > > >
> > > >
> > > >
> > > > Works:
> > > >
> > > > > > > label="Test help">
> > > > > > >simple="true" />
>
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
Just so that people don't have to search: it's a bug in Facelets fixed
in the latest version 1.1.13.
regards,
Martin
On 9/6/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> FYI, I started a new thread entitled "Major bug in facelets 1.1.11
> with mark and sweep code?" that is on the facelets user list and CC'd
> on this list as a result of my findings from this thread.
>
> -Andrew
>
> On 9/5/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > 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 temp = new
> > > ArrayList(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.
> >
> > This is the CACHE_VIEW_ROOT optimization. BTW, this
> > optimization *has* been tested with Facelets, though not
> > intensively with especially recent versions.
> >
> > > As a result the view is never restored fully. That is where I am
> > > getting the problem.
> >
> > No, it should be fully restored - all the children from the prior
> > request should still be there.
> >
> > >
> > > 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:
> > >
> > >
> > > > > name="org.apache.myfaces.trinidad.faces.STATE"/>
> > >
> > > That value seems incredible small for a view state.
> >
> > That's because its a token. Not the full 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.
> >
> > It's actually a really valuable optimization, especially for PPR.
> >
> > -- Adam
> >
> > > 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
> > > > sou
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
FYI, earliest fix can be found in in 1.1.12
On 9/7/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> Just so that people don't have to search: it's a bug in Facelets fixed
> in the latest version 1.1.13.
>
> regards,
>
> Martin
>
> On 9/6/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> > FYI, I started a new thread entitled "Major bug in facelets 1.1.11
> > with mark and sweep code?" that is on the facelets user list and CC'd
> > on this list as a result of my findings from this thread.
> >
> > -Andrew
> >
> > On 9/5/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > > 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 temp = new
> > > > ArrayList(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.
> > >
> > > This is the CACHE_VIEW_ROOT optimization. BTW, this
> > > optimization *has* been tested with Facelets, though not
> > > intensively with especially recent versions.
> > >
> > > > As a result the view is never restored fully. That is where I am
> > > > getting the problem.
> > >
> > > No, it should be fully restored - all the children from the prior
> > > request should still be there.
> > >
> > > >
> > > > 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:
> > > >
> > > >
> > > > > > > name="org.apache.myfaces.trinidad.faces.STATE"/>
> > > >
> > > > That value seems incredible small for a view state.
> > >
> > > That's because its a token. Not the full 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.
> > >
> > > It's actually a really valuable optimization, especially for PPR.
> > >
> > > -- Adam
> > >
> > > > 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)
