Implicit Objects & Scopes

All the examples below are views of one WAR, deployed as g3implicit.war under the context path /g3implicit. A small servlet (ViewServlet, mapped to /view/*) sets the request attributes book and who, increments a visit counter, and forwards to /WEB-INF/views/implicit/<name>.jsp for a fixed list of view names; a ServletContextListener (CatalogListener) stores catalogName and visits in the application scope at start-up. web.xml declares the context parameter shelfName and a jsp-file servlet. The two Java classes are shown once here; every other listing on the page is a JSP or a descriptor.

Source: Jakarta Servlet 6.1 — 4.5 Context Attributes

The view name is looked up in a fixed set before it is put into the forward path, so a request cannot choose an arbitrary file; the views stay under WEB-INF, so no URL reaches a JSP directly.

Source: Jakarta Pages 4.0 — 1.8 Objects

The specification defines implicit objects twice, because a JSP page has two languages inside it. The Java scripting variables (scriptlets and scripting expressions) can use nine objects without declaring them: request, response, pageContext, session, application, out, config, page and, in error pages only, exception. The Expression Language sees eleven different names: pageContext, the four scope maps pageScope, requestScope, sessionScope and applicationScope, the request-data maps param, paramValues, header, headerValues and cookie, and the context-parameter map initParam. Only pageContext is in both lists. The objects of the first list are real Java objects of the types in the next table; the objects of the second list are mostly java.util.Map views that the EL resolver builds on demand.

Source: Jakarta Pages 4.0 — 1.8.3 Implicit Objects

Source: Jakarta Pages 4.0 — 2.4 Implicit Objects (EL)

The glossary of the specification states the same split in one sentence: the implicit objects are request, response, pageContext, session, application, out, config, page and exception for scriptlets and scripting expressions, and pageContext, pageScope, requestScope, sessionScope, applicationScope, param, paramValues, header, headerValues, cookie and initParam for EL expressions.

The translator declares these variables at the top of the generated service method, so a scriptlet can use them by name. Each has a type from a core Java or Servlet package (Pages 4.0 Table JSP.1-6 and JSP.1-7).

Source: Jakarta Pages 4.0 — 1.8.3 Implicit Objects

The first view asks each variable for its class. It is a scripting page, shown here as the "before" style the rest of the section replaces with EL and JSTL; it is the clearest way to see that these are ordinary Java objects.

Source: Jakarta Pages 4.0 — 1.8.3 Implicit Objects

The class names are Tomcat’s and differ on Jetty or GlassFish; the interface types are what a page may rely on. request is an ApplicationHttpRequest because the page was reached by RequestDispatcher.forward from the servlet: after a forward the container hands the page a request object that exposes the new path while the original is still reachable through the jakarta.servlet.forward.* attributes. The generated class lives in the package org.apache.jsp with the escaped path WEB_002dINF.views.implicit (the hyphen of WEB-INF becomes _002d), and page is that class’s instance, so page == this is true.

Four rules decide when these names are valid.

Source: Jakarta Pages 4.0 — 1.10.1 The page Directive

Source: Jakarta Pages 4.0 — 7.5.1 How to Define New Implicit Objects

A tag file has a smaller set (Table JSP.8-5): request, response, session, application, out and config, plus jspContext, a JspContext instead of pageContext, because a tag file can also run outside a servlet environment. There is no page and no exception there.

jakarta.servlet.jsp.PageContext extends jakarta.servlet.jsp.JspContext. The Javadoc describes it as one API that manages the scoped namespaces, provides convenience accessors for the other implicit objects, supplies the JspWriter and offers forward, include and error handling. The generated code obtains one PageContext per request from JspFactory.getPageContext, passing the servlet, the request, the response, the error page URL, whether the page needs a session, the buffer size and the autoflush flag, and releases it afterwards, which is how session="false" and the buffer and autoFlush attributes of the page directive reach the runtime. Page authors do not call those lifecycle methods; the rest of the class is for them and for tag handlers.

Source: Jakarta Pages 4.0 Javadoc — PageContext

Source: Jakarta Pages 4.0 Javadoc — JspContext.findAttribute

Source: Jakarta Pages 4.0 — 1.8.4 The pageContext Object

Two reasons make the object worth knowing even when a page never mentions it. First, EL, JSTL and tag handlers all read and write attributes through it: c:set calls pageContext.setAttribute(name, value, scope), and the bare ${name} of EL is pageContext.findAttribute(name). Second, in EL it is the bridge to the scripting objects, because the EL implicit objects have no request or session: ${pageContext.request.contextPath} and ${pageContext.session.id} are the only EL spellings.

A scope is a named storage area with an owner and a lifetime. The specification (1.8.2) defines four, and each is backed by an object of the Servlet API, so what a JSP writes is visible to servlets, filters and listeners, and the reverse.

Source: Jakarta Pages 4.0 — 1.8.2 Objects and Scopes

Source: Jakarta Servlet 6.1 — 3.3 Attributes

Source: Jakarta Servlet 6.1 — 4.5 Context Attributes

Source: Jakarta Servlet 6.1 — 7.3 Session Scope

The specification adds an ideal that containers are allowed to leave unenforced: a name should mean one object at every point of the execution, that is, all the scopes should behave as a single name space. A page that stores who in every scope violates the ideal and is a bug waiting to happen, but it is legal and the lookup order decides what the page sees. The view below exercises exactly that.

Source: Jakarta Pages 4.0 Javadoc — JspContext.findAttribute

Source: Jakarta Pages 4.0 Javadoc — JspContext.getAttributesScope

Source: Jakarta Pages 4.0 Javadoc — JspContext.removeAttribute

The output demonstrates five rules. The nearest scope wins: the page copy hides the request copy, which hides the session copy, which hides the application copy. Removing a copy with c:remove and a scope removes only that one, so the next scope shows through; c:remove without scope, like pageContext.removeAttribute(name), removes the name from all scopes at once, which is what the scriptlet shows. A name found nowhere gives scope 0 and the empty string, never an error. Storing null removes the attribute. The request copy came from the servlet, so a servlet-set request attribute and a JSP-set page attribute are the same kind of thing seen from different sides.

The spec text of findAttribute says the session is searched "if valid"; that is the practical meaning of the next view.

out is a jakarta.servlet.jsp.JspWriter, an abstract class that extends java.io.Writer and emulates parts of BufferedWriter and PrintWriter. Everything the page produces goes through it: the template text, <%= %> values, the output of c:out and of every tag. It differs from PrintWriter in one respect, which explains the odd signatures: its print methods declare IOException.

The writer buffers by default, and the reason matters. If the page is not buffered, output goes straight to the PrintWriter of the response and the headers are committed with the first byte. If it is buffered, the PrintWriter is not even created until the buffer is flushed, so until then the page can still call setContentType, sendRedirect, sendError or add headers. The specification states that headers are sent only at the first flush; after that those calls are invalid.

Source: Jakarta Pages 4.0 Javadoc — JspWriter

Source: Jakarta Pages 4.0 — 11.3 Buffering

The size and the overflow policy are set with the buffer and autoFlush attributes of the page directive (the default is at least 8 KB and autoFlush="true"), or for a group of pages with the buffer element of a JSP property group. The view below prints a few facts, discards the buffer, flushes, and then tries to change the response.

Source: Jakarta Pages 4.0 Javadoc — JspWriter.clearBuffer

Source: Jakarta Pages 4.0 — 11.3 Buffering

Read the output carefully. The first three lines of the page, buffer size, remaining and autoFlush, are gone because clearBuffer() discarded everything written so far (the buffer held 67 bytes: 8192 minus 8125). The status is still 200 and there is no X-Late header although the scriptlet set a header and a status of 202: both calls came after flush(), which had committed the response, and the container ignores them. The response is chunked because the length was no longer known when the headers went out.

The second policy is a failure instead of a flush. With autoFlush="false" an overflow throws an IOException.

Source: Jakarta Pages 4.0 Javadoc — JspWriter, Buffering

That policy suits pages whose client is an application rather than a browser and needs complete data or none, as the Javadoc explains; an error page can then still replace a half-built answer. With autoFlush="true" the same loop would flush and commit, and a later error would produce a truncated page with a 200 status. For tags, pageContext.pushBody() replaces out with a BodyContent so a tag can capture the output of its body, and popBody() restores the previous writer; this is how c:out and every body tag compose output, and the custom-tag pages of this section (Classic Handlers and SimpleTag) build on it.

In EL the same data is reached through the eleven implicit objects. The JSP container passes a jakarta.el.CompositeELResolver to every expression, and its first component is the ImplicitObjectELResolver, so an implicit object name wins over any attribute of the same name. A bare identifier that matches no implicit object reaches ScopedAttributeELResolver near the end of the chain, which does exactly pageContext.findAttribute(name). The specification gives the example ${product}: it searches the page, request, session and application scopes in that order and returns the first match.

Source: Jakarta Pages 4.0 — 2.4 Implicit Objects (EL)

Source: Jakarta Pages 4.0 — 2.10 Resolution of Variables and their Properties

Because the resolver chain is shared with the whole EL language, its order is worth knowing: after the implicit objects come the resolvers registered with JspApplicationContext.addELResolver (the hook Jakarta Faces uses), the stream resolver, StaticFieldResolver, MapELResolver, ResourceBundleELResolver, ListELResolver, ArrayELResolver, RecordELResolver, BeanELResolver (everything with a non-null base), and then ScopedAttributeELResolver, ImportELResolver and NotFoundELResolver for names without a base. NotFoundELResolver always resolves, returning null, which is why an unknown name prints nothing; the errorOnELNotFound setting turns that into a PropertyNotFoundException and is the first thing to switch on while developing. The EL language itself, operators and type coercion are on the Expression Language Basics and EL Operators & Type Coercion pages of this section.

Source: Jakarta Pages 4.0 — 2.4 Implicit Objects (EL)

Source: Jakarta Pages 4.0 — 2.7 Unknown EL Identifiers

The two traps are in the output. ${request.method} is empty because EL has no request object: request there is just a name that the scoped-attribute resolver looks up as an attribute, finds nowhere, and resolves to null; the correct spelling is ${pageContext.request.method}, and nothing warns about the mistake unless errorOnELNotFound is on. And ${param.q} still worked after c:set created a request attribute called param, because the implicit object param is consulted first; the attribute is reachable only as ${requestScope.param}. The same shadowing applies to header, cookie, initParam, pageContext and the scope names, so never name an attribute after an implicit object.

Request data is untrusted. param, header, cookie and initParam values reach the page unchanged, and ${...} in template text does not escape them. The next view shows the difference in an HTML page, with the query parameter q set to a script tag.

Source: Jakarta Standard Tag Library 3.0 — c:out

The first line is a cross-site scripting hole; the second is the secure default. Every EL expression that prints request data into HTML goes through c:out (or fn:escapeXml, or an encoder of the OWASP Java Encoder library), and the escapeXml attribute of c:out defaults to true. The scope maps are equally untrusted when the value came from a user: data stored in sessionScope by one request is output by another.

config is the ServletConfig of the servlet that executes the page. For a plain .jsp file the container creates that servlet itself, with the name jsp on Tomcat and no initialization parameters; the two things a page author uses it for are getServletName() and getInitParameter(...), which are meaningful once the page is declared in web.xml with <jsp-file>, so that the declaration can carry <init-param> entries. getServletContext() returns the same object as application. page is the page instance, this, and is almost never useful to page code.

Source: Jakarta Servlet 6.1 Javadoc — ServletConfig

Source: Jakarta Pages 4.0 — 1.8.3 Implicit Objects

For a context-wide setting prefer the <context-param> and read it as ${initParam.shelfName}; the per-page config is the right tool only for a page that is genuinely one configured servlet.

A page names its error page with errorPage="..." in the page directive, and a page that serves as an error page declares isErrorPage="true". Only then does the exception variable exist, and pageContext.getErrorData() returns an ErrorData with the facts the Servlet container recorded in the jakarta.servlet.error.* request attributes. Pages 4.0 added method and queryString to ErrorData, together with the matching Servlet 6.1 attributes jakarta.servlet.error.method and jakarta.servlet.error.query_string. The full error-handling story, including web.xml error pages and their precedence, is the subject of the Error Handling page of this section.

Source: Jakarta Pages 4.0 Javadoc — ErrorData

Source: Jakarta Pages 4.0 Javadoc — PageContext.getErrorData

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

The request URI is the path of the page that failed (the forward target under WEB-INF), not the URL the user typed, and the servlet name jsp is the Tomcat servlet that compiles and runs every JSP. Two cautions follow. The exception message and class are internal information, so an error page for the public prints a generic message and logs the throwable; the exception and errorData objects are for the log. And the PageContext Javadoc says getErrorData is meaningless in a page that is not an error page.

A tag file is a JSP fragment packaged as a custom tag. It has its own page scope, jspContext is its context object, and the request, session and application scopes are the caller’s. The tag below writes one attribute to its own page scope and one to the request, and prints the class of its jspContext.

Source: Jakarta Pages 4.0 — 8.8 Implicit Objects (tag files)

Source: Jakarta Pages 4.0 Javadoc — JspContext

The page scope of the tag file is private: the caller does not see tagLocal unless the tag declares it with a variable directive, which synchronizes a tag-file variable with the caller’s page scope. The request attribute is the shared channel, and a tag that writes request attributes without documenting them is a source of surprising coupling. The Tag Files & Layouts and Custom Tags pages of this section cover variable, attribute and the variable-synchronization rules.

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

Source: Jakarta Pages 4.0 — C.3 Changes between JSP 3.0 and JSR 245

Source: Jakarta Servlet 6.1 — A.1 Changes Since Jakarta Servlet 6.0

The implicit objects and the four scopes are the part of JSP that has changed least since 2001, so the concepts the books teach (Web Development with JavaServer Pages chapters 4 and 6, and JSTL in Action chapters 1 to 3, listed in the section bibliography) still hold. What has moved around them is the platform, the style and a few APIs.

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

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