I have this JSP EL expression, which uses the >= comparator. On my development environment I get the result you would expect, namely that 2 >= 188 is false. However, on my staging and production servers apparently 2 >= 188 is true.
Here is the code:
</ul>
<p>curPage: ${param.curPage}<br/>
totalPages: ${param.totalPages}<br/>
totalPages - curPage: ${param.totalPages - param.curPage}<br/>
curPage gt totalPages: ${param.curPage >= param.totalPages}<br/>
<p>
On my development environment, I get output like this:
curPage: 2
totalPages: 68
totalPages - curPage: 66
curPage gt totalPages: false
On staging:
curPage: 2
totalPages: 181
totalPages - curPage: 179
curPage gt totalPages: true
My development environment is running Tomcat 7.0.29, staging is running 7.0.30. The codebases are the same.
The above code is in a file “pagination.jsp” (I know, it should be a .tag), which is included into another jsp like this:
<jsp:include page="/widgets/pagination.jsp">
<jsp:param name="totalPages" value="${actionBean.jbp.totalPages}" />
<jsp:param name="baseUrl" value="${baseUrl}" />
<jsp:param name="curPage" value="${not empty param.page?param.page:0}" />
</jsp:include>
“jbp.totalPages” is defined as:
private final int totalPages;
and “param.page” is obviously a page parameter.
I suppose there could be a type conversion problem here, between the parameter and the int, but that does not explain why it works on one machine and not the other.
Also, I thought JSP EL did automatic type conversion.
Any thoughts would be appreciated.
Those params are evaluated as
Stringinstead ofNumber(because that’s basically whatHttpServletRequest#getParameter()returns). A string value of"2"is lexicographically “greater” than any string value starting with"1".You need to parse them as
Number. You can use JSTL<fmt:parseNumber>for this.As to the difference in development versus production environment, this is most likely result of bad testing (not using same test data or maybe even not same test code). There is namely nothing like that changed in Tomcat’s EL implementation across the mentioned versions. Only if one of the hands in the comparison is really a
Numberand the other is aString, then EL will coerce theStringtoLong. This is perhaps what is happening in real code.