These components also exhibit similar behaviour:
selectBooleanCheckbox, selectManyListbox, selectInputText, selectManyMenu, selectOneListbox

The following components have also been verified to have that behavior:
selectOneMenu, inputTextarea, inputHidden, inputRichText

This is a result of how UIData intentionally works. You simply cannot use UIInput/EditableValueHolder components in a UIData without using a ValueBinding/ValueExpression for their value attribute.

Basically, UIData maintains state for all of its child UIInput/EditableValueHolder components until validation succeeds. It only keeps the state if there exists a FacesMessage, which is its heuristic for Validation failing, so that user inputted values won't disappear if they were invalid. This causes unexpected failures, as value becomes null before the render phase.

The reason why I'm counting this as Fixed, and not Invalid, is that I've changed our component metadata to better document how the value attribute works, so that hopefully people can avoid this issue. I ran into some corner cases in the component metadata, which I spun off into ICE-2687.

Subversion 15685

You might be able to capitalise off of ICE-2297, by nesting your UIData, so that it will maintain the state. This is why this issue doesn't pop up with ice:columns, because ice:columns and ice:dataTable are both UIData, so it's the nested UIData special case. You could also put it inside a faked out an ice:panelSeries by giving it a single entry data model.

I do not understand the previous commnt. What is ment by putting it out an ice:panelSeries: Following xhtml:

<ice:panelSeries value="#

" var="currProp"
varStatus="currPropStatus">

<ice:inputText rendered="#

" id="xxx"
required="#

" />

</ice:panelSeries>

What I have to do to get it run? The state of the ice:inputText is not holded.