Hey guys,
There is some oddness that I'm seeing in Trinidad which is going to
cause some issues with the 301 implementation and I'm trying to
understand the problem so that I can figure out whether we need to go
another route with 301 or what.. Here is the code I'm looking at:
public UIViewRoot popRoot(FacesContext fc)
{
UIViewRoot root = null;
Object viewRootState = null;
// we need to synchronize because we are mutating _root
// which is shared between simultaneous requests from the same user:
synchronized(this)
{
if (_root != null)
{
root = _root;
viewRootState = _viewRootState;
// we must clear the cached viewRoot. This is because
UIComponent trees
// are mutable and if the back button
// is used to come back to an old PageState, then it would be
// really bad if we reused that component tree:
_root = null;
_viewRootState = null;
}
}
if (root != null)
{
// If an error happens during updateModel, JSF 1.1 does not
// clear FacesEvents (or FacesMessages, IIRC), so any pending
// events will still be present, on the subsequent request.
// so to clear the events, we create a new UIViewRoot.
// must get the UIViewRoot from the application so that
// we pick up any custom ViewRoot defined in faces-config.xml:
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;
}
return null;
}
}
The part that is going to cause an issue is where root != null. The
reason for this is that in the portal environemnt we use a custom
UIViewRoot that implements a naming container. Therefore, doing this
call gives us the original UIViewRoot as opposed to the bridge's
UIViewRoot. The comment seems to indicate that this was added for JSF
1.1, so is this needed in the 1.2 branch? If so, when would this case
occur and is there anyway to not have to do this?
Thanks,
Scott O'Bryan
