Why JSTL — and how to install it today

Stage 2 · Topic 2 - JSP · Session 5: JSTL Introduction

Slides 4-10 — installing JSTL, the three installation steps, and the conclusions of the introduction.

What the slides say, and what has changed

The slides describe installing JSTL into Tomcat itself:

  1. copy the JSTL JAR files into Tomcat's lib directory
  2. copy the eight JSTL .tld files into Tomcat's WEB-INF directory
  3. add an entry for all eight tag libraries to web.xml
Do not do that today. Those steps come from the Tomcat 4 era (the slide even says C:\Program Files\Apache Tomcat 4.0) and they modify the server so that every application on it inherits the library. On a modern container it is wrong for two reasons:
  • It is a security problem. Anything placed in Tomcat's lib folder is loaded into every web application running on that server, including applications you did not write and do not trust.
  • It does not deploy with the application. A colleague who runs your WAR file on their own Tomcat will not have your copy.

What this project does instead

JSTL is placed in the application itself:

jsp-demo/
  WebContent/
    WEB-INF/
      lib/
        jstl-1.2.jar     <-- the whole library, API + implementation + TLDs

and that is the entire installation. Nothing in Tomcat's directories is touched, and no taglib entries are needed in web.xml for JSTL, because the container scans every jar in WEB-INF/lib for .tld files and registers the libraries it finds automatically.

The taglib URI you write in a page

<%@ taglib prefix="c"   uri="http://java.sun.com/jsp/jstl/core" %>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt"   %>
<%@ taglib prefix="x"   uri="http://java.sun.com/jsp/jstl/xml"   %>
<%@ taglib prefix="fn"  uri="http://java.sun.com/jsp/jstl/functions" %>
The http://java.sun.com/... URIs in the slides are correct and current for JSTL 1.2 — they are just names, not addresses, and nothing is downloaded from the internet. They only became jakarta.tags.core etc. in JSTL 2.x, which belongs to the jakarta.servlet generation of Tomcat (10.1 and later).
Which generation is this course on? The examples here use javax.servlet.jsp.tagext.TagSupport and the http://java.sun.com/jsp/jstl/... URIs, because that is what the slides use and because the installed server is Tomcat 9, which is a javax container. If you move to Tomcat 10.1 or 11, change the imports to jakarta.servlet.jsp.* and the taglib URIs to jakarta.tags.* — nothing else about the syntax of JSP changes.

Conclusions (slides 9-10)

JSTL allows a more consistent programming environment by expressing both HTML and procedural code as tags. It does not give you everything a full-featured web application needs, and some things that can be done in JSTL are best not done there.

The perfect example is the database JSTL tags: except for very small web applications, embedding actual database commands into a JSP page is generally considered bad programming practice. The proper location for such code is in Java beans and EJBs used by the application. For routines that occur on many pages, consider creating your own tag library.

In other words: use JSTL for the basic, non-business-specific programming of your pages; put the business logic in beans; and implement the components that are unique to your business in your own tag libraries — which is exactly what Session 3 and Session 7 demonstrate.

← Back to the example index