Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSR 052 • JavaServer Pages™ (JSP™) Standard Tag Library (JSTL)
Maintenance Review (1.1)

Description

Maintenance review of the JavaServer Pages™ (JSP™) Standard Tag Library (JSTL), version 1.1.

Maintenance Lead

Pierre Delisle, Sun Microsystems, Inc.

Feedback

Comments should be sent to jsr-52-comments@jcp.org

Rationale for proposed changes

As already stated in the JSTL 1.0 specification, the specification of the Expression Language first introduced in JSTL 1.0 is now moving into the JSP 2.0 specification. The primary goal of the JSTL 1.1 maintenance release is to synchronize the JSTL specification with the JSP 2.0 specification which now owns the EL. This maintenance release also adresses clarifications and corrections needed to the initial specification.

Accepted Changes

Expression Language moved to the JSP specification

Make necessary changes all across the specification to reflect the fact that the Expression Language now belongs to the JSP specification (JSP 2.0). This includes removing "Appendix A - Expression Language Definition", as well as modifying examples to take advantage of the fact that EL expressions can now be used in template text and do not require the use of the <c:out> action (unless the escapeXml or default features of <c:out> are required).

Compatibility and Migration

Add new appendix to provide information on compatibility between different versions of JSTL, as well as on how to migrate a web application to take advantage of the new features of the latest JSTL release. The content of this appendix is included at the end of this change log.

Functions

JSP 2.0 introduces EL functions. Define a simple, standard set of functions that has been most often requested by page authors. This includes functions to get the size of a collection, and to perform common string manipulations:
  • contains(string, substring) -> boolean
  • containsIgnoreCase(string, substring) -> boolean
  • endsWith(string, suffix) -> boolean
  • escapeXml(string) -> String
  • indexOf(string, substring) -> int
  • join(collection, separator) -> String
  • length(collection) -> int
  • replace(inputString, beforeSubstring, afterSubstring) -> String
  • split(string, separator) -> String[]
  • startsWith(string, prefix) -> boolean
  • substring(string, beginIndex, endIndex) -> String
  • substringAfter(string, substring) -> String
  • substringBefore(string, substring) -> String
  • toLowerCase(string) -> String
  • toUpperCase(string) -> String
  • trim(string) -> String

Support for direct transfer from Reader -> out

With JSP 2.0, displaying the content of a Reader object to "out" has been identified as an important use case, creating the need for a mechanism to handle a direct transfer from reader -> out. This will be provided as an extension of <c:out>.

In Section 4.2, behavior will now be defined as follows:

The expression to be evaluated is specified via the value attribute.

If the result of the evaluation is not a java.io.Reader object, then it is coerced to a String and is subsequently emitted into the current JspWriter object.

If the result of the evaluation is a java.io.Reader object, data is first read from the Reader object and then written into the current JspWriter object. This special processing associated with Reader objects should help improve performance when large amount of data must be read and then displayed to the page.

Default values

Add new section to describe how default values can be handled in a generic way in JSTL.

2.9 Default Values

It is often desirable to display a default value if the output of an action yields a null value. This can be done in a generic way in JSTL by exporting the output of an action via attribute var, and then displaying the value of that scoped variable with action <c:out>.

For example:
<fmt:formatDate var="formattedDate" value="${reservationDate}"/>
Date: <c:out value="${formattedDate}" default="not specified"/>

end attribute >= begin attribute in iterator actions

The spec currently constrains the end attribute to be greater than or equal to the begin attribute. The spec will be relaxed to handle this situation according to common practices of modern programming languages (e.g. C++, Java, Perl). If end < begin, the loop will simply not be executed.

Correct the way character encoding is handled for <c:import>

In Section 7.4, behavior will now be defined as follows:

<c:import> exposes a String or Reader object, both of which are sequences of text characters. It is possible to specify the character encoding of the input resource via the charEncoding attribute. The values supported for charEncoding are the same as the ones supported by the constructor of the Java class InputStreamReader.

If the character encoding is not specified, the following rules apply:

  • If URLConnection.getContentType() has a non-null result, the character set is retrieved from URLConnection.getContentType() by parsing this method's result according to RFC 2045 (section 5.1).
  • If this method's result does not include a character set, or if the character set causes InputStreamReader(InputStream in, String charsetName) to throw an UnsupportedEncodingException, then use ISO-8859-1 (which is the default value of charset for the contentType attribute of the JSP "page" directive).

Correct the inconsistency between <fmt:message> and <fmt:formatXXX> when <fmt:message> is used with parametric replacement and a locale-less localization context

Correct as follows:

If the localization context does not have any locale, the locale of the java.text.MessageFormat is set to the locale returned by the formatting locale lookup algorithm in section 9.3, except that the available formatting locales are given as the intersection of the number- and date- formatting locales. If this algorithm does not yield any locale, the locale of the java.text.MessageFormat is set to the runtime's default locale.

Null or empty values with formatting actions

Clarify the behavior of <fmt:formatNumber> and <fmt:formatDate> (sections 9.7 and 9.9) when value is null or empty.
  • If value is null or empty, nothing is written to the current JspWriter object and the scoped variable is removed if it is specified (see attributes var and scope).

Connection handling in SQL actions

Clarify the fact that SQL actions in JSTL always release connections to the database as quickly as possible (a connection is always closed by the time execution of the action responsible for opening it completes).

Context for XPath expression evaluations nested within <x:forEach>

This will be clarified through a new description subsection in Section 12.6:

