Hi Nate,
Thanks for reaching out!
What I can't understand is how your app evaluates the value. Because I see the
following in Struts UIBean.java since 2006:
// see if the value was specified as a parameter already
if (parameters.containsKey("value")) {
parameters.put("nameValue" , parameters.get("value"));
} else {
which I think means that it doesn't evaluate value if you've already set it. As
far as I remember Struts evaluates name to calculate value if it's not already
set.
Don't you have some specific magic in your app? Could you please see also
Struts logs for any WARN message?
Regards,
Yasser
________________________________________
From: Nate Kerkhofs <[email protected]>
Sent: Friday, November 24, 2023 3:23 PM
To: [email protected]
Subject: Struts 6.3 tags do not automatically evaluate the value field against
the ognl stack
Greetings,
I am currently upgrading a Struts 2.5 project to Struts 6.3, and I ran into an
issue with Struts 6.3 tags not evaluating the value against the ognl stack. I
have reproduced this issue both with the radio map included in the struts2-core
jar and with a custom radiomap.ftl, and also with an s:textfield instead of an
s:radio. In both cases, the value attribute on the source page doesn't get
resolved against the ognl stack, instead using the string literal entered in
the value attribute.
I have about 140 s:radio components formatted like below, with "locked" being a
Boolean field in the Action java controller:
<s:set var="lockedOptionMap" value="#{'true':getText('label.true'),
'false':getText('label.false')}" />
<s:radio label="%{getText('label.projectStream.locked')}"
list="lockedOptionMap" id="locked" name="locked" value="locked" />
In this case, none of the radios with a value set are setting their checked
status based on the boolean value because parameters.nameValue doesn't get
evaluated by ognl. If I remove the value attribute or make it an explicit ognl
expression using %{}, it does resolve the attribute against the ognl stack and
select the right item, but with the code above, the value got resolved against
the ognl ValueStack in 2.5, but that doesn't happen in 6.3. Instead, it just
sets nameValue to "locked" or whatever string literal "value" is set to.
I cannot find any mention of this breaking change in the migration guide,
though I did find an issue dating back to 2007 mentioning a similar problem:
https://issues.apache.org/jira/browse/WW-1907 which means that this either is a
regression or it a deliberate design decision to no longer evaluate this
property against the ognl stack.
Either way, I'd like to know whether this is an intentional change, and if so
what the recommended way is to use a field on the ognl stack to configure the
value of a field: should I add an explicit %{} evaluation symbol around the
value attribute, or should I just leave out the value attribute entirely,
instead relying solely on the name attribute set on the tag?
Kind regards,
Nate Kerkhofs
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
