The core of the problem is that even though the actual list instance that is being wrapped did not change, the code outjects a new wrapper. If the code is updated to preserve the existing wrapper if the underlying wrapped data is not changed then the problem goes away. (This is the fix proposed in http://jira.jboss.com/jira/browse/JBSEAM-308) Brief overview of the flow that occurs : Decode Phase: UIInput decodes itself. UIData grabs the DataModel (instance 1) via the value binding and caches it then decodes each row. UpdateModel Phase: UIInput calls setText via value binding. Injection -- Existing DataModel (instance 1, the same that UIData is caching) is injected into FooBean Outjection -- The list backing the datamodel does not change but a new wrapper is created and outjected (instance 2) UIData iterates over its cached DataModel(instance 1) InvokeApplication Phase UIData fires the its ActionEvent, sets the appropriate row on the cached DataModel (instance 1). UICommand calls dummy via method binding Injection -- Existing DataModel (instance 2, which was oujected because of call to setText) is injected along with its selection (currently row 0, as the UIData set the row on instance 1 instead of instance 2) Outjection -- The list backing the datamodel does not change but a new wrapper is created and outjected (instance 3) UIData caches its DataModel reference If any components are caching the outjected value (which is the case with a UIData) they wont be working on the "current" value in the contexts. Later when injection occurs the "current" value (which is no longer the same as the instance View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972955#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...