Note that these failures are consistent between Mojarra JSF 2.0.4-b03 and also JSF 2.1 Sept. 3 SNAPSHOT.

Instrumentation added to mojarra 2.0.4 shows:

saveState class com.icesoft.faces.component.ext.HtmlOutputText iceform:j_idt175 [Ljava.lang.Object;@3347a591
saveState class com.icesoft.faces.component.ext.HtmlPanelGroup iceform:j_idt176 [Ljava.lang.Object;@24c6ece4
saveState class com.icesoft.faces.component.tree.Tree iceform:tree [Ljava.lang.Object;@7fea7f98
!D! saveState class com.icesoft.faces.component.tree.TreeNode iceform:tree:n-2-3 com.sun.faces.application.view.StateHolderSaver@7c5f15c3
!D! saveState class com.icesoft.faces.component.ext.HtmlPanelGroup iceform:tree:n-2-3:j_idt180 com.sun.faces.application.view.StateHolderSaver@468df4ff
!D! saveState class com.icesoft.faces.component.ext.HtmlCommandLink iceform:tree:n-2-3:j_idt181 com.sun.faces.application.view.StateHolderSaver@11cfb589
!D! saveState class javax.faces.component.UIParameter iceform:tree:n-2-3:j_idt182 com.sun.faces.application.view.StateHolderSaver@5b973e81
!D! saveState class com.icesoft.faces.component.ext.HtmlOutputText iceform:tree:n-2-3:TreeNode com.sun.faces.application.view.StateHolderSaver@2688b621
!D! saveState class com.icesoft.faces.component.ext.HtmlPanelGroup iceform:tree:n-2-3:j_idt178 com.sun.faces.application.view.StateHolderSaver@596d444a
!D! saveState class com.icesoft.faces.component.ext.HtmlGraphicImage iceform:tree:n-2-3:j_idt179 com.sun.faces.application.view.StateHolderSaver@149e8424
saveState class com.icesoft.faces.component.ext.HtmlCommandButton iceform:moveUp [Ljava.lang.Object;@32f5620f
saveState class com.icesoft.faces.component.ext.HtmlCommandButton iceform:moveDown [Ljava.lang.Object;@bf8e0ec

Indicating that mojarra is classifying the tree subnodes as dynamic components for some reason.

Additional instrumentation shows that StateContext.handleAddEvent() is specifically invoked for tree subcomponents.

Partial stack trace showing code that triggers "dynamic" classification:

at javax.faces.component.UIComponentBase.doPostAddProcessing(UIComponentBase.java:1751)
at javax.faces.component.UIComponentBase.setParent(UIComponentBase.java:404)
at com.icesoft.faces.component.tree.Tree.visitTreeNodes(Tree.java:1468)
at com.icesoft.faces.component.tree.Tree.visitRows(Tree.java:1448)
at com.icesoft.faces.component.tree.Tree.visitTree(Tree.java:1403)

Several calls to UIComponent.setParent() are found in Tree and TreeRenderer. The purpose of these calls is not yet clear. Typically a component would not change the parent status during rendering.

Removing these setParent calls fixes component-showcase with no other apparent ill effects.

Fix checked in:

===================================================================
— compat/components/src/main/java/com/icesoft/faces/component/tree/Tree.java (revision 22563)
+++ compat/components/src/main/java/com/icesoft/faces/component/tree/Tree.java (working copy)
@@ -965,7 +965,6 @@
.getRoot());
treeNodeTemplate.setMutable(currentNode);
treeNodeTemplate.setId(ID_PREFIX + pathToCurrentNode);

• treeNodeTemplate.setParent(this);

this.setNodePath(pathToCurrentNode);

@@ -1465,7 +1464,6 @@
.getRoot());
treeNodeTemplate.setMutable(currentNode);
treeNodeTemplate.setId(ID_PREFIX + pathToCurrentNode);

• treeNodeTemplate.setParent(this);

this.setNodePath(pathToCurrentNode);

Index: compat/components/src/main/java/com/icesoft/faces/component/tree/TreeRenderer.java
===================================================================
— compat/components/src/main/java/com/icesoft/faces/component/tree/TreeRenderer.java (revision 22563)
+++ compat/components/src/main/java/com/icesoft/faces/component/tree/TreeRenderer.java (working copy)
@@ -338,7 +338,6 @@

treeNode.setMutable(currentNode);
treeNode.setId(Tree.ID_PREFIX + pathToCurrentRoot);

• treeNode.setParent(treeComponent);
  treeComponent.setNodePath(pathToCurrentNode);

// efficiency and simplicity

Assigning to Ken for component team review.

From reviewing the code, we should be able to just remove the setParent call.