Hi Bauke,
Is that the only use case that would still require this setting?
If so could we phase this setting out in 2.3 and tell people that would
need this to register their own EL resolver and make sure that the JSF
runtime always uses EL coercion to determine the actual value?
What do you think?
Manfred
On 10/15/14, 10:37 AM, Bauke Scholtz wrote:
> Hi,
>
> The INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL has still any use.
> Without it, BV's @NotNull wouldn't have any effect.
>
> The problem here is that COERCE_TO_ZERO has in Tomcat been changed to
> not be applied on java.lang.String anymore. See Tomcat 8 source:
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-jasper-el/8.0.11/org/apache/el/lang/ELSupport.java#ELSupport.coerceToType%28java.lang.Object%2Cjava.lang.Class%29
> Compare it to Tomcat 7 source where it get applied on everything,
> including String:
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-jasper-el/7.0.55/org/apache/el/parser/AstValue.java#AstValue.setValue%28org.apache.el.lang.EvaluationContext%2Cjava.lang.Object%29
>
> This change is indeed a major drawback. I tried to reproduce this on
> WildFly 8.1.0 which uses com.sun EL impl. It unfortunately also
> pollutes the model with empty strings during update model values phase
> after EL-coercing the null submitted value to empty string. I see one
> possible theoretical trick: fool the EL ValueExpression by telling
> that we want to resolve it as java.lang.Object instead of
> java.lang.String.
>
> Cheers, Bauke
>
>
>
> On Wed, Oct 15, 2014 at 5:23 PM, manfred riem <manfred.riem_at_oracle.com
> <mailto:manfred.riem_at_oracle.com>> wrote:
>
> Hi Koen,
>
> I think this is a perfect issue to bring up on the new JSF 2.3
> Expert Group list, I have copied them.
>
> Experts please weigh in and keep Koen on your responses.
>
> Note I have removed dev_at_javaserverfaces.java.net
> <mailto:dev_at_javaserverfaces.java.net> to avoid cross posting.
>
> Thanks!
> Manfred
>
> On 10/15/14, 9:08 AM, Koen Serneels wrote:
>>
>> Hi,
>>
>> When binding a JSF input text to a String property of a JSF
>> ManagedBean, I want that an empty value is mapped to null and not
>> "" (empty string).
>>
>> So, on tomcat7 (7.0.56) with JSF(2.2 RI) I can get this to work
>> nicely by controlling the coercing behavior with the JVM property
>> org.apache.el.parser.COERCE_TO_ZERO icw JSF
>> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL as
>> context param.
>>
>> When javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
>> is set to true, JSF will set the local component value for the
>> input component as null when the input if left empty.
>>
>> Next, when the value is actually set by tomcat's EL parser, it
>> will NOT try to coerce the value when
>> org.apache.el.parser.COERCE_TO_ZERO is set to false and the value
>> remains null as I want (= OK)
>>
>> However (as I first posted this on the tomcat dev mailinglist) as
>> of Tomcat8 and EL3 , a null value is coerced to “” (empty String)
>> by the EL parser and the COERCE_TO_ZERO property has no longer
>> any effect.
>>
>> This is as the specification now by default converts “” to null
>> in case of a non-primitive number. But, in case of String, the
>> specs says that a empty string (“”) is not coerced to null and
>> remains empty String.
>>
>> The relevant parts from the EL 3 spec:
>>
>> 1.23.2 Coerce A to String
>>
>> If A is null: return “”
>>
>> 1.23.3 Coerce A to Number type N
>>
>> If A is null and N is not a primitive type, return null.
>>
>> If A is null or "", return 0.
>>
>> My questions:
>>
>> -Wrt EL3, does the JSF param
>> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL has
>> any use left?
>> Since the EL impl converts the null resulting from this property
>> to empty String according to the spec
>>
>> -Is there a way that I can change this behavior in any way so
>> that I can have null instead of empty String for empty text
>> fields with Tomcat8/JSF2.2 RI?
>>
>> Thanks,
>>
>> Koen.
>>
>