On Tue, Mar 30, 2010 at 6:06 PM, Martin Marinschek <mmarinschek@apache.org> wrote:

> Hmm... that's not what I'm seeing. Interesting point, though.

Can you check what type the value-expressions that you are looking at
are created with?

You're correct -- they're created with expectedType of Object.class. The problem I was seeing specific to Tomcat, and for some reason it doesn't use the expected type when setting the value of the expression in org.apache.el.parser.AstValue:

    public void setValue(EvaluationContext ctx, Object value)            throws ELException {
        Target t = getTarget(ctx);
        ctx.setPropertyResolved(false);
        ELResolver resolver = ctx.getELResolver();

        // coerce to the expected type
        Class<?> targetClass = resolver.getType(ctx, t.base, t.property);
        if (COERCE_TO_ZERO == true
                || !isAssignable(value, targetClass)) {
            value = ELSupport.coerceToType(value, targetClass);
        }
        resolver.setValue(ctx, t.base, t.property, value);
    }

This method is called by org.apache.el.ValueExpressionImpl:

    public void setValue(ELContext context, Object value)
            throws PropertyNotFoundException, PropertyNotWritableException,
            ELException {
        EvaluationContext ctx = new EvaluationContext(context, this.fnMapper,
                this.varMapper);
        this.getNode().setValue(ctx, value);
    }

(AstValue is a Node subclass.) Am I missing something, or should it be looking at the expectedType instead of the actual type?

I can get around this issue in Tomcat by setting the system property org.apache.el.parser.COERCE_TO_ZERO=false, but I'm quite concerned about this problem in general case.

> Just to make things more complicated, take a look at this issue:
> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=672. Looks like
> Mojarra handles this the way we'd expect, but only when performing injection
> on newly created managed beans, so we have inconsistent behavior...

ah yes, so Ryan has done a fix for this part of the problem. We need
this _all over_.

True. The problem is that now it's pretty inconsistent, which is not good.

best regards,

Martin

>>
>> >> On Mon, Mar 29, 2010 at 9:21 PM, Kito Mann <kito.mann@virtua.com>
>> >> wrote:
>> >> > I just ran into this while upgrading an application from MyFaces 1.1
>> >> > to
>> >> > Mojarra 1.2. In MyFaces 1.1, empty strings were converted to null for
>> >> > Long
>> >> > properties in a backing bean. Now, they are converted to 0. I found
>> >> > several
>> >> > postings about this issue, culminating in this bug:
>> >> > https://jsp-spec-public.dev.java.net/issues/show_bug.cgi?id=183.
>> >> >
>> >> > So, unless I'm missing something, this issue is really the same as
>> >> > https://uel.dev.java.net/issues/show_bug.cgi?id=12. If everyone
>> >> > agrees,
>> >> > I'll
>> >> > go ahead and update the description accordingly, since the
>> >> > description
>> >> > currently mentions Booleans only, not number values.
>> >> >
>> >> > Are there any plans to address this issue in 1.2 branches of the
>> >> > implementations?
>> >> > ---
>> >> > Kito D. Mann | twitter: kito99 | Author, JSF in Action
>> >> > Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
>> >> > consulting
>> >> > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
>> >> > twitter:
>> >> > jsfcentral
>> >> > +1 203-404-4848 x3
>> >> >
>> >> > Sign up for the JSFCentral newsletter:
>> >> > http://oi.vresp.com/?fid=ac048d0e17
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Mar 4, 2010 at 11:51 AM, Andy Schwartz
>> >> > <andy.schwartz@oracle.com>
>> >> > wrote:
>> >> >>
>> >> >> On 3/4/10 3:01 AM, Martin Marinschek wrote:
>> >> >>>
>> >> >>> Optionally, we can try to solve this in the new spec-revision of
>> >> >>> the
>> >> >>> Unified-EL - for which work is already being started on. That would
>> >> >>> of
>> >> >>> course be the easier way out.
>> >> >>>
>> >> >>
>> >> >> One option might be to allow the JSF implementations to provide this
>> >> >> functionality in an implementation-specification way (eg. expose a
>> >> >> context
>> >> >> parameter) as a short-term solution that can be exposed now
>> >> >> independent
>> >> >> of
>> >> >> any spec changes. Then, once the new revision of UEL is available
>> >> >> (which I
>> >> >> am sure will address this issue), we can pick that up as our
>> >> >> standard
>> >> >> solution.
>> >> >>
>> >> >> Andy
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> http://www.irian.at
>> >>
>> >> Your JSF powerhouse -
>> >> JSF Consulting, Development and
>> >> Courses in English and German
>> >>
>> >> Professional Support for Apache MyFaces
>> >
>> >
>>
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>
>

--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces