-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kerry,
On 3/7/12 10:59 AM, ke...@kjaklive.com wrote:
> My issue is with the Expression Language and how a Character object
> is compared to an in-line Character object in order to decide what
> content to display on the web page.
>
> My original comparison code is as follows: <c:if
> test="${program.isGeneralPublicYN == 'N'}"> <!-- Show General
> Public Information --> </c:if>
I'm not that steeped in the EL spec, but it looks like Section 1.3 in
spec 2.2 MR says that there is no such thing as a character literal:
only strings (and others):
"
Literals
There are literals for boolean, integer, floating point, string, and
null in an eval- expression.
■ Boolean - true and false
■ Integer - As defined by the IntegerLiteral construct in Section 1.19
■ Floating point - As defined by the FloatingPointLiteral construct in
Section 1.19
■ String - With single and double quotes - " is escaped as \", ' is
escaped as \',
and \ is escaped as \\. Quotes only need to be escaped in a string
value enclosed
in the same type of quote
■ Null-null
"
The grammar for EL (section 1.19) also defines "StringLiteral" to be
anything between single- or double-quotes.
What if you did something like this:
<c:if test="${program.isGeneralPublicYN == 'N'.charAt(0)}">
<!-- Show General Public Information -->
</c:if>
Or, if you can think of another way to coerce the string "N" to a
character, the spec says that coercing a String to a Character results
in the first character of the string being used.
> It doesn't make much sense that it would convert a referenced
> object, but not an in-line object of the same type. Possibly
> because in-line the compiler has a harder time differentiating a
> one-character string object and a character object?
I think that's the deal: Tomcat takes the character from your object's
property and decides that everything should be coerced to Long, then
tries to coerce your String literal to a Long, which obviously does
not work (there appear to be no rules for coercing String to Number
unless the target type is BigDecimal. It seems ambiguous to me since
there is no "otherwise" in section 1.18.3 when String is being coerced
to something other than BigDecimal.
> It seems a little crazy to have to workaround this issue. I
> shouldn't have to change my code. This greatly increases the amount
> of code changes and testing we have to do in order to move
> applications from Tomcat 6 to 7. If this is a bug in Tomcat 7.0.26
> (x64) then we may hold off on the upgrade. However, if it is not a
> bug, then please explain to me why my original code no longer works
> and the best practices for implementation.
Each version of Tomcat generally becomes more strict when it comes to
spec-compliance. That may be the case, here.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9XphEACgkQ9CaO5/Lv0PCgkACfU83Xxek0aj+kJjrC59UWHwKN
MvcAnAoSKMO7Pby0zeRylOLqdTG3wBPn
=rSTu
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