Inside the body of the tag, the context for XPath expression evaluations is obtained as follows:

  • variable, function, and namespace bindings operate as in the rest of JSTL
  • the context node is the node whose representation would be exposed by 'var' (whether or not the 'var' attribute is specified)
  • the context position is the iteration 'count' (with the same meaning as in <c:forEach>)
  • the context size is equal to the number of nodes in the node-set over which <x:forEach> is presently iterating.

Align behavior of <x:forEach> with <c:forEach>

Add attributes varStatus, begin, end, and step.

Default context node for Xpath expression evaluations

This will be clarified through the new section "11.1.7 Default Context Node".

The context node for every XPath expression evaluation in JSTL that does not appear in the body of an <x:forEach> tag is the root of an empty document. Page authors wishing to work with documents must therefore supply their own node(s) using an XPath variable (see section 11.1.2).

Action <x:forEach> establishes for its nested actions a specific context for XPath expressions evaluation. See section 12.6 for details.

Replace attributes that start with "xml"

Names beginning with the string "xml" are reserved by the XML specification.
  • Add new attribute doc for <x:parse> to replace attribute xml that is now being deprecated.
  • Add new attributes doc and docSystemId for <x:transform> to replace attributes xml and xmlSystemId that are now being deprecated.

Response Encoding

The way formatting actions influence the encoding of the response needs to be clarified in sections 8.4 and 8.10. Repeated calls to ServletResponse.setLocale() will affect the character encoding of the response only if it has not already been set explicitely.

Minor corrections

  • Correct status with varStatus in section 6.6.
  • Correct the resulting locale of examples 1 and 3 in Section 8.3.3.
    In both cases, the resulting locale is en_GB.
  • Correct the syntax of <sql:dateParam> in Section 10.8.
    <sql:dateParam value="value" [type="{timestamp|time|date}"]/>

Deferred Changes

Provide adequate XML Namespace support for the XML actions

JSTL 1.0 does not currently provide adequate support for XML namespaces in XPath expressions. Collaboration between the JSP, JAXP, and JSTL specs is necessary to come up with the proper solution. This will therefore be addressed in the next major revision of JSTL.

Appendix C. Compatibility & Migration

This appendix provides information on compatibility between different versions of JSTL, as well as on how to migrate your web application to take advantage of the new features of the latest JSTL release.

C.1 JSTL 1.1 backwards compatibility

JSTL 1.1 is backwards compatible with JSTL 1.0. This means that a web-application that was developed to run with JSTL 1.0 won�t require any modification when run with JSTL 1.1. Details explaining how this backwards compatibility is achieved are given in Section C.1.1 below.

If your application executes in an environment that has JSTL 1.1, it is however recommended that you migrate to JSTL 1.1 to take full advantage of the new capabilities it offers. Details on how to migrate your web-application from JSTL 1.0 to JSTL 1.1 are given in Section C.2.

C.1.1How JSTL 1.1 backwards compatibility is achieved
JSTL 1.0 requires JSP 1.2 (J2EE 1.3 platform). The key difference between JSTL 1.0 and JSTL 1.1 is that the expression language (EL) has moved from the JSTL specification to the JSP specification. The EL is therefore now part of the JSP 2.0 specification, and JSTL 1.1 requires JSP 2.0 (J2EE 1.4 platform).

A web application developed for JSP 1.2 has a servlet 2.3 deployment descriptor (web.xml). JSP 2.0 provides backwards compatibility for JSP 1.2 web applications by disabling by default the EL machinery (i.e. evaluation of EL expressions) when a web application has a servlet 2.3 deployment descriptor. A web application that uses JSTL 1.0 and which is deployed with a servlet 2.3 deployment descriptor therefore runs without any modification in a J2EE 1.4 environment because EL expressions are ignored by JSP 2.0, and JSTL 1.0 keeps evaluating them as was the case with JSP 1.2.

To support backwards compatibility, JSTL 1.1 introduces new URIs that must be specified to use the new capabilities offered in JSTL 1.1. Among these new capabilities is the evaluation of EL expressions being performed by the JSP 2.0 container rather than JSTL itself. The new URIs for JSTL 1.1 are as follows:

  • http://java.sun.com/jsp/jstl/core
  • http://java.sun.com/jsp/jstl/xml
  • http://java.sun.com/jsp/jstl/fmt
  • http://java.sun.com/jsp/jstl/sql
The new URIs are similar to the old JSTL 1.0 EL URIs, except that jsp/ has been added in front of jstl, stressing JSTL's dependency on the JSP specification (which now "owns" the EL). It would have been desirable to move forward with the same EL URIs in JSTL 1.1, however this would have only been possible at the cost of losing full backwards compatibility. The JSTL Expert Group felt that maintaining backwards compatibility was more important than preserving the old URIs.

The JSTL 1.0 URIs are deprecated as of JSTL 1.1. If used, they should normally appear in a web application that has a servlet 2.3 deployment descriptor to disable the JSP 2.0 EL machinery. If used with a servlet 2.4 deployment descriptor, the JSP 2.0 EL machinery must be explicitely disabled for the pages where the JSTL 1.0 tag libraries are used. Consult the JSP specification for details.

C.2. Migrating to JSTL 1.1

To migrate from JSTL 1.0 to JSTL 1.1, so a web application can take advantage of the new features associated with JSTL 1.1, one must do the following:
  • Migrate the web application deployment descriptor (web.xml) from servlet 2.3 to servlet 2.4. See Servlet 2.4 specification for details
  • Replace all the JSTL 1.0 EL & RT URIs by the new JSTL 1.1 URIs
  • Escape all occurrences of "{" in RT actions and template text. See JSP 2.0 specification for details.