Standard Actions & JavaBeans

A standard action is written <jsp:name attributes> in standard syntax and in a JSP document alike. A translation error results when the jsp prefix is used for an element that is not a standard action; Tomcat 11.0.26 reports Invalid standard action for jsp:plugin, which Pages 4.0 removed (observed).

Source: Jakarta Pages 4.0 — Chapter 5, Standard Actions

Source: Jakarta Pages 4.0 — C.1 Changes between JSP 4.0 and JSP 3.1

Three attribute-handling rules apply to every action, and explain several error messages later on this page.

Source: Jakarta Pages 4.0 — 1.14.1 Request Time Attribute Values

A JavaBean is, for the purposes of Pages, an ordinary Java class that follows a few naming rules so that tools (and Jasper) can discover its properties without being told about them. The rules come from the JavaBeans specification and are implemented by java.beans.Introspector; Jasper introspects the bean class for every jsp:setProperty and jsp:getProperty, and EL’s BeanELResolver uses the same machinery for ${book.title}.

Source: Java SE 21 — java.beans.Introspector

Source: Java SE 21 — java.beans.BeanInfo

The Bookshelf bean used by every example on this page is a plain class with the conventions above: a no-argument constructor, ordinary accessors, a boolean isAvailable(), an indexed tags property, Serializable, and a session binding listener that records its own lifecycle. The featured flag exists so that a later example can show why property="*" is dangerous. The Titled interface exists so that jsp:useBean can name a type that cannot be instantiated.

Source: Java SE 21 — java.beans.Introspector

Source: Jakarta Servlet 6.1 Javadoc — HttpSessionBindingListener

To see what the introspector sees, ask it. This page, and a second class Odd with a getISBN() accessor and a Boolean isFeatured() method, were run as a scriptlet purely for the demonstration (scriptlets are legacy; see the Scripting Elements (Legacy)).

The second block shows both traps: the property is ISBN, not isbn, and featured appears only because of its setter (a Boolean-returning isFeatured() is not a getter). The third line is the decapitalization rule: Introspector.decapitalize("URL") returns URL unchanged because the first two characters are upper case.

Source: Java SE 21 — java.beans.Introspector, decapitalize

jsp:useBean associates a Java object that lives in a scope with a name, creating the object first if it does not exist. It is the action that "introduces" a bean to the page: jsp:setProperty and jsp:getProperty are only valid for names introduced this way (or by a custom action that declares a variable of that name). In a scripting page it also declares a Java local variable of the same name; in a scriptless page or context only the EL variable exists.

At least one of type and class must be present, and class with beanName is not valid. When type and class are both present, class must be assignable to type; Jasper compiles the generated servlet with that assumption, so the mismatch becomes a Java compile error (Unable to compile class for JSP, observed).

Source: Jakarta Pages 4.0 — 5.1 jsp:useBean

jsp:setProperty sets one or more properties of a bean introduced earlier in the same file. The values may come from the request parameters, a string constant or a request-time expression. Property discovery is the ordinary JavaBeans introspection described above, including PropertyEditor and BeanInfo.

The name attribute must be a name introduced by jsp:useBean, and the introducing action must come first in the page; jsp:setProperty placed before its jsp:useBean fails with java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "bean" is null at request time (observed). A jsp:setProperty for a property that does not exist fails with Cannot find any information on property [nosuch] in a bean of type [...] (observed).

Source: Jakarta Pages 4.0 — 5.2 jsp:setProperty

jsp:getProperty writes the value of one property of a bean to the output, converted to a string "as in the println methods": primitives directly and objects with toString(). name is the bean introduced earlier and property is the property name. The specification says "if the object is not found, a request-time exception is raised", and it recommends a translation error when the name was never introduced by jsp:useBean or a custom action.

Tomcat 11.0.26 takes the recommendation: a bean that a servlet stored with setAttribute is not visible to jsp:getProperty unless the page introduces it with jsp:useBean (type only is enough); otherwise the page does not compile (observed).

The unescaped output is a cross-site scripting vector, which is the single best reason to stop using the tag:

A record, which EL 6.0 reads without getters, is invisible to the action. With BookRecord(long id, String title) stored by the servlet as rec, ${rec.title} prints Neuromancer, while jsp:useBean id="rec" type="...BookRecord" followed by jsp:getProperty name="rec" property="title" fails with Cannot find any information on property [title] in a bean of type [org.example.bookshelf.BookRecord] (both observed).

Source: Jakarta Pages 4.0 — 5.3 jsp:getProperty

Source: OWASP — Cross Site Scripting Prevention Cheat Sheet

