JSTL SQL & XML (Legacy)

The Standard Tag Library has five libraries. Three of them (core, formatting and functions) are the everyday tools of a page author; the other two reach outside the view layer. The table lists them as the specification and the tag library descriptors of the implementation define them.

Source: Jakarta Standard Tag Library 3.0 — 10 SQL Actions

Source: Jakarta Standard Tag Library 3.0 — 11 XML Core Actions

The old Sun URIs http://java.sun.com/jsp/jstl/sql and http://java.sun.com/jsp/jstl/xml are still accepted by the 3.0.1 implementation on Tomcat 11 (a page that declares them runs; checked), but the URIs of JSTL 3.0 are the jakarta.tags.* ones, and only those are used on this page. The JSTL 1.0 URIs http://java.sun.com/jstl/sql and the _rt twin libraries of the older books are another matter, covered in Where the Books Are Outdated.

The examples use one scratch web application with Maven coordinates as follows. The Jakarta APIs are provided (Tomcat supplies them), the JSTL API and implementation travel in WEB-INF/lib, and the database driver is a runtime dependency. H2 in memory stands in for a real database; nothing on this page depends on it except the exact wording of its error messages.

Source: Jakarta Standard Tag Library 3.0 — specification page

The data source is declared the way a real deployment would declare it: a Resource in META-INF/context.xml (Tomcat creates a pooled javax.sql.DataSource and binds it in JNDI as java:comp/env/jdbc/bookshelf), and two context parameters in web.xml that are the JSTL configuration variables of the SQL library. The user name and password below are placeholders; a real application takes them from the environment or a secret store, never from a page.

Source: Apache Tomcat 11 — JNDI Datasource How-To, DBCP 2 configurations

Source: Apache Tomcat 11 — The Context Container, resource definitions

Source: Jakarta Standard Tag Library 3.0 — 2.8 Configuration Data

Source: H2 — in-memory databases

A throwaway setup.jsp creates and fills the two tables (a book and the number of copies on each of two shelves). It already uses most of the tags described below, which is why it comes first: DDL through sql:update, a transaction around several statements, parameters for every value and sql:dateParam for a date. The fmt: tags only produce the date and are described on the JSTL Formatting page of this section.

Source: Jakarta Standard Tag Library 3.0 — 10.4 sql:update

curl http://localhost:18080/g5jstlsqlxml/setup.jsp prints inserted 1: Dune (1 row) through inserted 5: Hyperion (1 row) and done. The page is a setup script, not a design: it may be called by anyone who can reach the URL and it drops the tables, which is the first reason it must never ship.

Every SQL tag that talks to a database needs a javax.sql.DataSource, and the same algorithm finds it for sql:query, sql:update and sql:transaction. The specification (10.2) gives the steps, and the diagram follows them.

The value can therefore be given in five ways. The page datasource.jsp uses all of them in turn against the same database.

The tag is empty (no body), and a null dataSource is a JspException.

Source: Jakarta Standard Tag Library 3.0 — 10.6 sql:setDataSource

Source: Jakarta Standard Tag Library 3.0 — 10.2 Database Access

Source: Jakarta Tags 3.0 tagdocs — sql:setDataSource

The output shows what each form does, including the surprising last two cases (line 5 is another empty in-memory database, and line 6 shows the message for a name that is neither a JNDI resource nor a JDBC string):

Case 5 is the pitfall: sql:setDataSource without var replaces the configuration variable for the page scope, so every later tag of the page that has no dataSource attribute uses the new database, whatever web.xml says. A JNDI name that is not bound is not reported as "name not found": the algorithm falls through to the JDBC parameter string, and the error is the one from DriverManager. The helper tags are also scoped by scope: a sql:setDataSource with scope="application" in a page changes the data source of every page that runs afterwards (verified: after one request to such a page, an unrelated page that has no dataSource attribute failed with the other database’s "Table not found"; the application had to be redeployed), which is another reason to configure it once, in web.xml or in Java.

