我有这个JSP EL表达式,它使用> =比较器。在我的开发环境中,我得到了你期望的结果,即2> = 188是假的。但是,在我的登台和生产服务器上,显然2> = 188是真的。
以下是代码:
</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>
在我的开发环境中,我得到如下输出:
curPage: 2
totalPages: 68
totalPages - curPage: 66
curPage gt totalPages: false
登台:
curPage: 2
totalPages: 181
totalPages - curPage: 179
curPage gt totalPages: true
我的开发环境正在运行Tomcat 7.0.29,暂存正在运行7.0.30。代码库是相同的。
以上代码位于文件“pagination.jsp”(我知道,它应该是.tag),它包含在另一个jsp中,如下所示:
<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”定义为:
private final int totalPages;
和“param.page”显然是一个页面参数。
我想在这里可能存在类型转换问题,在参数和int之间,但这并不能解释为什么它在一台机器上运行而不在另一台机器上运行。
另外,我认为JSP EL进行了自动类型转换。
任何想法都会受到赞赏。
答案 0 :(得分:3)
2 >= 188
为false。
2 >= 188
为真。
您的两个部署中有不同的内容。
查看jstl.jar和standard.jar的版本以及可能在tomcat/lib
目录中的所有jar文件。也许您的代码是相同的,但依赖库中还有其他差异?不知何故,类型不同。不太可能,但不超出可能性范围,JSP中的差异正在影响类型推断。
修改强>:
当问题对两个代码示例使用188(实际上是181)时,回答了这个问题。它已经在一个的示例中更改为69。现在一切都有道理。
答案 1 :(得分:3)
这些参数被评估为String
而不是Number
(因为这基本上是HttpServletRequest#getParameter()
返回的)。字符串值"2"
按字典顺序“大于”以"1"
开头的任何字符串值。
您需要将它们解析为Number
。您可以使用JSTL <fmt:parseNumber>
进行此操作。
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>
...
<fmt:parseNumber var="curPage" value="${param.curPage}" integerOnly="true" />
<fmt:parseNumber var="totalPages" value="${param.totalPages}" integerOnly="true" />
...
<p>
curPage: ${curPage}<br/>
totalPages: ${totalPages}<br/>
totalPages - curPage: ${totalPages - curPage}<br/>
curPage gt totalPages: ${curPage >= totalPages}<br/>
</p>
至于开发与生产环境的差异,这很可能是测试不良的结果(不使用相同的测试数据,甚至可能不是相同的测试代码)。在所提到的版本中,Tomcat的EL实现中没有任何改变。只有当比较中的一只手真的一个Number
而另一只手是String
时,EL才会将String
强制转换为Long
}。这可能是真实代码中发生的事情。