WASv6.0 - JSTLv1.1 problems

[Troy Chung]

Hi, Need advise on the following problem faced by our customer in
WASv6.0. Currently, customer is using Tomcat 5.0 and migrating to WASv6.0.
Customer's applications uses quite a lot of JSTL v1.1. This version of
JSTL requires JSP2.0, Servlet 2.4 to work as it uses _Expression
Language (EL). However, when tried to migrate application from Tomcat to
WASv6.0, we found that certain JSTL functions do not work. As an
example, a JSTL application downloaded from Apache, which is attached.
When this application is deployed to WASv6.0 and accessed using
http://localhost:9080/standard-examples/functions/Length.jsp

the following error is shown :

[29/07/05 13:38:06:455 SGT] 00000037 ServletWrappe E SRVE0014E:
Uncaught service() exception root cause /functions/Length.jsp:
javax.servlet.jsp.el.ELException: No function is mapped to the name
"fn:indexOf"

However, the application works fine in Tomcat 5.0. If you look at the
Length.jsp file attached, the error is due to this line:
<c:when test="${fn:indexOf(customer.address.country,'U') <= 0}">

If you notice, this line is in another loop. When this line is taken out
of the loop, it works!

We belive it is a WASv6.0 error, because from the log file, the error
can be traced back to the compiled JSP file :

[29/07/05 13:38:06:455 SGT] 00000037 ServletWrappe E SRVE0014E:
Uncaught service() exception root cause /functions/Length.jsp:
javax.servlet.jsp.el.ELException: No function is mapped to the name
"fn:indexOf"
at org.apache.commons.el.Logger.logError(Logger.java:481)
at org.apache.commons.el.Logger.logError(Logger.java:498)
at org.apache.commons.el.Logger.logError(Logger.java:525)
at
org.apache.commons.el.FunctionInvocation.evaluate(FunctionInvocation.java:150)
at
org.apache.commons.el.BinaryOperatorExpression.evaluate(BinaryOperatorExpression.java:154)
at
org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:263)
at
org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:190)
at
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:720)
at com.ibm._jsp._Length._jspx_meth_c_when_0(_Length.java:144)
at com.ibm._jsp._Length._jspx_meth_c_choose_0(_Length.java:196)
at
com.ibm._jsp._Length._jspx_meth_c_forEach_0(_Length.java:229)
at com.ibm._jsp._Length._jspService(_Length.java:102)

Note: Applied WASv6.0 latest patches.

This is quite urgent .Thanks.

Troy Chung,
TroyTech International
Singapore

[Paul Ilechko]

Troy Chung wrote:

> This is quite urgent .Thanks.

This is *not* a support forum. If you have an urgent problem that you
believe is a WAS bug, you should open a PMR.

[Troy Chung]

Paul,

Thanks, and we will try to apply PMR at the same time.

By the way, can anyone tell us if WAS 6.0 support JSTL v1.1 or not!? Thanks!

Troy Chung, TroyTech International Consulting.

[Paul Ilechko]

Troy Chung wrote:

> Paul,
>
> Thanks, and we will try to apply PMR at the same time.
>
> By the way, can anyone tell us if WAS 6.0 support JSTL v1.1 or not!?
> Thanks!

It supports Servlet 2.4 & JSP 2.0, if that's what you mean. It all
supports JSF, and therefore provides JSTL in the application server
runtime. You may be getting classloader issues between the WAS JSTL
implementation & an external one.

From the infocenter:

"The specification related classes (javax.faces.*) for JSF is packaged
in a JAR file called jsf-api.jar. The IBM modified version of the JSF
Sun reference implementation is packaged in a JAR file called
ws-jsf.jar. The dependency on JavaServer Pages Standard Tag Library
(JSTL) requires that its JAR files, (jstl.jar and standard.jar), are
available, therefore they need to be available in the Application Server
runtime. The jstl.jar and standard.jar files reside in the lib directory
of the WebSphere Application Server install image. You must copy the JSF
JAR files to the standard Application Server runtime directory.

Typically Web applications that leverage this API/Framework embed the
JSF API and implementation JAR files within their WAR file. This is not
required when these Web applications are deployed and run within
WebSphere Application Server 6.0. Only the removal of these jars along
with any JSTL JAR files from the WAR file is required.

If a Web application requires the use of its own version of JSF or JSTL
embedded within it, you can change the class loader mode of the Web
application. By default this is set to PARENT_FIRST mode. Changing this
value to PARENT_LAST allows the Web application version of the JSF or
JSTL classes to load before the WebSphere 6.0 version."

- if you are providing JSTL in your WAR I would recommend removing it,
and seeing if that helps. If not, try switching to PARENT_LAST.

[cam...@gmail.com]

Hi Troy,

We had the same problem when trying to use the fn:length function. With
a bit of luck we managed to find a workaround for it, which was a
matter of finding just the right combination of tags to coerce
websphere to work.

Our problem fragement was
<c:if test="${fn:length(quote.otherDrivers)==0}">

We found that if we put
<c:set var="xx" value="${fn:length(param)}"/>
before our problem tag, then websphere would be happy and understand
what fn:length is. Basically the trick is get the expression you have
in a c:if tag, without the boolean test, and put it in a c:set tag.

I've tested the same thing with your expression, so before your <c:if>
tag wite
<c:set var="x" value="${fn:indexOf('asdf','U')}"/>
and presto, you page should work!

Daniel Campagnoli