Two rules close the section. First, the parameter string and the four JDBC attributes put a user name and a password into a page: use them only on a laptop with a throwaway database and a placeholder account, and never commit a real password into a JSP, a web.xml or a context.xml that is under version control. Second, a JDBC driver in WEB-INF/lib of a web application is registered with DriverManager and not unregistered by the container on undeploy: Tomcat logs a warning that the application "registered the JDBC driver [org.h2.Driver] but failed to unregister it" when the scratch WAR is redeployed, and the Tomcat JNDI how-to has a section on the service provider mechanism and memory leaks that recommends putting the driver in the server’s lib directory for container-managed pools.

sql:query runs a SELECT and stores a jakarta.servlet.jsp.jstl.sql.Result in var. It has three syntaxes, which differ only in where the statement and the parameters come from.

Syntax 1 is <sql:query sql="..." var="r"/> (no body); syntax 2 puts only sql:param actions in the body; syntax 3 puts the statement text and then the sql:param actions in the body, which the container evaluates and the tag trims. If the query returns nothing, var holds an empty Result, not null. Any SQLException is rethrown as a JspException whose message includes the SQL statement and whose cause is the original exception.

The Result interface has five properties, all readable from EL:

Source: Jakarta Standard Tag Library 3.0 — 10.3 sql:query

Source: Jakarta Tags 3.0 API — Result

Source: Jakarta Tags 3.0 tagdocs — sql:query

The page query.jsp lists the books ordered by year, skipping the first row and keeping three. It prints the same rows three ways: the counters, a table built from columnNames and rowsByIndex (no column is named in the page), and a list that uses rows with the case-insensitive keys.

Source: Jakarta Standard Tag Library 3.0 — 10.1.2 Querying a Database

The books sorted by year are Foundation (1951), Solaris, Dune, Neuromancer and Hyperion; startRow="1" dropped Foundation, so the first row shown is Solaris. Every value is printed through c:out, because a database column is untrusted text (see Escaping What Comes from the Database).

A statement may contain ? markers; every marker is filled, in order, by a nested sql:param or sql:dateParam. The values travel as JDBC PreparedStatement parameters, so the database never parses them as SQL. Both tags locate their nearest ancestor that implements jakarta.servlet.jsp.jstl.sql.SQLExecutionTag (sql:query and sql:update do) and call its addSQLParameter() method, which is also the extension point for custom parameter tags.

Source: Jakarta Standard Tag Library 3.0 — 10.7 sql:param

Source: Jakarta Standard Tag Library 3.0 — 10.8 sql:dateParam

Source: Jakarta Standard Tag Library 3.0 — 10.1.4 SQL Statement Parameters

Source: Jakarta Tags 3.0 API — SQLExecutionTag

The page param.jsp runs the same search twice, once with a parameter and once with the request value concatenated into the statement by EL. The second form is the vulnerable "before" snippet; it is shown so the difference can be seen, and it is never to be used.

Source: Jakarta Standard Tag Library 3.0 — 10.3 sql:query (syntax 3, query with optional parameters)

Source: OWASP — SQL Injection Prevention Cheat Sheet, primary defenses

With a normal value both forms agree. With q set to x' OR '1'='1 (sent as a URL-encoded query parameter) the result differs:

The parameter form found nothing, because no book has that literal title; the concatenated form returned every book, because the EL expression was replaced by text before the statement reached the driver and the OR '1'='1' became part of the SQL. (A second attempt with x' OR 'a shows the other symptom, a JspException whose cause is the database error with the statement in it: Data conversion error converting "CHARACTER VARYING to BOOLEAN".) The specification’s examples are safe: its money transfer example uses markers. The rule is mechanical: no ${...} inside the SQL text, only in value attributes. A value that cannot be a parameter, such as a table or column name chosen by the visitor, is never taken from the request: it is looked up in a fixed list of allowed names in a servlet.

sql:update runs an INSERT, UPDATE or DELETE, and also any statement that returns nothing, such as DDL. Its syntaxes mirror sql:query: the statement in sql, or in the body, with sql:param actions.

