There is code that inserts an object into the request parameter map in the update method, in the PortletExternalContext, and the ServletExternalContext. This correctly triggers the logic in the JSF restoreView implementation class to treat the request as a postback. The problem is, update is being called on both partial and fresh non-jsf GET requests, essentially making everything a postback.

One of the symptoms of this problem are Seam DataModel objects no longer working. In some rare instances, Seam example code has the following type of behaviour:

User clicks on an item from a data table,
seam link tag causes a redirect from the table item to the same page
the UI now displays the contents of the chosen record on the same page

This type of interaction would be broken because after the redirect, the phases that are supposed to be executed are restoreView, which will cause a new viewRoot to be created, and renderResponse, since we have a brand new View.

In our case, the postback token causes the view to be restored, and the full JSF lifecycle is executed. As part of the full lifecycle, the DataModel data holding objects get cleared, and the visible result is that no matter what record the user clicks in the dataTable, only the first record is ever displayed, edited, deleted, etc.