IIRC, JSF 2.0/JSP 2.1 has the unfortunate behavior of coercing
null to zero, false, and the empty string, for integers, booleans
and strings repectively, at least for "get" calls. (The last of those is
especially annoying.) Don't know about "set" calls offhand.
-- Adam
On 6/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
fwiw -- hibernate has the same behavior when assigning primitives from
null values in a resultset.
Mike wrote:
========================================
Well, I'd say because there's no guarantee that mapping 0 to null is a
good choice.
It may be that the next user wants null mapped to -1.
My suggestion in this described use case is that you use Integer
instead of int if there's a possibility that the value could be null.
Then you can use whichever value you prefer if you receive a null
value. You can make it a wrapper method on another bean if you
don;'t want to change the original bean.
On 6/5/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> hi,
>
> following scenario.
>
> a (form) page renders and it has an input with #{bean.prop}, where
> prop is int (not Integer).
>
> The page renders and the value is 0 (since the variable is declared
> like "private int prop;")
>
> Now I can change it to 3. Fine. When I remove the value (not a
> required=true field) I get an javax.faces.el.EvaluationException
> inside the PropertyResolverImpl.setPropert(...)
>
>
> try
> {
> m.invoke(base, new Object[] {newValue});
> }
> catch (Throwable t)
> {
> log.debug("Exception while invoking setter method.",t);
> throw new EvaluationException(getMessage(base, name,
> newValue, m), t);
> }
>
>
> the getMessage(...) give me this string:
> Bean: com.company.Bean, property: prop, newValue: null ,newValue
> class: null method parameter class: int
>
> So far so good, but why not doing a isPrimitive() check on property
> and set it to 0 incase of int, for instance.
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> mail: matzew-at-apache-dot-org
>
