When applying Gareth Morgan's bug fix for JspRuntimeLibrary in the Tomcat MAIN
branch, a difference between the tomcat_32 and MAIN versions revealed that
Tomcat 3.2 still has the bug discovered by Glenn Nielsen. This is where:
<jsp:setProperty name="bean" property="prop" value=""/>
leaves the property unchanged instead of setting it to an empty string. As Glenn
noted, the spec calls for ignoring an empty string when param is used, i.e.:
<jsp:setProperty name="bean" property="prop" param="prop"/>
with a query string of "?prop=". But doesn't say to ignore it for value. This
is easily fixed.
However, its not clear to me what the spec calls for with respect to empty
strings and indexed properties. Also, Tomcat 3.2's current behavior seems
inconsistent on this issue. I tested the following cases where the
property is a String array:
1) <jsp:setProperty name="bean" property="prop" param="prop"/>
2) <jsp:setProperty name="bean" property="prop"/>
3) <jsp:setProperty name="bean" property="*"/>
For an empty query string, or a query string with mutlitple non-empty values,
you get the expected result. However, for the following query strings
which involve empty values, I get the following results for how the String
array is set.
Query String Result1 Result2 Result3 Spec
?prop= "" "" not changed not changed
?prop=&prop= "","" "","" not changed ???
?prop=&prop=text "","text" "","text" not changed ???
I would expect the results to be the same instead of different. The spec
doesn't say that ignoring an empty value shouldn't apply to an indexed
property. But if that's true, what about "?prop=&prop="? Should this be
ignored too? And should "?prop=&prop=text" set the property to a single
element array containing "text"?
Am I missing something in the spec? Can someone shed some light on what
proper behavior should be?
I'm +1 on fixing the <jsp:setProperty name="bean" property="prop" value=""/>
bug in Tomcat 3.2. If the desired behavior for indexed properties can be
determined, I can try to fix that too.
Cheers,
Larry
__________
Larry Isaacs
[EMAIL PROTECTED]
SAS Institute Inc.