The standard-action approach and the EL approach read the same objects; the difference is how much the page is responsible for. The table compares the styles on the Bookshelf’s book.

Because jsp:useBean declares a Java variable named by id, scriptlets and bean tags can be mixed, as in basic.jsp above where <%= book.getTitle().length() %> printed 4. The specification warns that the object in the pageContext is "the truth" and that a scripting variable is only a cache of the reference. Mixed pages are among the hardest to maintain, which is why scripting-invalid exists. The tag files, EL and JSTL pages show the replacements.

A bean that implements HttpSessionBindingListener is told when it enters and leaves a session. The next example puts a bean into the session with jsp:useBean and invalidates the session in a second request, then prints the events.

valueUnbound also runs when the session expires or the attribute is replaced, so it is a reliable place to close resources a session bean holds. Storing a bean in the session makes it part of the session’s state, and the session rules (serializability for distributable applications, size, fixation) apply to it; see Servlet Fundamentals.

Source: Jakarta Servlet 6.1 Javadoc — HttpSessionBindingListener

Source: Jakarta Pages 4.0 — 1.8.2 Objects and Scopes

A BeanInfo changes what is a property. With a HiddenBeanBeanInfo that lists only title, a page that sets property="*" with secret=HACK leaves secret alone, and ${h.secret} fails with PropertyNotFoundException: Property [secret] not found on type [org.example.bookshelf.HiddenBean] (observed). That is a legitimate way to protect a bean that has to be used with *, but it is invisible in the class itself, so the explicit form of jsp:setProperty is easier to review.

Source: Java SE 21 — java.beans.BeanInfo

jsp:include includes the output of another resource into the current output at request time. The resource may be a JSP, a servlet, or a static file; it is addressed with a relative URL specification that is interpreted in the context of the web application, and that is mapped like any other request. The included resource shares the request and its attributes (so a request-scope bean is visible to it) but cannot change the response status or set headers, a constraint equivalent to RequestDispatcher.include. Request processing resumes in the calling page afterwards.

Two facts follow. The new parameters are in effect only during the include: after the action the including page sees the original request, whose heading is Orig and whose a is foo (heading=[] and an empty a when the original had none). And jsp:param values are prepended to existing ones, so a request parameter a=foo plus <jsp:param name="a" value="bar"/> gives a=bar,foo in the included page, where ${param.a} is the first value bar and the original is still reachable at paramValues.a[1]. The new value takes precedence; it does not replace the old one.

The relative-path rule is easy to get wrong when two directories are involved. Pages 4.0 gives four combinations of the include directive and the action:

The static-include directive, the three include mechanisms side by side, prelude and coda, and c:import are compared in Includes, Forwards & Page Composition; this page covers only the action and its parameters.

Source: Jakarta Pages 4.0 — 5.4 jsp:include

Source: Jakarta Pages 4.0 — 5.6 jsp:param

jsp:forward dispatches the current request to another resource in the same application and ends the current page: nothing after the action is executed. It is RequestDispatcher.forward from inside a page, with the same effects on the request path attributes. If the page output is buffered, the buffer is cleared before the forward. If the buffer was already flushed, or if an unbuffered page had written anything, the forward cannot work: the specification demands an IllegalStateException.

jsp:forward accepts the same jsp:param children as jsp:include, with the same ordering rules, and a single attribute page, which accepts a request-time value (and has the same path-selection risk as in jsp:include).

The text before the forward and the text after it do not appear. The next page flushes the buffer first.

Tomcat 11.0.26 did not throw the IllegalStateException of the specification: the JSP writer’s clear() raised java.io.IOException: Error: Attempt to clear a buffer that's already been flushed, the error-page mechanism could not run because the response was committed (too late for an error page in the log), and the client received an HTTP 200 with an empty body (observed). The practical rule is the one from the servlet fundamentals page: decide to forward before writing anything, which also means before any <% out.flush() %> and before a full buffer.

A forward is invisible to the browser (the URL does not change) and is only appropriate when the destination is part of the same logical request; after a state change use a redirect (see Includes, Forwards & Page Composition).

Source: Jakarta Pages 4.0 — 5.5 jsp:forward

Source: Jakarta Servlet 6.1 Javadoc — RequestDispatcher

jsp:param has two mandatory attributes, name and value, and the value may be a request-time expression. It is valid only inside jsp:include, jsp:forward (and the removed jsp:params); anywhere else the page is rejected: The jsp:param action must not be used outside the jsp:include or jsp:forward elements (observed). Names and values are written unencoded by the page author; the container encodes them with the request’s character encoding when it has to build a query string, which is why a value containing an ampersand needs no manual escaping. New parameters take precedence over existing ones of the same name and are visible only during the included or forwarded call.

