tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat 7.0.26 Expression Language Issue when Comparing Character Objects
Date Wed, 07 Mar 2012 18:16:49 GMT
Hash: SHA1


On 3/7/12 10:59 AM, 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):

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 -->

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
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message