The result is the same number Statement.executeUpdate() returns: zero for a statement that matched nothing and for every DDL statement. The page errors.jsp checks this and some other edges in one place.

Source: Jakarta Standard Tag Library 3.0 — 10.4 sql:update

Source: Jakarta Tags 3.0 tagdocs — sql:update

Three details are worth remembering. A null parameter value became SQL NULL (the page printed true for empty nul.rows[0].v). A maxRows below -1 is rejected with the tag’s own message, and a failing statement reports its text first, which is why the message of a JspException from these tags must never be shown to a visitor. And each sql:update that is not inside sql:transaction obtains its own connection, runs, and releases it before the tag ends (the specification requires every database action to close what it opened), so on an auto-commit connection each statement is its own transaction: two separate updates are not atomic.

sql:transaction provides one connection to the sql:query and sql:update actions nested in its body, turns auto-commit off, and commits when the body ends or rolls back if an exception escapes. Its attributes are dataSource (as before) and isolation.

The life cycle given by the specification is: at the start, read the current isolation level (a value of TRANSACTION_NONE means transactions are not supported and the action fails), save and disable auto-commit, and set the requested isolation level if it differs; at the end call commit(); on an exception call rollback() and rethrow; and in every case restore the saved isolation level and auto-commit mode and close the connection. Three rules follow from it: the nested sql:query and sql:update must not specify dataSource; transactions cannot be nested to share a connection; and executing a SQL statement such as rollback with sql:update inside the body is not supported (the result is unpredictable). Its behaviour inside a larger JTA user transaction is undefined.

The Bookshelf transfers copies of Dune from the main shelf to the annex. The two updates are one transaction; the first one adds copies to the annex and the second removes them from the main shelf, where the CHECK (copies >= 0) constraint rejects an impossible quantity. The output of the second request shows that the first update, which had succeeded, was rolled back.

Source: Jakarta Standard Tag Library 3.0 — 10.5 sql:transaction

Source: Jakarta Standard Tag Library 3.0 — 10.1.3 Updating a Database

Source: Jakarta Tags 3.0 tagdocs — sql:transaction

After the failed request ANNEX is still 2, not 7: the + 5 on the annex was rolled back with the failed - 5. The JspException that c:catch stored has the SQL exception as its cause, and the SQL text is part of the message, again.

Giving a dataSource to a tag inside the transaction is not a run-time error: the tag library validator of the SQL library rejects the page when it is translated, which is better:

Source: Jakarta Standard Tag Library 3.0 — 10.5 sql:transaction (constraints)

A transaction made of tags in a page also lives only as long as the page; it cannot span two requests, so the classic "read, show a form, write" cycle with a version check needs the optimistic locking of a real data layer (the Hibernate pages in this repository have a transactions page and the SQL transactions page describes the isolation levels themselves).

Everything in a Result is data to be treated as untrusted. A title that contains markup is printed unchanged by a bare ${...} and escaped by c:out. The page xss.jsp inserts such a title through a parameter and prints it both ways.

Source: Jakarta Standard Tag Library 3.0 — 10.7 sql:param

Source: OWASP — Cross Site Scripting Prevention Cheat Sheet

The injection safety of sql:param and the output safety of c:out are two different protections, and a page needs both: the first keeps the visitor’s text from becoming SQL, the second keeps the database’s text from becoming HTML.

The SQL library reads two configuration settings (spec 10.9). Each can be set as a context parameter in web.xml (String values only) and overridden for one scope (page, request, session or application) by a configuration variable, which sql:setDataSource and the Config class write from a page or from Java; Config.find looks a setting up by its context-parameter name.

Source: Jakarta Standard Tag Library 3.0 — 10.9.1 DataSource

Source: Jakarta Standard Tag Library 3.0 — 10.9.2 MaxRows

Source: Jakarta Tags 3.0 API — Config

The web.xml of the scratch application sets both: the first line of datasource.jsp case D worked without any attribute because of the first, and the cfg query of errors.jsp is bounded by the second. The jakarta.servlet.jsp.jstl.fmt.* variables of the formatting library follow the same rules and are described with it.

