Overview of JSP Page Semantics

 

Overview of JSP Page Semantics

ü 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. 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 samelife-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 development of the JSP page into the runtime environment of 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.

 

ü 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.

 

ü 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 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 what reference is removed.

 

The created objects may also be visible directly to the scripting elements through some scripting-level 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 JSP page or the request is forwarded somewhere else. References to objects with page scope are stored in the pageContext object.

 

ü Request

Object 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 . 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 they 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 not enforce this rule explicitly due to performance reasons.