A partial workaround is to initialize bean String properties to empty Strings. This doesn't address non-String inputs, which aren't able to be initialized with a meaningful non-null value.

I have created some testcases for this issue, since the user reported using Seam. It turns out that this is the normal behavior for JSF applications.

I created a page with 3 inputTexts I have an ICEfaces+Seam app, ICEfaces only app, and a non-ICEfaces (pure JSF) app. For all three applications, the first time the form is submitted all three fields submit their "" values, and the valueChangeListener method is called. After that, however, for each subsequent form submission, only the field that actually changes has its valueChangeListener method called.

Since ICEfaces does exactly what the pure JSF application does, and it's not an onerous burden for the lifetime of the application, I think this is doing exactly what it's supposed to.

behaviour matches stock JSF

• only inputText components bound to String properties will inadvertently fire the valueChangeListener when changing from a null submitted value (initially) and a blank string submitted value (after first partial or full submit). The workaround is to initialize any String properties to empty Strings.