I've been answering this question a lot recently.
There's nothing in the spec that allows us to coerce from one type to
another for f:selectItem.
4.1.13.2 Properties
The server-side value of this item, of the same
basic data type as the parent component's
value. If the parent component type's value is a
value binding expression that points at a
primitive, this value must be of the
corresponding wrapper type
However, we could allow such a coercion for t:selectItem.
Another workaround that might help is using "#{1}" instead of "1"
On 3/14/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
I was having a problem with a bug in 1.1.3 of tomahawk/myfaces that
was fixed in 1.1.5 core, so I decided to upgrade to
1.1.5/1.1.5-Snapshot. After the upgrade, many of my select controls
(selectOneRadio, selectOneMenu, etc.) are now broken. The cause is
that in 1.1.3 non-converted values were allowed, but in 1.1.5 they are
not.
Example:
<t:selectOneRadio value="#{bean.value}">
<f:selectItem itemValue="1" />
<f:selectItem itemValue="2" />
</t:selectOneRadio>
public class MyBean {
private int value;
public int getValue() {return value;}
public void setValue(int value) { this.value = value; }
}
In 1.1.3, this worked. In 1.1.5 this fails. The reason for the failure
is that in 1.1.5 it looks for a select item with value of Integer(1)
or Integer(2), but the select items contain "1" and "2". Since the
following are false:
new Integer(1) == "1" && (new Integer(1)).equals("1")
The validation always fails. This was a nice feature in 1.1.3, that
the item value of a select item can be a string representation that
the converter would take care of. Was this part of the JSF spec. and
1.1.3 was not compliant, or was there another reason?
Thanks,
Andrew
