JSP.1.4 Overview of JSP Page Semantics

This section provides an overview of the semantics of JSP pages.

JSP.1.4.1 Translating and Executing JSP Pages

A JSP page is executed in a JSP container , which is installed on a web server, or on a web enabled application server. The JSP container delivers requests from a client to a JSP page and responses from the JSP page to the client. The semantic model underlying JSP pages is that of a servlet: a JSP page describes how to create a response object from a request object for a given protocol, possibly creating and/or using in the process some other objects.

All JSP containers must support HTTP as a protocol for requests and responses, but a container may also support additional request/response protocols. The default request and response objects are of type HttpServletRequest and HttpServletResponse , respectively.

A JSP page may also indicate how some events are to be handled. In JSP 1.1 only init and destroy events can be described: the first time a request is delivered to a JSP page a jspInit() method, if present, will be called to prepare the page. Similarly, a JSP container can reclaim the resources used by a JSP page at any time that a request is not being serviced by the JSP page by invoking first its jspDestroy() method; this is the same life cycle as that of servlets.

A JSP page is represented at request-time by a JSP page implementation class that implements the javax.servlet.Servlet interface. JSP pages are often implemented using a JSP page translation phase that is done only once, followed by some request processing phase that is done once per request. The translation phase creates the JSP page implementation class. If the JSP page is delivered to the JSP container in source form, the translation of a JSP source page can occur at any time between initial deployment of the JSP page into the runtime environment of a JSP container and the receipt and processing of a client request for the target JSP page.

A JSP page contains some declarations , some fixed template data, some (perhaps nested) action instances, and some scripting elements . When a request is delivered to a JSP page, all these pieces are used to create a response object that is then returned to the client. Usually, the most important part of this response object is the result stream.

JSP.1.4.2 Compiling JSP Pages

JSP pages may be compiled into its JSP page implementation class plus some deployment information. This enables the use of JSP page authoring tools and JSP tag libraries to author a servlet. This has several benefits:

• Removal of the start-up lag that occurs when a JSP page delivered as source receives the first request.

• Reduction of the footprint needed to run a JSP container, as the Java compiler is not needed.

If a JSP page implementation class depends on some support classes in addition to the JSP 1.1 and Servlet 2.2 classes, the support classes will have to be included in the packaged WAR so it will be portable across all JSP containers.

JSP.C contains two examples of packaging of JSP pages. One shows a JSP page that is delivered in source form (probably the most common case) within a WAR. The other shows how a JSP page is translated into a JSP page implementation class plus deployment information indicating the classes needed and the mapping between the original URL that was directed to the JSP page and the location of the servlet.

JSP.1.4.3 Objects and Scopes

A JSP page can create and/or access some Java objects when processing a request. The JSP specification indicates that some objects are created implicitly, perhaps as a result of a directive (see Section JSP.2.8, "Implicit Objects"); other objects are created explicitly through actions; objects can also be created directly using scripting code, although this is less common. The created objects have a scope attribute defining where there is a reference to the object and when that reference is removed .

The created objects may also be visible directly to the scripting elements through some scripting-level variables (see Section JSP.1.4.7, "Objects and Variables ").

Each action and declaration defines, as part of its semantics, what objects it defines, with what scope attribute, and whether they are available to the scripting elements.

Objects are always created within some JSP page instance that is responding to some request object. There are several scopes:

• page ” Objects with page scope are accessible only within the page where they are created. All references to such an object shall be released after the response is sent back to the client from the JSP page or the request is forwarded somewhere else. References to objects with page scope are stored in the pageContext object.

• request ” Objects with request scope are accessible from pages processing the same request where they were created. All references to the object shall be released after the request is processed ; in particular, if the request is forwarded to a resource in the same runtime, the object is still reachable . References to objects with request scope are stored in the request object.

• session ” Objects with session scope are accessible from pages processing requests that are in the same session as the one in which they were created. It is not legal to define an object with session scope from within a page that is not session-aware (see Section JSP.2.7.1, "The page Directive"). All references to the object shall be released after the associated session ends. References to objects with session scope are stored in the session object associated with the page activation.

• application ” Objects with application scope are accessible from pages processing requests that are in the same application as the one in which they were created. All references to the object shall be released when the runtime environment reclaims the ServletContext . Objects with application scope can be defined (and reached) from pages that are not session-aware. References to objects with application scope are stored in the application object associated with a page activation.

A name should refer to a unique object at all points in the execution; i.e., all the different scopes really should behave as a single name space. A JSP container implementation may or may not enforce this rule explicitly for performance reasons.

JSP.1.4.4 Fixed Template Data

Fixed template data is used to describe those pieces that are to be used verbatim either in the response or as input to JSP actions. For example, if the JSP page is creating a presentation in HTML of a list of, say, books that match some search conditions, the template data may include things like the <ul> , </ul> , and something like <li>The following book... .

This fixed template data is written (in lexical order) unchanged onto the output stream (referenced by the implicit out variable) of the response to the requesting client.

JSP.1.4.5 Directives and Actions

There may be two types of elements in a JSP page: directives or actions . Directives provide global information that is conceptually valid independent of any specific request received by the JSP page. For example, a directive can be used to indicate the scripting language to use in a JSP page. Actions may, and often will, depend on the details of the specific request received by the JSP page. If a JSP container uses a compiler or translator, the directives can be seen as providing information for the compilation/translation phase, while actions are information for the subsequent request processing phase.