The replacement for sql:* is the structure the specification recommends: the page prints, a servlet (or a service behind it) queries. The Bookshelf servlet BooksServlet gets the container’s data source through @Resource, runs a prepared statement, puts a list of records in the request and forwards to a page that has no SQL.

Source: Jakarta Standard Tag Library 3.0 — 10 SQL Actions (the MVC preference)

Source: Apache Tomcat 11 — JNDI Datasource How-To

Source: OWASP — SQL Injection Prevention Cheat Sheet, primary defenses

The servlet is longer than the tag, and that is the trade: it can be tested without a container, reused by a REST endpoint, traced, given a read-only account, and changed without touching the page. Serious projects go one step further and replace the hand-written JDBC with a data layer: the Hibernate pages of this repository (getting started with Hibernate) and the Spring Data JPA page show the options. The mapping from the old tags to the modern code is straightforward:

The XML tags are built on XPath 1.0, and the specification is careful about how XPath coexists with EL. XPath is a separate language used only in the select attribute of the XML tags; everything else on the page is EL and JSP.

Source: Jakarta Standard Tag Library 3.0 — 11.1.1 XPath Context

Source: Jakarta Standard Tag Library 3.0 — 11.1.5 The select Attribute

Source: Jakarta Standard Tag Library 3.0 — 11.1.6 Default Context Node

Source: W3C — XPath 1.0

The XML tags take documents as a String or a Reader; they do not open URLs. The specification routes URL access through c:import (11.1.7), and relative systems identifiers through the systemId attribute. There are four ways to get text to x:parse, and on Tomcat 11 with JSTL 3.0.1 one of the obvious ones does not work for static files.

The cause is in the implementation: the response wrapper that c:import hands to the included resource has an output stream whose flush() copies what was written into the page’s JspWriter and then clears it; a static file served by Tomcat’s default servlet is written to that stream and flushed, which is consistent with what was observed: the text goes to the page and var is empty. A JSP or a servlet that uses a Writer is not affected, which is why c:import of a dynamic URL works, and why the examples on this page use the body form. This was verified on 2026-10-08 on Tomcat 11.0.26 with JSTL 3.0.1 for var, for varReader and for a file outside WEB-INF; it is recorded as an inconsistency with the specification, which says c:import "works seamlessly with the XML tags". The XSLT stylesheet below (a static file too) is imported through a one-line JSP wrapper, catalog-xsl.jsp, that includes it.

Source: Jakarta Standard Tag Library 3.0 — 11.1.7 Resources Access

(The failing cases also write the XML declaration of the file into the page, which is the leak described above; it is not shown in the output.) For remote documents, c:import of an absolute URL with var works, because the text is read with a reader (see A Remote Feed, the Classic Use).

x:parse parses a document and saves the result. It does not validate against a DTD or schema.

An empty or null source is an exception. var and varDom are alternatives: one of them is required.

Source: Jakarta Standard Tag Library 3.0 — 11.2 x:parse

Source: Jakarta Tags 3.0 tagdocs — x:parse

Source: Jakarta Standard Tag Library 3.0 — 11.1.8 Core Actions

x:out writes the string value of an XPath expression to the page, and x:set stores the result in a scoped variable. They are the XPath counterparts of c:out and c:set.

Source: Jakarta Standard Tag Library 3.0 — 11.3 x:out

Source: Jakarta Standard Tag Library 3.0 — 11.4 x:set

Source: Jakarta Tags 3.0 tagdocs — x:out

Source: Jakarta Tags 3.0 tagdocs — x:set

The page xml-basic.jsp shows both, plus the flow tags of the next section. This is its first half.

Source: Jakarta Standard Tag Library 3.0 — 11.3 x:out

Source: Jakarta Standard Tag Library 3.0 — 11.1.4 XPath to Java Type Mappings

