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
>
