<br clear="all">---<br>Kito D. Mann | twitter: kito99 | Author, JSF in Action<br>Virtua, Inc. | <a href="http://www.virtua.com">http://www.virtua.com</a> | JSF/Java EE training and consulting<br><a href="http://www.JSFCentral.com">http://www.JSFCentral.com</a> - JavaServer Faces FAQ, news, and info | twitter: jsfcentral<br>
+1 203-404-4848 x3<br><br>Sign up for the JSFCentral newsletter: <a href="http://oi.vresp.com/?fid=ac048d0e17">http://oi.vresp.com/?fid=ac048d0e17</a><br><br>
<br><br><div class="gmail_quote">On Tue, Mar 30, 2010 at 6:06 PM, Martin Marinschek <span dir="ltr"><<a href="mailto:mmarinschek@apache.org">mmarinschek@apache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">> Hmm... that's not what I'm seeing. Interesting point, though.<br>
<br>
</div>Can you check what type the value-expressions that you are looking at<br>
are created with?<br></blockquote><div><br>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:<br>
<br> public void setValue(EvaluationContext ctx, Object value) throws ELException {<br> Target t = getTarget(ctx);<br> ctx.setPropertyResolved(false);<br> ELResolver resolver = ctx.getELResolver();<br>
<br> // coerce to the expected type<br> Class<?> targetClass = resolver.getType(ctx, t.base, t.property);<br> if (COERCE_TO_ZERO == true<br> || !isAssignable(value, targetClass)) {<br>
value = ELSupport.coerceToType(value, targetClass);<br> }<br> resolver.setValue(ctx, t.base, t.property, value);<br> }<br><br><br>This method is called by org.apache.el.ValueExpressionImpl:<br>
<br> public void setValue(ELContext context, Object value)<br> throws PropertyNotFoundException, PropertyNotWritableException,<br> ELException {<br> EvaluationContext ctx = new EvaluationContext(context, this.fnMapper,<br>
this.varMapper);<br> this.getNode().setValue(ctx, value);<br> }<br><br>(AstValue is a Node subclass.) Am I missing something, or should it be looking at the expectedType instead of the actual type?<br>
<br>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. <br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> Just to make things more complicated, take a look at this issue:<br>
> <a href="https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=672" target="_blank">https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=672</a>. Looks like<br>
> Mojarra handles this the way we'd expect, but only when performing injection<br>
> on newly created managed beans, so we have inconsistent behavior...<br>
<br>
</div>ah yes, so Ryan has done a fix for this part of the problem. We need<br>
this _all over_.<br></blockquote><div><br>True. The problem is that now it's pretty inconsistent, which is not good. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5"><br>
best regards,<br>
<br>
Martin<br>
<br>
>><br>
>> >> On Mon, Mar 29, 2010 at 9:21 PM, Kito Mann <<a href="mailto:kito.mann@virtua.com">kito.mann@virtua.com</a>><br>
>> >> wrote:<br>
>> >> > I just ran into this while upgrading an application from MyFaces 1.1<br>
>> >> > to<br>
>> >> > Mojarra 1.2. In MyFaces 1.1, empty strings were converted to null for<br>
>> >> > Long<br>
>> >> > properties in a backing bean. Now, they are converted to 0. I found<br>
>> >> > several<br>
>> >> > postings about this issue, culminating in this bug:<br>
>> >> > <a href="https://jsp-spec-public.dev.java.net/issues/show_bug.cgi?id=183" target="_blank">https://jsp-spec-public.dev.java.net/issues/show_bug.cgi?id=183</a>.<br>
>> >> ><br>
>> >> > So, unless I'm missing something, this issue is really the same as<br>
>> >> > <a href="https://uel.dev.java.net/issues/show_bug.cgi?id=12" target="_blank">https://uel.dev.java.net/issues/show_bug.cgi?id=12</a>. If everyone<br>
>> >> > agrees,<br>
>> >> > I'll<br>
>> >> > go ahead and update the description accordingly, since the<br>
>> >> > description<br>
>> >> > currently mentions Booleans only, not number values.<br>
>> >> ><br>
>> >> > Are there any plans to address this issue in 1.2 branches of the<br>
>> >> > implementations?<br>
>> >> > ---<br>
>> >> > Kito D. Mann | twitter: kito99 | Author, JSF in Action<br>
>> >> > Virtua, Inc. | <a href="http://www.virtua.com" target="_blank">http://www.virtua.com</a> | JSF/Java EE training and<br>
>> >> > consulting<br>
>> >> > <a href="http://www.JSFCentral.com" target="_blank">http://www.JSFCentral.com</a> - JavaServer Faces FAQ, news, and info |<br>
>> >> > twitter:<br>
>> >> > jsfcentral<br>
>> >> > +1 203-404-4848 x3<br>
>> >> ><br>
>> >> > Sign up for the JSFCentral newsletter:<br>
>> >> > <a href="http://oi.vresp.com/?fid=ac048d0e17" target="_blank">http://oi.vresp.com/?fid=ac048d0e17</a><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > On Thu, Mar 4, 2010 at 11:51 AM, Andy Schwartz<br>
>> >> > <<a href="mailto:andy.schwartz@oracle.com">andy.schwartz@oracle.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> On 3/4/10 3:01 AM, Martin Marinschek wrote:<br>
>> >> >>><br>
>> >> >>> Optionally, we can try to solve this in the new spec-revision of<br>
>> >> >>> the<br>
>> >> >>> Unified-EL - for which work is already being started on. That would<br>
>> >> >>> of<br>
>> >> >>> course be the easier way out.<br>
>> >> >>><br>
>> >> >><br>
>> >> >> One option might be to allow the JSF implementations to provide this<br>
>> >> >> functionality in an implementation-specification way (eg. expose a<br>
>> >> >> context<br>
>> >> >> parameter) as a short-term solution that can be exposed now<br>
>> >> >> independent<br>
>> >> >> of<br>
>> >> >> any spec changes. Then, once the new revision of UEL is available<br>
>> >> >> (which I<br>
>> >> >> am sure will address this issue), we can pick that up as our<br>
>> >> >> standard<br>
>> >> >> solution.<br>
>> >> >><br>
>> >> >> Andy<br>
>> >> >><br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >><br>
>> >> <a href="http://www.irian.at" target="_blank">http://www.irian.at</a><br>
>> >><br>
>> >> Your JSF powerhouse -<br>
>> >> JSF Consulting, Development and<br>
>> >> Courses in English and German<br>
>> >><br>
>> >> Professional Support for Apache MyFaces<br>
>> ><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>><br>
>> <a href="http://www.irian.at" target="_blank">http://www.irian.at</a><br>
>><br>
>> Your JSF powerhouse -<br>
>> JSF Consulting, Development and<br>
>> Courses in English and German<br>
>><br>
>> Professional Support for Apache MyFaces<br>
><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="h5"><br>
<a href="http://www.irian.at" target="_blank">http://www.irian.at</a><br>
<br>
Your JSF powerhouse -<br>
JSF Consulting, Development and<br>
Courses in English and German<br>
<br>
Professional Support for Apache MyFaces<br>
</div></div></blockquote></div><br>