[jsr-314-open-mirror] [jsr-314-open] Coercion in the EL

[Kito Mann]

---
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 Tue, Mar 30, 2010 at 6:06 PM, Martin Marinschek
<mmarinschek at 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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100330/5b4d868d/attachment-0002.html