Object Scoping with JSP

Another feature that JSP and servlets bring to the table is the idea of object persistence across HTTP requests . When a browser first connects to a server, a session is established that is uniquely connected to that client. This allows information to be available from one request to the next , making it seem to the user as if all the requests were part of one session.

HOW ARE SESSIONS TRACKED?

When a client makes a request to a JSP server, how does the server associate the client with a specific session? The answer is, it depends.

If the client browser has enabled session cookies (that is, cookies that are kept only as long as the browser is running and are lost on shutdown), they are used to track the session. On first contact, a new session cookie is generated and sent to the client. Each subsequent request will include the cookie, allowing the server to make the match.

Some users, out of paranoia or ignorance, have disabled session cookies. This requires the server to adopt a different strategy ”URL rewriting. Under this scheme, every form and HREF are rewritten before being sent to the client so that a unique session token is included. For example, the HREF foo.jsp might be rewritten as foo.jsp?sessionid=24234235 .

Obviously, this is a much less aesthetic approach and is used by the server only as a last resort.

There are several ways that a developer can gain access to these persistent objects. For example, the session object is available by calling the getSession() method on an HttpRequest object. Listings 5.5 and 5.6 show examples of two JSP pages; the first page sets a value, and the second retrieves it later in the session.

Listing 5.5 setvalue.jsp

 <% request.getSession().setAttribute("myage", new Integer(39)); %> <H2>Value Set</H2> 

Listing 5.6 getvalue .jsp

 <H2> Age = <%= request.getSession().getAttribute("myage") %> </H2> 

As expected, after loading the first page, you get this in your browser:

 Value Set 

Then, when you load getvalue.jsp , it displays

 Age = 39 

The first page gets a reference to the session object from the request, and then uses the setAttribute call to establish a persistent value. The second page uses the getAttribute call to retrieve the previously stored value.

Scopes Other than Session Scoping

Although session-scoped objects are by far the most frequently used, three other types of scoping are available.

A page-scoped object is available only on the specific JSP page on which it is referenced. You can think of it as a local variable of the jspRequest() method for the Java class created from the JSP source.

A request-scoped object is available during the life of the current request/reply cycle. It is somewhat like a page-scoped object, but would be available (for example) if one JSP page used a redirect to send the browser to another JSP page.

Finally, an application-scoped object is available to any request in the current Web application. These objects are most frequently used to store information that's required globally. For example, information that's being cached by the application for fast access would be a good candidate to be application-scoped .

Accessing Scoped Objects from JSP

Although you've already seen how you can access a session-scoped object from the request parameter, this is more often used from Java code that's called from a JSP page. On a JSP page itself, it is preferable to use a JSP tag: the useBean tag. Listings 5.7 and 5.8 provide an example of this tag, as well as demonstrate how each of the scopes behaves.

Listing 5.7 page1.jsp

 <jsp:useBean id="pagevar" scope="page" class="java.lang.StringBuffer"/> <jsp:useBean id="requestvar" scope="request" class="java.lang.StringBuffer"/> <jsp:useBean id="sessionvar" scope="session" class="java.lang.StringBuffer"/> <jsp:useBean id="appvar" scope="application" class="java.lang.StringBuffer"/> <% pagevar.append("page1");    requestvar.append("page1");    sessionvar.append("page1");    appvar.append("page1"); %> <jsp:forward page="page2.jsp"/> 

Listing 5.8 page2.jsp

 <jsp:useBean id="pagevar" scope="page" class="java.lang.StringBuffer"/> <jsp:useBean id="requestvar" scope="request" class="java.lang.StringBuffer"/> <jsp:useBean id="sessionvar" scope="session" class="java.lang.StringBuffer"/> <jsp:useBean id="appvar" scope="application" class="java.lang.StringBuffer"/> <% pagevar.append("page2");    requestvar.append("page2");    sessionvar.append("page2");    appvar.append("page2"); %> page = <%= pagevar.toString() %><BR> request = <%= requestvar.toString() %><BR> session = <%= sessionvar.toString() %><BR> appvar = <%= appvar.toString() %><BR> 

If you request page1.jsp , you'll get the requests shown here:

 page = page2 request = page1page2 session = page1page2 appvar = page1page2 

As you can see, the request, session, and application versions of the StringBuffer are the same on both page1 and page2 ( page1 does a forward, too). But because the page scope works only for a physical JSP page, page1 and page2 are each given a new copy of the StringBuffer for pagevar , and only page2 is printed as its value.

If you then load page2.jsp explicitly, you'll see the following:

 page = page2 request = page2 session = page1page2page2 appvar = page1page2page2 

Because this is a different request, the page and request values are new, but the session and application values carry over from the last request. Finally, if a different user were to request page2 , he would see

 page = page2 request = page2 session = page2 appvar = page1page2page2 page2 

These are different sessions, but the value associated with the application still remains.