These changes were made in early early December, and are fresh for 1.5.2

D2DViewHandler.java

I refactored the code to create a new ViewRoot in the createView method, and to
potentially return null from the restoreView method. This now fits into how the
LifecycleImpl class in myFaces actually uses it. The LifecycleImpl class calls
restoreView, and if the view cannot (or should not) be restored, the restoreView
method can return null, in which case, the lifecycleImpl class does some
initialization work, and then calls createView.

Our previous implementation of this put the code in restoreView, and the
subsequent call to createView just called restoreView, which caused that method
to be called twice each time the ViewRoot needed to be called, which required a
bunch of extra state to remember when it was correct to return a view or not.
Bah. This conforms to the spec, and eliminates a lot of complexity, and allows
us to duplicate the lifecycle shortcuts that Seam is explicitly written to expect.

IF the ViewRoot is created, the lifecycle moves directly to renderResponse, and
the intervening phases are skipped. If ICEfaces goes through the intervening
phases, we have a tendency to stomp over subtle DataModel settings that Seam has
orchestrated. The one concrete example is the showorders.xhtml page in the
dvdstore application, which used a GET request redirecting to the same page once
the order had been selected. Seam remembered which order was selected, and the
page displayed it. This would display nothing under the original ICEFaces code
as the data List selection index was reset during the JSF lifecycle. There are
other examples of this failure in the dvdstore application under the admin pages.

Head revision: 12538; 1.5 branch revision: 12742


PersistentFacesServlet.java

As Seam 1.1 was released, we started to get exceptions from some Seam example
applications during Seam GET requests as access to the requestParametersValueMap
 was invalid. The requestParameterValuesMap wasn't yet populated in all
invocations. I added a call to the
BlockingServlet.populateRequestParameters(Map) method to populate the copy of
the original Map from the PersistentFacesServlet, where it likely was not
required before Seam integration.

Head revision: 12544; 1.5 branch revision: 12743

BlockingServlet.java

Made the method populateRequestParameters(Map) static, so it can be used from
PFServlet.
Head revision: 12549; 1.5 branch revision: 12744