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
Hibernate
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 -->
</c:if>
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
(http://download.oracle.com/otn-pub/jcp/expression_language-2.2-mrel-eval-oth-JSpec/expression_language-2_2-mrel-spec.pdf)
=>
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
operator
■ 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 />
</c:if>
(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 />
</c:if>
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,
--Kerry--
http://www.kjaklive.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