An action may create some objects and may make them available to the scripting elements through some scripting-specific variables.

Directive elements have a syntax of the form

 <%@ directive ...%> 

Action elements follow the syntax of XML elements, i.e., have a start tag, a body, and an end tag:

 <mytag attr1="attribute value" ...>  body  </mytag> 

or an empty tag

 <mytag attr1="attribute value" .../> 

An element has an element type describing its tag name, its valid attributes, and its semantics; we refer to the type by its tag name.

JSP.1.4.5.1 Tag Extension Mechanism

An element type abstracts some functionality by defining a specialized (sub)language that allows more natural expression of the tasks desired, can be read and written more easily by tools, and also can even contribute specialized yet portable tool support to create them.

The JSP specification provides a tag extension mechanism (see Chapter JSP.5) that enables the addition of new actions, thus allowing the JSP page "language" to be easily extended in a portable fashion. A typical example would be elements to support embedded database queries. Tag libraries can be used by JSP page authoring tools and can be distributed along with JSP pages to any JSP container like web and application servers.

The tag extension mechanism can be used from JSP pages written using any valid scripting language, although the mechanism itself only assumes a Java runtime environment. Custom actions provide access to the attribute values and to their body; they can be nested and their bodies can include scripting elements.

JSP.1.4.6 Scripting Languages

Scripting elements are commonly used to manipulate objects and to perform computation that affects the content generated. There are three classes of scripting elements: declarations , scriptlets , and expressions. Declarations are used to declare scripting language constructs that are available to all other scripting elements. Scriptlets are used to describe actions to be performed in response to some request. Scriplets that are program fragments can also be used to do things like iterations and conditional execution of other elements in the JSP page. Expressions are complete expressions in the scripting language that get evaluated at response time; commonly the result is converted into a string and then inserted into the output stream.

All JSP containers must support scripting elements based on the Java programming language. Additionally, JSP containers may support other scripting languages. All such scripting languages must support:

• Manipulation of Java language objects

• Invocation of methods on Java language objects

• Catching of Java language exceptions

The precise definition of the semantics for scripting done using elements based on the Java programming language is given in Chapter JSP.4.

The semantics for other scripting languages are not precisely defined in this version of the specification, which means that portability across implementations cannot be guaranteed . Precise definitions may be given for other languages in the future.

JSP.1.4.7 Objects and Variables

An object may be made accessible to code in the scripting elements through a scripting language variable. An element can define scripting variables in two places: after its start tag and after its end tag. The variables will contain at process request-time a reference to the object defined by the element, although other references exist depending on the scope of the object (see Section JSP.1.4.3, "Objects and Scopes").

An element type indicates the name and type of such variables although details on the name of the variable may depend on the scripting language. The scripting language may also affect how different features of the object are exposed; for example, in the JavaBeans specification, properties are exposed via getter and setter methods, while these are available directly in the JavaScript programming language.

The exact rules for the visibility of the variables are scripting language specific. Chapter JSP.4 defines the rules for when the language attribute of the page directive is " java ."

JSP.1.4.8 Scripts, Actions, and Beans

Scripting elements, actions, and beans are all mechanisms that can be used to describe dynamic behavior in JSP pages. Different authors and authoring tools can use these mechanisms in different ways based on their needs and their preferences. The JSP specification does not restrict their use but this section provides some guidelines that may be useful to understand their relative strengths.

Beans are a well-known and well-supported component framework for the Java platform that can be accessed easily from the Java programming language and other JSP page scripting languages. Some JSP page authors, or their support organizations, may create or reuse bean components to use from their JSP pages.

Actions provide an abstraction that can be used to easily encapsulate common actions. Actions typically create and/or act on (server-side) objects, often beans.

The JSP specification provides some standard actions that can be used to interact with any bean. If the bean is extended so it implements the Tag interface, then the bean becomes a tag handler and it can be used directly in the JSP page with improved integration into the template data.

Scripting elements are very flexible; that is their power but also their danger as they can make hard understanding and maintaining a page that uses them extensively; they may also make it hard for an authoring tool. In some development contexts, JSP pages will mostly contain only actions (standard or custom) with scripting elements only used as a "gluing" mechanism that can be used to "fill-in" the actions that are described using actions (and beans and EJB components). In other development contexts JSP pages may contain significant amounts of scripting elements.

JSP.1.4.9 JSP, HTML, and XML

The JSP specification is designed to support the dynamic creation of several types of structured documents, especially those using HTML and XML.

In general, a JSP page uses some data sent to the server in an HTTP request (for example, by a QUERY argument or a POST method) to interact with information already stored on the server, and then dynamically creates some content which is then sent back to the client. The content can be organized in some standard format (like HTML, DHTML, XHTML, XML, etc.), in some ad-hoc structured text format, or not at all.

There is another relationship between JSP and XML: a JSP page has a standard translation into a valid XML document. This translation is useful because it provides a standard mechanism to use XML tools and APIs to read, manipulate, and author JSP documents. The translation is defined in Chapter JSP.7. JSP 1.1 processors are not required to accept JSP pages in this standard XML syntax, but this may be required in a future version of the JSP specification.