Note : jboss-seam-2.0.0.Beta1 & jsf1.2 implementation has been used.

Please add technical perspective to this issue.

When Greg looked at this before his holidays, he thought that there was an issue with the jsf-1.2 ri (used in jBoss AS 4.2.1.GA) :-

To refresh -> the PageContext object from Seam is placed into the UIViewRoot implementation and uses JSF NavigationHandler to manage the context)
Thus, each new non-faces request (standard seam request) is a new GET request for a new page or redirect to same page. This results in a new PageContext (old one is flushed)

To support this, a tokenn is inserted into the request parameter map in the ServletExternalContext when it's created, and then consumed in the D2DViewHandler. If the token is present, the ViewHandler returns null from the restoreView() method, cuasing createView to be called. (works well in MyFaces)

Code in D2DViewHandler.createView() has

root.setViewId(viewId);
context.setViewRoot(root);
contextServletTable.put(DOMResponseWriter.RESPONSE_VIEWROOT,root);

meaning that once a viewRoot is created, it's put into the FacesContext.

DIfficulty is following code in RestoreViewPhas in jsf source 1.2_04

//if an apphad explicitly set the tree in the context use that;
//
UIViewRoot viewRoot = facesContext.getViewRoot();
if (viewRoot != null) {
System.out.println(" Found ViewRoot in Context, returning");
if (logger.isLoggable(Level.FINE))

facesContext.getViewRoot().setLocale(
facesContext.getExternalContext().getRequestLocale());
doPerComponentActions(facesContext, viewRoot);
return;
}

Greg's thoughts on this:-

Unfortunately, this sidesteps the logic in our D2DViewHandler. In fact,
our ViewHandler is never called, and can no longer influence the
behaviour of viewRoot management. I'm not sure why this is this way,
since it seems to take the decision making from the ViewHandler, and
puts it into the Lifecycle class, but there it is.

Note that this primarily affects Seam applications, but there is code in
restoreView that isn't being called for all ICEfaces applications.
contextServletTable? DomResponseContexts? mungeViewId()?

The solution seems to have to be not to put the ViewRoot into the
FacesContext. Once it's there, it will be used until we visit a new
viewID. I think we're going to have to come up with a different way of
restoring the View. Perhaps StateManagement (on the restore end) is
necessary after all.

Also to note, while running the icefaces-booking example through the MyEclipse debugger, it kept stumbling upon the following Method:-

BridgeFacesContext:switchToPushMode()
Fills several copies of the sessionMap into the Variables view and freezes the debugger. The comments above this method leave one to wonder if this is another probably cause.

sample icefaces-booking ear and ds file (for database configuration)--uses built-in hypersonic database that comes with jboss AS 4.2.1.GA

database configuration file for icefaces-booking example

added icefaces-booking ear that shows that actual conversation stack in Seam is correct. Problem is with Seam Framework classes. They are not being flushed properly (need to be manipulated during RENDER_RESPONSE phase. Same problem is happening in icefaces-seam-gen with EntityHome object. It is not getting flushed so when you try to delete something that has been added into the tables, you have a "transient" instance of the object (same object hadn't been flushed).

fixed with ICEfaces 1.6.1