PREDEFINED VARIABLES

PREDEFINED VARIABLES

 To simplify code in JSP expressions and scriptlets, Servlet also creates several objects
to be used by the JSP engine; these are sometimes called implicit objects (or

predefined variables). Many of these objects are called directly without being
explicitly declared. These objects are:

1. The out Object
2. The request Object
3. The response Object
4. The pageContext Object
5. The session object
6. The application Object
7. The config Object
8. The page Object
9. The exception Object
 

• The out Object

The major function of JSP is to describe data being sent to an output stream in
response to a client request. This output stream is exposed to the JSP author through
the implicit out object. The out object is an instantiation of a
javax.servlet.jsp.JspWriter object. This object may represent a direct reference to the
output stream, a filtered stream, or a nested JspWriter from another JSP. Output
should never be sent directly to the output stream, because there may be several output
streams during the lifecycle of the JSP.
 

The initial JspWriter object is instantiated differently depending on whether the page
is buffered or not. By default, every JSP page has buffering turned on, which almost

always improves performance. Buffering be easily turned off by using the buffered=
‘false’ attribute of the page directive.
 

A buffered out object collects and sends data in blocks, typically providing the best
total throughput. With buffering the PrintWriter is created when the first block is sent,
actually the first time that flush() is called.
 

With unbuffered output the PrintWriter object will be immediately created and
referenced to the out object. In this situation, data sent to the out object is immediately
sent to the output stream. The PrintWriter will be created using the default settings
and header information determined by the server.
 

In the case of a buffered out object the OutputStream is not established until the first
time that the buffer is flushed. When the buffer gets flushed depends largely on the
autoFlush and bufferSize attributes of the page directive. It is usually best to set the
header information before anything is sent to the out object It is very difficult to set
page headers with an unbuffered out object. When an unbuffered page is created the
 

OutputStream is established almost immediately.
The sending headers after the OutputStream has been established can result in a
number of unexpected behaviours. Some headers will simply be ignored, others may
generate exceptions such as IllegalStateException.
 

The JspWriter object contains most of the same methods as the java.io.PrintWriter
class. However, JspWriter has some additional methods designed to deal with
buffering. Unlike the PrintWriter object, JspWriter throws IOExceptions. In JSP these
exceptions need to be explicitly caught and dealt with. More about the out object is
covered in Chapter 6.
 

Setting the autoFlush= ‘false’ attribute of the page directives will cause a buffer
overflow to throw an exception.

• The request Object

Each time a client requests a page the JSP engine creates a new object to represent
that request. This new object is an instance of javax.servlet.http.HttpServletRequest
and is given parameters describing the request. This object is exposed to the JSP
author through the request object.
 

Through the request object the JSP page is able to react to input received from the
client. Request parameters are stored in special name/value pairs that can be retrieved
using the request.getParameter(name) method.
 

The request object also provides methods to retrieve header information and cookie
data. It provides means to identify both the client and the server, e.g., it uses
request.getRequestURI() and request.getServerName() to identify the server.
 

The request object is inherently limited to the request scope. Regardless of how the
page directives have set the scope of the page, this object will always be recreated
with each request. For each separate request from a client there will be a
corresponding request object.
 

• The response Object

Just as the server creates the request object, it also creates an object to represent the
response to the client.

 Just as the server creates the request object, it also creates an object to represent the
response to the client.
63
The object is an instance of javax.servlet.http.HttpServletResponse and is exposed to
the JSP author as the response object.
The response object deals with the stream of data back to the client. The out object is
very closely related to the response object. The response object also defines the
interfaces that deal with creating new HTTP headers. Through this object the JSP
author can add new cookies or date stamps, change the MIME content type of the
page, or start “server-push” ethods. The response object also contains enough
information on the HTTP to be able to return HTTP status codes, such as forcing page
redirects.
 

• The pageContext Object

  The pageContext object is used to represent the entire JSP page. It is intended as a
means to access information about the page while avoiding most of the
implementation details.
 

This object stores references to the request and response objects for each request.
The application, config, session, and out objects are derived by accessing attributes of
this object. The pageContext object also contains information about the directives
issued to the JSP page, including the buffering information, the errorPageURL, and
page scope. The pageContext object does more than just act as a data repository. It is
this object that manages nested JSP pages, performing most of the work involved with
the forward and include actions. The pageContext object also handles uncaught
exceptions.
 

From the perspective of the JSP author this object is useful in deriving information
about the current JSP page's environment. This can be particularly useful in creating
components where behavior may be different based on the JSP page directives

• The session object

The session object is used to track information about a particular client while using
stateless connection protocols, such as HTTP. Sessions can be used to store arbitrary
information between client requests.
 

Each session should correspond to only one client and can exist throughout multiple
requests. Sessions are often tracked by URL rewriting or cookies, but the method for
tracking of the requesting client is not important to the session object.
The session object is an instance of javax.servlet.http.HttpSession and behaves exactly
the same way that session objects behave under Java Servlets.
 

• The application Object

The application object is direct wrapper around the ServletContext object for the
generated Servlet. It has the same methods and interfaces that the ServletContext
object does in programming Java Servlets.
 

This object is a representation of the JSP page through its entire lifecycle. This object
is created when the JSP page is initialized and will be removed when the JSP page is
removed by the jspDestroy() method, the JSP page is recompiled, or the JVM crashes.
Information stored in this object remains available to any object used within the JSP
page.
 

The application object also provides a means for a JSP to communicate back to the
server in a way that does not involve “requests”. This can be useful for finding out
information about the MIME type of a file, sending log information directly out to the
servers log, or communicating with other servers.

 • The config Object

The config object is an instantiation of javax.servlet.ServletConfig. This object is a
direct wrapper around the ServletConfig object for the generated servlet. It has the
same methods and interfaces that the ServletConfig object does in programming Java
Servlets. This object allows the JSP author access to the initialisation parameters for
the Servlet or JSP engine. This can be useful in deriving standard global information,
such as the paths or file locations.
 

• The page Object

This object is an actual reference to the instance of the page. It can be thought of as an
object that represents the entire JSP page. When the JSP page is first instantiated the
page object is created by obtaining a reference to this object. So, the page object is
really a direct synonym for this object.
However, during the JSP lifecycle, this object may not refer to the page itself. Within
the context of the JSP page, the page object will remain constant and will always
represent the entire JSP page.
 

• The exception Object

The error handling method utilises this object. It is available only when the previous
JSP page throws an uncaught exception and the <%@ pageerrorPage= “ ...” %> tag
was used. The exception object is a wrapper containing the exception thrown from the
previous page. It is typically used to generate an appropriate response to the error
condition.