https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #2 from John Engebretson <jeng...@amazon.com> ---
I think you're right that the letter of step #2 proscribes this change. My
subsequent text in no way attempts to undermine or change that statement.
In the vast majority of cases, when a JSP author uses the value "${true}" and
the property type is Boolean, the author intends Boolean.TRUE. A case that
violates that would be closer to a bug than desired behavior.
In the vast majority of cases, when a JSP author refers to an enum by implicit
name using the value "${'hotFudge'}" and such an enum exists, the author
intends to use that. I can conceive of a situation when centralized code wants
to override all values of 'hotFudge' but that is rare at best, and alternative
solutions exist.
In the vast majority of cases, when a JSP author uses a constant string
"${'constant'}" and the targeted property is a String, they intend the property
to contain the string "constant". Here again I can conceive of a desire to
override all strings with the value "constant" but this would also be rare, and
alternative solutions exist.
Most applications would choose significant efficiency improvements over the
loss of these specific capabilities.
Which leaves us in the situation of a very clear specification versus a very
clear performance win. How can we resolve this? My rough ideas:
1. Provide a configuration flag, in which one value enables these optimizations
and one value maintains strict compliance with the spec. (default value is a
separate question)
2. Fudge the spec, with the argument that the efficiency gains outweigh a few
edge cases.
Thoughts? Thank you!
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