Three observations follow from the output. x:out escapes by default (the title Foundation & Empire appears as & in the HTML) and escapeXml="false" prints it raw, which is only safe for trusted XML. A number result is a Double, so count() prints 3.0 through EL; use number() and a formatting tag, or an integer conversion, where an integer is wanted. And a node-set stored by x:set (dune) can be used as the start of later paths ($dune/author).

The flow tags are the XPath versions of c:if, c:choose and c:forEach; the test expression is evaluated by XPath and converted to a boolean as the boolean() function does (a number is true unless zero or NaN; a node-set is true if it is non-empty; a string is true if it is not empty).

Source: Jakarta Standard Tag Library 3.0 — 12.2 x:if

Source: Jakarta Standard Tag Library 3.0 — 12.3 x:choose

Source: Jakarta Standard Tag Library 3.0 — 12.4 x:when

Source: Jakarta Standard Tag Library 3.0 — 12.5 x:otherwise

Source: Jakarta Standard Tag Library 3.0 — 12.6 x:forEach

Source: Jakarta Tags 3.0 tagdocs — x:forEach

The second half of xml-basic.jsp uses all of them, with a request parameter as an XPath variable.

Source: Jakarta Standard Tag Library 3.0 — 12.6 x:forEach

Source: Jakarta Standard Tag Library 3.0 — 12.2 x:if

Source: Jakarta Standard Tag Library 3.0 — 12.3 x:choose

The first line of the output is wrong, and it is the most useful lesson of this page. The loop has begin="1" end="3" step="2", so it visits the books at index 1 (Neuromancer) and 3 (The Great Gatsby); varStatus reports index 1 and 3 correctly, and $b/price (path from the loop variable) is right, but the relative path title printed Foundation & Empire for the first iteration, the book at index 2. The relative XPath is evaluated against a context node that is one step ahead of var whenever step is greater than one. A second page, xml-loop.jsp, reproduced it without begin and end:

Source: Jakarta Standard Tag Library 3.0 — 12.6 x:forEach (the context node is the node exposed by var)

The specification says the context node is "the node whose representation would be exposed by var (whether or not the var attribute is specified)". On Tomcat 11.0.26 with JSTL 3.0.1 this holds without step (the plain loop printed Dune | Dune | 1 and so on) and not with step above 1, so the workaround is to name the loop variable and write paths from it ($b/title, $b/@id) in any loop that uses step or begin; it is also the style that stays readable.

The other flow-control results: x:if select="$catalog//book[@year < 1930]" is true (the 1925 book) and its var holds true; x:choose skipped the empty fantasy test and took the second x:when; the last loop used $param:genre and a request with ?genre=scifi listed three books. Two things about that XPath: the < in the first select is written unescaped, because in the standard (non-XML) JSP syntax an attribute value is not an XML text and < would be passed to XPath as four literal characters and fail ("Expected ], but found: <"); in a JSP document (XML syntax) it has to be escaped (see the JSP documents page). And a request without the genre parameter is an exception, not an empty list:

The variable namespaces still use the old java.sun.com URIs inside the XPath engine; that is an implementation detail and not something a page writes.

The scope variables of the table in The XML Library: XPath as a Local Language were each tried by xml-edge.jsp, with the cookie theme=dark set by curl -b.

Source: Jakarta Standard Tag Library 3.0 — 11.1.2 XPath Variable Bindings

Two sharp edges. A request that has no Cookie header at all makes $cookie:name fail with a NullPointerException ("Cannot read the array length because "c" is null") in the 3.0.1 implementation, instead of an unbound-variable error, so a page that reads a cookie guards it (a request-scoped value set by a filter or servlet is better). And an unbound variable is always an exception: there is no way to test for existence from inside XPath, so a page tests the request first (c:if test="${not empty param.genre}") and sets a default.

Then the rest of the second page: the results of x:set and the old attribute and empty documents.

Source: Jakarta Standard Tag Library 3.0 — 11.4 x:set

Source: Jakarta Standard Tag Library 3.0 — 11.2 x:parse (null and empty source)

An empty document is reported as the parser’s own "Premature end of file", not as the specification’s "source XML document is null or empty"; x:out of a node-set prints the string value of the first node (Dune); and the deprecated xml attribute is still accepted.

