tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Tomcat 7.0.26 Expression Language Issue when Comparing Character Objects
Date Wed, 07 Mar 2012 15:59:48 GMT
Hello. I have been testing a Java Web Application to upgrade from Tomcat
6.0.32 (x86) to Tomcat 7.0.26 (x64). I am using Java 6 update 31. I have
also tried pointing Tomcat 7.0.26 (x64) to Java 7 Update 3 and
experience the same issue.

Windows 7 x64
IDE is Netbeans 7.0.1
Tomcat 7.0.26 x64
Java 6 update 31
Spring MVC 2.5.6
JSTL 1.1

I have come across an issue with existing code in the application. This
code has been in production using Tomcat 6.0.32 (x86) for over 1 year
and has not had a problem.

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

Where program is a Program object and isGeneralPublicYN is a char
property of the program object.

When I access this page running on Tomcat 7.0.26 (x64), I receive the
following error:
 javax.el.ELException: Cannot convert N of type class
java.lang.String to class java.lang.Long

I started looking around and found the following in section 1.8.1 of the
Expression Language Specification Version 2.2 Maintenance Release
A {<,>,<=,>=,lt,gt,le,ge} B
■ If A==B, if operator is <=, le, >=, or ge return true.
■ If A is null or B is null, return false
■ If A or B is BigDecimal, coerce both A and B to BigDecimal and use
the return
value of A.compareTo(B).
■ If A or B is Float or Double coerce both A and B to Double apply
■ If A or B is BigInteger, coerce both A and B to BigInteger and use
the return
value of A.compareTo(B).
Chapter 1 Language Syntax and Semantics 13
■ If A or B is Byte, Short, Character, Integer, or Long coerce both A
and B to
Long and apply operator
■ If A or B is String coerce both A and B to String, compare lexically
■ If A is Comparable, then:
■ If A.compareTo(B) throws exception, error.
■ Otherwise use result of A.compareTo(B)
■ If B is Comparable, then:
■ If B.compareTo(A) throws exception, error.
■ Otherwise use result of B.compareTo(A)
■ Otherwise, error

I am particularly interested in the following line of logic:
■ If A or B is Byte, Short, Character, Integer, or Long coerce both A
and B to
Long and apply operator

The expression I am evaluating appears to meet the requirements here.
program.isGeneralPublicYN is a Character object. It is being converted
to a Long as the specification states. However, my in-line variable
('N') is not being converted to a Long, but is instead being converted
to a String.

Am I reading the specification wrong? Since program.isGeneralPublicYN is
a Character, shouldn't EL convert both sides to a Long for the
comparison? Was this implemented incorrectly in Tomcat 6.0.32 (x86) and
corrected in Tomcat 7.0.26 (x64)?

I have identified 2 workarounds for this issue:
(1) Since it is a character, I can use the EL Function "contains" for
the comparison
<c:if test="${fn:contains(program.is_general_public_yn, 'N')}"> 
 <div class="sub_question">Please explain:</div><br /> 
 <c:out value="${program.general_public_explain}" /> 
 <br /><br /> 

(2) I can pass a character to the page via the reference map in the
controller to the page and then do the comparison on that object instead
of doing it in-line

Map refData = new HashMap();
refData.put("charN", 'N');

<c:if test="${program.isGeneralPublicYN == charN}">
 <div class="sub_question">Please explain:</div><br />
 <c:out value="${program.general_public_explain}" />
 <br /><br />

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?

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.

I appreciate your time looking into this concern and I hope to hear from
the community in the near future regarding this matter. Thank you,


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

View raw message