I just spend two days writing a bunch of base-classes for JSF component-collaboration that do the lookup of related components in the tag-handler allowing you to access the other UIComponents independent from the component-tree structure easily. Just like a logical structure in parallel to the component tree for each compound-component. For ease of reuse I stored the references to the other UIComponents by means of regular statesaving. Everything worked fine and writing the first few compound-components to test this in reall life was basically a snap until...

...until I turned on client-side statesaving.

Whenever a view got restored that was saved in the client the references to the other UIComponents in parallel to the component-tree didn't reference the correct components anymore, but copies of them. Bad thing. A clear indicator that there was not just simple serialization of the component-tree going on. So I did some digging into the code of the JSF 1.2 RI to understand why this is happening and how I could go around this (using the standard apis).

In current versions of JSF the component-tree structure and the component-state are stored and restored via the StateManager that still makes use of the deprecated methods getTreeStructureToRestore() and getComponentStateToRestore(). The tree-structure consists of an (implementation-specific) object containing structural information while the tree-state contains the Object-array-tree that is the result of calling all the saveState()-methods on all UIComponents implementing StateHolder. So when it's time to restore the view first the structure is restored, then the state is applied to it. And because the tree-structure object does not contain references to the original UIComponent-instances the rebuild view consists of new instances of UIComponents instead of deserialized ones so the serialized versions of UIComponents that are stored in the state are just not the same instances as the ones the rebuild view consist of.

And without rewriting a majar part of the framework there's no way to go around this. Just don't store references to UIComponents in component-state. period.