An element name without a prefix in XPath means "no namespace". A document whose elements are in a default namespace is therefore invisible to //entry, a classic source of "my XPath finds nothing". The Bookshelf feed feed.xml declares a default namespace and a prefixed one.

Source: Jakarta Standard Tag Library 3.0 — 11.1.1 XPath Context (namespace prefix definitions)

Source: W3C — XPath 1.0

The specification promises "namespace prefix definitions" in the XPath context but gives no way to declare one from a page (the tags have no attribute for it), and a prefix that is not resolvable is an error (Prefix must resolve to a namespace). The portable answer is local-name() (and, for a namespace check, namespace-uri()), as in the page. The stack trace shows the implementation: XPath is evaluated by an embedded copy of Apache Xalan’s XPath engine that the implementation bundles under org.eclipse.tags.shaded, which is why only XPath 1.0 is available.

x:transform applies an XSLT stylesheet to a document. The document comes from doc (a String, Reader, javax.xml.transform.Source, DOM Document, or an object exported by x:parse or x:set) or from the body; the stylesheet from xslt (a String, Reader or Source). Parameters are nested x:param tags.

By default the result is written to the page. An empty source document or stylesheet is a JspException. An implementation may cache compiled stylesheets, and the specification warns that a cache must key on both xslt and xsltSystemId.

Source: Jakarta Standard Tag Library 3.0 — 13.2 x:transform

Source: Jakarta Standard Tag Library 3.0 — 13.3 x:param

Source: Jakarta Tags 3.0 tagdocs — x:transform

Source: Jakarta Tags 3.0 tagdocs — x:param

The Bookshelf stylesheet turns the catalog into a list of the books of one genre, sorted by year; the genre is a stylesheet parameter with a default.

Source: Jakarta Standard Tag Library 3.0 — 13 XML Transform Actions

Source: W3C — XSLT 1.0

x:transform accepted a document in the body, a varDom document, and a stylesheet imported as a string (through the one-line wrapper JSP, because a static .xsl would hit the c:import problem of Getting the XML In). The HTML produced by the stylesheet is written as it is, so a stylesheet is trusted code that must escape the data it prints; xsl:value-of escapes text by default, which is why Foundation & Empire is & in the output. XSLT 1.0 only: xsl:sort, xsl:for-each, parameters and the common instructions work, but nothing from XSLT 2 or 3 (no xsl:for-each-group, no regular expressions).

The JSTL in Action book builds an RSS reader; the same shape is still the classic use of these tags, and still the one that needs the most care. The page rss.jsp imports a feed over HTTP, parses it and lists the items. The scratch application serves its own feed from new-books.jsp; a real page would use the publisher’s URL (the host publisher.example.com appears inside the feed only as data).

Source: Jakarta Standard Tag Library 3.0 — 11.1.7 Resources Access

Source: Jakarta Standard Tag Library 3.0 — 11 XML Core Actions

The risks are the ones of any server-side fetch: c:import of an absolute URL has no timeout attribute, so a slow host holds a request thread; the URL must never come from the request (a visitor-chosen URL makes the server fetch internal addresses, a server-side request forgery); the document is parsed in memory on every request, so a page that serves many visitors caches it; and the remote text is untrusted (see XML Security: XXE, XSLT, XPath Injection and Escaping). A servlet with a client that has timeouts and a cache is the right place, and the page then reads a bean.

Source: W3C — XPath 1.0

Source: OWASP — XML External Entity Prevention Cheat Sheet, Java

Source: Oracle — Java API for XML Processing (JAXP) Security Guide

The test page xml-xxe.jsp imports the entity document from a file and from a request parameter, and the output for both was the same error text about accessExternalDTD (the file read is blocked). The entity attack is the one that makes XML tags in a page worth a security review: the restriction is a default of the implementation, not a promise of the specification (the chapter only says x:parse does not validate), and a container or a different implementation on the class path may behave otherwise. A project that keeps these tags runs the check above once per implementation upgrade.