Source: Jakarta Pages 4.0 — 5.6 jsp:param

jsp:element creates an element whose name is only known at request time, jsp:attribute gives it attributes (and, as shown above, can also give attributes to other actions), jsp:body gives it content, and jsp:text writes template text verbatim.

jsp:body takes no attributes and is required whenever jsp:attribute children are present. If jsp:attribute children are present and there is no (or an empty) jsp:body, the action has an empty body.

jsp:element has one mandatory attribute, name, which must be an XML attribute (not a jsp:attribute) because jsp:attribute has a special meaning inside jsp:element. The name may be a request-time value.

The class value was trimmed, the hidden attribute was omitted, and an element with no body was written as an empty tag. The element name must never come from the request: Jasper accepts any name as is ("JSP 4.0 places no constraints on this value"), so a computed name from user input is markup injection.

Source: Jakarta Pages 4.0 — 5.11 jsp:element

Source: Jakarta Pages 4.0 — 5.8 jsp:body

jsp:invoke and jsp:doBody are valid only inside tag files, and a translation error results if they are used in a page. jsp:invoke fragment="name" invokes a fragment attribute (declared with fragment="true"); jsp:doBody evaluates the body passed to the tag. Both write to the current output by default; var (a String) or varReader (a java.io.Reader, resettable) captures the output in a scoped variable, and scope (default page) says which scope, valid only with var or varReader. A session scope throws IllegalStateException when the calling page has no session. The action has no body. This example is only a pointer; the full treatment is on the tag file pages of this section.

Here jsp:attribute supplies the fragment attribute header, jsp:body supplies the body, jsp:invoke writes the fragment, and jsp:doBody is used twice: once captured into inner and once written directly.

Source: Jakarta Pages 4.0 — 5.9 jsp:invoke

Source: Jakarta Pages 4.0 — 5.10 jsp:doBody

Source: Jakarta Pages 4.0 Javadoc — JspFragment

jsp:plugin (with jsp:params and jsp:fallback) generated the object or embed markup that loaded an applet or a bean into the browser’s Java plug-in. Applets no longer run in browsers, and the action was deprecated in Pages 3.1 and removed in 4.0 ("Remove the deprecated jsp:plugin action and related actions"). A page that uses it no longer compiles (observed):

There is no replacement for an applet. A page that rendered one needs a rewrite to ordinary HTML and JavaScript, or a server-side equivalent.

Source: Jakarta Pages 4.0 — C.1 Changes between JSP 4.0 and JSP 3.1

The Bookshelf needs a "preview" page that shows a book typed into a form. The legacy shape binds with property="*" and prints with jsp:getProperty. The shape below keeps the standard actions but removes the two dangers: it lists the three properties the form may set, and it prints through c:out. A fragment renders the card; it receives its bean through the request scope and a heading level through jsp:param.

What the run shows: the level=1 the client sent was overridden by the page’s own jsp:param (the heading is an h2), featured=true was ignored because the page never names that property, the title was escaped by c:out, and the fragment found the bean through jsp:useBean type because the request scope is shared by an included page. The year is printed with plain EL: a number needs no escaping. A form that must reject year=abc still needs a controller, because jsp:setProperty throws.

Source: Jakarta Pages 4.0 — 5.2 jsp:setProperty

Source: Jakarta Pages 4.0 — 5.4 jsp:include

Source: Jakarta Standard Tag Library 3.0 — c:out

In the real Bookshelf both files live under WEB-INF/views and WEB-INF/fragments, reached by a servlet that forwards to them; the examples on this page were served from a top-level demo folder only so that curl could reach every one directly. The servlet fundamentals page shows the controller side (Servlet Fundamentals).

Source: Jakarta Pages 4.0 — Chapter 5, Standard Actions

Two behaviours of Tomcat 11.0.26 are worth knowing because they differ from older material: the jakarta.tags.core URI is the Jakarta Tags 3.0 identifier for the core library, although the old http://java.sun.com/jsp/jstl/core identifier was still accepted by the JSTL 3.0.1 implementation in a test page (observed), and a record, supported by EL 6.0, is not supported by the bean actions.

Source: Jakarta Pages 4.0 — C.1 Changes between JSP 4.0 and JSP 3.1

Source: Jakarta Pages 4.0 — C.2 Changes between JSP 3.1 and JSP 3.0

Web Development with JavaServer Pages (Manning, listed in the section bibliography) devotes two chapters to "using JSP components" and "developing JSP components" and builds its examples around the bean actions, and JSTL in Action and the Struts books describe the same idea in their own tag libraries. The concepts survive; the details have not.

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

Source: Manning — JSTL in Action