开放原子开发者工作坊

How to Reference and Use JSTL in your Web Application

 

As a frequent contributor to the Spring Framework user forums, I have noticed a common trend among people new to Spring MVC – they really don’t understand how to use JSTL and EL in their Spring-driven JSPs.

Although Spring MVC supports flexibility in choosing a view technology, in my [back of the napkin] estimate, at least 80% of the time it is paired with JSP and JSTL. Unfortunately, since JSP was pushed out about 4-5 years ago, a lot of the information that you find on the web is extremely dated, often going back to JSTL 1.0 syntax (or, gasp, using scriptlets!). In this article I’ll clear up the confusion around how to use JSTL with various app servers and webapp versions.

Since JSP implementation and support varies widely among app server vendors (and versions of an app server), a lot of Spring MVC newbies get stuck just getting simple JSTL expressions to work. Since Spring relies on JSTL EL expressions for output of bound fields (assuming you’re not using the form taglibs), people often wrongly assume that something is wrong with Spring when their Spring-bound data doesn’t show up on the page.

Here’s a hint: if you can’t get a simple (non-Spring-related!) expression like ${2+2} to work, no expressions will work! (In a properly functioning servlet container, the prior expression should output “4″ on the page).

I set out to take some common application server configurations, combine them with various flavors of JSP/JSTL support, and see what happened.

The Importance of Servlet Version and web.xml

Let us review the following reference table:

JSP/Servlet Version

Servlet Version	JSP Version	JSTL Version	Java EE Version
2.5	2.1	1.2	5
2.4	2.0	1.1	1.4
2.3	1.2	1.0	1.2

 

What Does this mean to me?

The most important thing is to figure out what version of the Java EE web stack (Servlet/JSP) you are using. There are 2 aspects that factor into this:

• What version of Java EE / servlet spec does your servlet container support?
• What version of Java EE / servlet spec have you declared in your deployment descriptor (web.xml)?

Here’s an example of what to look for in web.xml:

<?xmlversion="1.0"encoding="UTF-8"?><web-appxmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"id="WebApp_ID"version="2.5"><display-name>web-app-25</display-name> ... </web-app>

You can see the ‘version=”2.5″‘ designation in here. This means that within this web application, we will be able to use JSP 2.1 and JSTL 1.2 features.

OK, How do I use JSTL in my Page?

A very common problem that I have seen with new Spring users is that they don’t understand how to reference the JSTL tag libraries on their pages. Important!: You need to identify the version of web application you are using first.

Web Application v2.5 and v2.4

To use EL Expressions: You do not need <c:out>. Simply insert EL expressions onto the page: ${2+2}
To use JSTL tag libraries (c, fmt, etc): Reference as follows:

<%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

Web Application v2.3

To use EL Expressions: You do need <c:out>. Raw EL expressions on the page will not work. e.g. <c:out value=”${2+2}”>
To use JSTL tag libraries (c, fmt, etc): Reference as follows:

<%@taglib prefix="c" uri="http://java.sun.com/jsp/core" %>

What about the _rt Taglibs Like core_rt?

The following type of URI will also work, in JSTL 1.2 and 1.1:

<%@taglib prefix="c" uri="http://java.sun.com/jstl/core_rt" %>

However, this is not desired. You should never have to reference the _rt versions of taglibs (e.g. core_rt).

Do I need to include a JSTL Implementation with my Web Application?

Obviously, there are a lot of application servers out there. I tested this with the following:

• Tomcat 6.0
• Tomcat 5.5
• Tomcat 5.0
• JBOSS 4.2
• Glassfish 2

Of these, JBOSS and Glassfish ship with JSTL implementations out of the box. Tomcat does not ship with a JSTL implementation. I have previously blogged about this here.

I did not test other application servers, simply because these are the ones I most commonly see referenced in the Spring forums. Websphere is also used, but I didn’t have access to it (and, frankly, didn’t want to spend the 8 hours and tens of gigs of downloads it would take to install it  ).

Testing Methodology

For those who are interested, here’s the testing methodology I used to come to the conclusions above.

I created 6 web applications. The 6 web applications are as follows:

• webapp-25: Servlet version 2.5 declared in web.xml, JSTL RI not included in WEB-INF/lib
• webapp-25-jstlri: Servlet version 2.5 declared in web.xml, JSTL 1.2 RI included in WEB-INF/lib
• webapp-24: Servlet version 2.4 declared in web.xml, JSTL RI not included in WEB-INF/lib
• webapp-24-jstl11: Servlet version 2.4 declared in web.xml, JSTL 1.1 RI included in WEB-INF/lib
• webapp-23: Servlet version 2.3 declared in web.xml, JSTL RI not included in WEB-INF/lib
• webapp-23-jstl10: Servlet version 2.3 declared in web.xml, JSTL 1.0 RI included in WEB-INF/lib

In each web application, I created 4 JSP pages with the following content:

  Some simple math: ${2+2}   <br/>   Some simple math with c:out: <c:out value="${2+2}"/>   <br/>   Some simple math with c2:out: <c2:out value="${2+2}"/>   <br/>

You can see there are 3 tests in the page. The goal of the tests are as follows:

1. ${2+2}: does inline EL evaluation work with this webapp version?
2. <c:out value=”${2+2}”/>: is the ‘c’ namespace automatically provided by the container?
3. <c2:out value=”${2+2}”/> is the ‘c2′ namespace explicitly provided by the given taglib declaration? (see next section for how the c2 taglib is declared)

For each of the 4 JSP pages, I varied how the JSTL core taglib was declared:

• test_no_taglib_decl.jsp: Contained no taglib declarations at all
• test_c2_jsp_jstl_core_taglib_decl.jsp: Contained the taglib declaration:

  <%@taglib prefix="c2" uri="http://java.sun.com/jsp/jstl/core" %>

• test_c2_jstl_core_taglib_decl.jsp: Contained the taglib declaration:

  <%@taglib prefix="c2" uri="http://java.sun.com/jstl/core" %>

• test_c2_jstl_core_rt_taglib_decl.jsp: Contained the taglib declaration:

  <%@taglib prefix="c2" uri="http://java.sun.com/jstl/core_rt" %>

In a typical scenario where the container supports JSP 2.0+, what you would expect to see is the following:

Some simple math: 4
Some simple math with c:out:
Some simple math with c2:out: 4

What Happens if You Have the Wrong Declarations

Some of the errors you may get if you don’t have things declared right:

On Tomcat
Declaring the wrong taglib:

org.apache.jasper.JasperException: /test_c2_jstl_core_taglib_decl.jsp(11,32) According to TLD or attribute directive in tag file, attribute value does not accept any expressions
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407)

No JSTL implementation:

org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)

org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)

On JBOSS

Since JBOSS also uses the Apache Jasper JSP compiler, the errors are basically exactly the same as those listed above.

On Glassfish

org.apache.jasper.JasperException: /test_c2_jstl_core_taglib_decl.jsp(11,32) PWC6236: According to TLD or attribute directive in tag file, attribute value does not accept any expressions