The best defence for a team that wants nothing of this page in its code is to forbid the libraries. The specification’s chapter 14 provides two tag library validators for that. jakarta.servlet.jsp.jstl.tlv.PermittedTaglibsTLV lists the tag libraries a page may import, and ScriptFreeTLV forbids scripting elements. A validator is attached to a tag library descriptor; every page that imports that library is then checked at translation time. The TLD below allows the core, formatting and functions libraries and (a requirement of the TLV) itself, and nothing else.

Source: Jakarta Standard Tag Library 3.0 — 14 Tag Library Validators

Source: Jakarta Tags 3.0 API — PermittedTaglibsTLV

Source: Jakarta Tags 3.0 API — ScriptFreeTLV

A page that imports only the guard and the core library (guarded-ok.jsp) runs normally. The guard has to be imported by the page to take effect, so teams enforce it with a shared header include (an include-prelude in a jsp-property-group of web.xml, described on the configuration page). The specification’s own example TLDs in chapter 14 contain markup errors (a <jsp-version> element closed with </jsp.version> and a <short-name> closed with </scriptfree>) that make them unusable as printed; the TLD above is the corrected, tested form.

The two libraries meet in a one-off administrative task of the Bookshelf: load catalog.xml into the book table in one transaction. It is a prototype page, exactly what these tags are meant for, and it shows the libraries working together: x:forEach inside sql:transaction, XPath results turned into typed parameters with x:set, and a count at the end. Each book is stored with an offset of 100 on its id so that it does not collide with the rows of setup.jsp.

Source: Jakarta Standard Tag Library 3.0 — 11.4 x:set

Source: Jakarta Standard Tag Library 3.0 — 10.5 sql:transaction

Source: Jakarta Standard Tag Library 3.0 — 10.7 sql:param

The number() results are Double objects (id 101.0), which sql:param bound to a BIGINT and an INT without complaint on H2; the string() results are String objects for the text columns, which is the combination the specification documents. The page ran twice with the same result because the first statements clear the previous load. As a design it has every smell listed at the beginning of this page (a write that a GET can trigger, a file and a database in a view, no authentication), and in a real project it becomes a servlet or a batch job that uses JAXB or StAX and a repository.

Source: Jakarta Standard Tag Library 3.0 — Appendix B: Changes

Source: Jakarta Standard Tag Library 3.0 — Appendix A: Compatibility & Migration

Source: Jakarta Standard Tag Library 3.1 (under development)

The rows for JSTL 1.0, 1.1 and 1.2 come from the book sections of the appendix of the issue and from the spec’s own B.2 and the deprecation footnotes; the rest were checked. The JSTL 3.0.1 implementation is also the last release of org.glassfish.web:jakarta.servlet.jsp.jstl on Maven Central (published 2023-01-19), and the JSTL API 3.0.2 the latest of the API; both projects live in the Jakarta EE repositories jakartaee/tags and eclipse-ee4j/jstl-api.

The two books that cover this page’s tags are JSTL in Action (JSTL 1.0; chapters 7 and 8 for XML and 9 for databases, with the SQL primer in the appendices) and Web Development with JavaServer Pages (JSP 1.2; chapter 9 for databases). They remain good for the ideas (XPath data model, location paths and predicates, XPath variables, result paging, transactions and isolation) and out of date in the details:

Source: Manning — JSTL in Action

Source: Manning — Web Development with JavaServer Pages, Second Edition

Source: Jakarta Tags 3.0 API — ResultSupport

The specification examples carry old habits too. The chapter 10 sample jdbc:mysql://localhost/,org.gjt.mm.mysql.Driver uses a driver class of the year 2000, <x:if select="$customer/[location='UK']"> is not valid XPath, the syntax of x:forEach in 12.6 has a stray > after select, and the two example TLDs of chapter 14 do not parse. They are listed with the other inconsistencies found in this section. What the specification is right about, and the books agree: these tags are for a prototype, a small internal tool or a stop-gap, and the day the page needs a second consumer, a test, a pool setting or a security review, the query moves to Java.