The AffableBean application uses the HttpSession object to identify users over multiple requests. An HttpSession object is obtained using getSession() on a given request:

If a session object doesn’t yet exist for the request, the method creates and returns a new session object.

You can use the session object as a vehicle for passing data between requests. You use the setAttribute method to bind objects to the session. Likewise, you use getAttribute to retrieve objects from the session. In the AffableBean application for example, the user’s shopping cart is created and bound to the user session in the following manner:

In order to retrieve the cart from the session, the getAttribute method is applied:

In JSP pages, you can access objects bound to the session using EL expressions. Continuing with the above example, if a ShoppingCart object named ‘cart’ is bound to the session, you can access the object using the following EL expression:

Accessing the ShoppingCart object on its own is of little value however. What you really want is a way to access values stored in the object. If you explore the new ShoppingCart class in the project snapshot, you’ll note that it contains the following properties:

Provided that properties have matching getter methods, you can access values for singular properties using simple dot notation in an EL expression. If you examine the cart.jsp page, you’ll see that this is exactly how the value for numberOfItems is accessed:

In order to extract data from properties that contain multiple values, such as the above items list, the cart.jsp page uses a <c:forEach> loop:

ShoppingCartItem’s `product property identifies the product type for a cart item. The above loop takes advantage of this by first setting a product variable to the expression ${cartItem.product}. It then uses the variable to obtain information about that product (e.g., name, price).

When working with JSP/Servlet technology, there are four scope objects available to you within the realm of the application. JSP technology implements implicit objects that allows you to access classes defined by the Servlet API.

If you open your project’s category.jsp file in the editor, you’ll see that EL expressions include various scoped variables, including ${categories}, ${selectedCategory} and ${categoryProducts}. The ${categories} variable is application-scoped, which is set in the ControllerServlet’s `init method:

The other two, ${selectedCategory} and ${categoryProducts}, are placed in the application’s session scope from the ControllerServlet. For example:

Note: If you are continuing from the previous tutorial units, you’ll likely note that ${selectedCategory} and ${categoryProducts} were originally placed in the request scope. In previous units this was fine, but consider now what happens if a user clicks the 'add to cart' button in a category page. The server responds to an addToCart request by returning the currently viewed category page. It therefore needs to know the selectedCategory and the categoryProducts pertaining to the selected category. Rather than establishing this information for each request, you place it in the session scope from a category request so that it is maintained across multiple requests, and can be accessed when you need it. Also, examine the functionality provided by the cart page. (A functional description is provided below.) The 'continue shopping' button returns the user to the previously viewed category. Again, the selectedCategory and the categoryProducts variables are required.

When referencing scoped variables in an EL expression, you do not need to specify the variable’s scope (provided that you do not have two variables of the same name in different scopes). The JSP engine checks all four scopes and returns the first variable match it finds. In category.jsp for example, you can use the following expression:

This expression is shorthand for the following expression:

For more information, see the following resources:

To toggle line numbers for the editor, right-click in the left margin and choose Show Line Numbers.

You can view and modify the debug port number from the Servers window (Tools > Servers). Select the Java tab for the server you are using. Specify the port number in the 'Address to use' field under Debug Settings.

As you may recall from Preparing the Page Views and Controller Servlet, the ControllerServlet’s `doPost method handles requests for the /addToCart URL pattern. You can therefore expect that when a user clicks an 'add to cart' button, the doPost method is called.

According to the documentation, getSession() returns the HttpSession currently associated with the request, and if no session exists, the method creates a new session object.

The IDE provides built-in Javadoc support for Java EE development. The IDE bundles with the Java EE 6 API Specification, which you can open in an external browser by choosing Help > Javadoc References > Java EE 6.

The IDE also includes various other features that enable easy access to API documentation:

When you document your own work, consider adding Javadoc comments to your classes and methods. Open the ShoppingCart class and examine the Javadoc comments added to the class methods. Javadoc comments are marked by the /** …​ */ delimiters. For example, the addItem method has the following comment before its signature:

This enables you (and others working on the project) to view Javadoc documentation on the method. To demonstrate, open the Navigator (Ctrl-7; ⌘-7 on Mac) and hover your mouse over the addItem method.

You can also use the IDE to generate a set of Javadoc HTML pages. In the Projects window, right-click your project node and choose Generate Javadoc. The IDE generates the Javadoc in the dist/javadoc folder of your project’s directory and opens the index page in the browser.

For more information on Javadoc, see the following resources:

In NetBeans 6.9, you can click the grey pointer ( ) in the popup to expand a list of variable values contained in the highlighted element.

Press Alt-Shift-3 (Ctrl-Shift-3 on Mac) to open the IDE’s Call Stack window.

Line 161 of the ControllerServlet binds the newly-created cart object to the session.

To witness this, open the debugger’s Variables window. Choose Window > Debugging > Variables, or press Alt-Shift-1 (Ctrl-Shift-1 on Mac).

If you expand the session > session > attributes node, you are able to view the objects that are bound to the session. In the above image, there are two items currently bound to the session (highlighted). These are selectedCategory and categoryProducts, instantiated in the ControllerServlet at lines 83 and 89, respectively. Both of these items were bound earlier, when you clicked a category image, and the ControllerServlet processed the category page request.

So far, we have not "proven" that the session, as listed in the Variables window, represents an HttpSession. As previously mentioned, HttpSession is actually an interface, so when we talk about an HttpSession object, or session object, we are in fact referring to any object that implements the HttpSession interface. In the Variables window, if you hover your cursor over ‘session’, a popup displays indicating that the variable represents an HttpSession object. The StandardSessionFacade type, as displayed, is the internal class that GlassFish uses to implement the HttpSession interface. If you are familiar with Tomcat and are puzzled by the ‘org.apache.catalina’ paths that appear in the Value column, this is because the GlassFish web/servlet container is in fact a derivative of the Apache Tomcat container.

A new ShoppingCart is added to the session, and the request continues to be processed. In order to complete implementation of the 'add to cart' functionality, the following actions are taken: * the ID of the selected product is retrieved from the request (line 165) * a Product object is created using the ID (line 169) * a new ShoppingCartItem is created using the product (line 170) * the ShoppingCartItem is added to ShoppingCart’s `items list (line 170)

Alternatively, you can place your cursor on the session variable in the editor, then right-click and choose New Watch. The New Watch dialog enables you to specify variables or expressions to watch continuously when debugging an application. (In the case of expressions, highlight the expression first, then right-click and choose New Watch.)

A new watch is created on the session variable and all variables it contains. The watch is visible from the Watches window (Window > Debugging > Watches) or, if you toggle the Watches ( ) button in the left margin of the Variables window, it displays in the top row of the Variables window.

The debugger enables you to keep an eye on variables as it steps through code. This can be helpful, for example if you’d like to follow changes to specific variable values (and don’t want to need to sift through the full list presented in the Variables window with each step), or if you temporarily step into a class that doesn’t contain the variables you are interested in.

At this stage, you can see how an HttpSession is created for the request, how a ShoppingCart object is created and attached to the session, and how a ShoppingCartItem is created based on the user’s product choice, then added to the ShoppingCart’s list of `items. The only remaining action is to forward the request to the category.jsp view.

Note: In order to suspend the debugger in a JSP page, you need to set a breakpoint. For example, when the ControllerServlet forwards the request to the appropriate view, the debugger will not automatically suspend within the JSP page.

Maximize the Variables window, or any window in the IDE, by right-clicking the window header, then choosing Maximize Window (Shift-Esc).

The debugger gives you access to the pageContext implicit object. pageContext represents the context of the JSP page, and offers direct access to various objects including the HttpServletRequest, HttpSession, and ServletContext objects. For more information, see the Java EE 5 Tutorial: Implicit Objects.

Hopefully you now feel comfortable using the IDE’s debugger not only to examine your project when it behaves unexpectedly, but also as a tool to become more familiar with code. Other useful buttons in the debugger toolbar include:

By default, the servlet engine uses cookies to maintain and identify sessions between requests. A random, alphanumeric number is generated for each session object, which serves as a unique identifier. This identifier is passed as a ‘JSESSIONID’ cookie to the client. When the client makes a request, the servlet engine reads the value of the JSESSIONID cookie to determine the session which the request belongs to.

To demonstrate this, we’ll use the debugger in tandem with the IDE’s HTTP Monitor.

You may wonder how a session object was created from a request for the site welcome page. After all, the ControllerServlet does not handle the initial request for /AffableBean/, and nowhere does this request encounter getSession(). Or does it? Recall that JSP pages are compiled into servlets upon deployment. Once you’ve deployed your project to the server, you can actually use the IDE to view the JSP’s compiled servlet on your server.

Ctrl-F (⌘-F on Mac) is a keyboard shortcut for Edit > Find.

The getSession method is in fact called. The reason this occurs is because JSP pages include the pageContext.session implicit object by default. If you wanted to deactivate this behavior, you could add the following directive to the top of a JSP file:

If you add the directive the getSession method will be removed in the compiled servlet.

To find out the location of the compiled servlet on your server, you can hover your mouse over the servlet’s name tab above the editor. A popup displays the path to the file on your computer.

From the Breakpoints window, you can view and call actions on all breakpoints set in projects opened in the IDE.

Click the Ascending Sort ( ) button so that the most recent records are listed at the top.

Under the Request tab, note the requested URI (/AffableBean/addToCart), the HTTP method (POST), and the request parameters (productId and submit).

Likewise, if you click the Header tab, you see the cookie listed, since ‘Cookie’ is a request header that was sent by the client.

See Wikipedia’s List of HTTP headers for more information on request and response headers.

In the next few steps, locate the session ID and JSESSIONID cookie in the Variables window.

As mentioned, the servlet engine detects whether cookies are supported for the client browser, and if not, it switches to URL rewriting as a means of maintaining sessions. This all happens transparently for the client. For you, the developer, the process isn’t entirely transparent.

You need to ensure that the application is capable of rewriting URLs whenever cookies are disabled. You do this by calling the response’s encodeURL method on all URLs returned by servlets in your application. Doing so enables the session ID to be appended to the URL in the event that the use of cookies is not an option; otherwise, it returns the URL unchanged.

For example, the browser sends a request for AffableBean’s third category (bakery): `category?3. The server responds with session ID included in the URL:

As stated above, all URLs returned by your application’s servlets must be encoded. Keep in mind that JSP pages are compiled into servlets. How can you encode URLs in JSP pages? JSTL’s `<c:url>` tag serves this purpose. The following exercise demonstrates the problem and illustrates a solution.

As before, the server generates a session and binds objects to it. This is how the category page is able to display the selected category and products. However, the server has failed in its attempt to set a JSESSIONID cookie. Therefore, when the client makes a second request (when user clicks 'add to cart'), the server has no way of identifying the session which the request belongs to. It therefore cannot locate any of the attributes previously set in the session, such as selectedCategory and categoryProducts. This why the rendered response lacks the information specified by these attributes.

Again, every link that a user is able to click on within the application, whose response requires some form of session-related data, needs to be properly encoded. Sometimes implementation is not as straight-forward as the example shown above. For example, the 'clear cart' widget used in cart.jsp currently sets a clear parameter to true when the link is clicked.

The <c:url> tag can be applied to the URL in the following manner:

The clear=true parameter is set by adding a <c:param tag between the <c:url> tags. A variable named ‘url’ is set using <c:url>'s var attribute, and var is then accessed in the HTML anchor tag using the ${url} expression.

You can download and examine snapshot 6 to see how all links in the project have been encoded.

URL rewriting should only be used in the event that cookies are not an available tracking method. URL rewriting is generally considered a suboptimal solution because it exposes the session ID in logs, bookmarks, referer headers, and cached HTML, in addition to the browser’s address bar. It also requires more server-side resources, as the server needs to perform additional steps for each incoming request in order to extract the session ID from the URL and pair it with an existing session.

You should consider the maximum time interval which your server maintains sessions for. If your website receives heavy traffic, a large number of sessions could expend your server’s memory capacity. You might therefore shorten the interval in hopes of removing unused sessions. On the other hand, you certainly wouldn’t want to cut sessions too short, as this could become a usability issue that might have a negative impact on the business behind the website. Taking the AffableBean application as an example, a user proceeds to checkout after filling her shopping cart with items. She then realizes she needs to enter her credit card details and goes off to find her purse. After returning to her computer with credit card in hand, she fills in the checkout form and clicks submit. During this time however, her session has expired on the server. The user sees that her shopping cart is empty and is redirected to the homepage. Will she really take the time to step through the process again?

The following steps demonstrate how to set the session time-out interval in the AffableBean project to 10 minutes. Of course, the actual duration ultimately depends on your server resources, the business objectives of the application, and the popularity of your website.

The editor displays the web.xml file in the XML view. The template that NetBeans provides for the web.xml file includes a default setting for 30 minutes.

If you switch back to the XML view, you’ll see that the <session-timeout> element has been updated.

Note: Alternatively, you could remove the <session-timeout> element altogether, and edit the session-properties element in the GlassFish-specific deployment descriptor (sun-web.xml). This would set the global time-out for all applications in the server’s web module. See the Oracle GlassFish Server 3.0.1 Application Development Guide: Creating and Managing Sessions for more details.

If your application relies on sessions, you need to take measures to ensure that it can gracefully handle situations in which a request is received for a session that has timed out or cannot be identified. You can accomplish this in the AffableBean application by creating a simple filter that intercepts requests heading to the ControllerServlet. The filter checks if a session exists, and if not, it forwards the request to the site’s welcome page.

The server log indicates that a NullPointerException occurred at line 184 in the ControllerServlet. The Output window forms a link to the line where the exception occurred.

Because the session had already expired before the request was received, the servlet engine was unable to associate the request with its corresponding session. It was therefore unable to locate the cart object (line 151). The exception finally occurred in line 184 when the engine attempted to call a method on a variable equating to null.

Now that we’ve identified the problem, let’s fix it by implementing a filter.

Note: Currently, in NetBeans 6.9, it isn’t possible to use the wizard to set a mapping to a servlet that isn’t registered in the web deployment descriptor. (ControllerServlet was registered using the @WebServlet annotation.) We’ll therefore modify the generated code in the next step.

This sets the filter to intercept any requests that are handled by the ControllerServlet. (Alternatively, you could have kept the urlPatterns attribute, and listed all patterns that the ControllerServlet handles.)

Note that ‘Controller’ is the name of the ControllerServlet, as specified in the servlet’s @WebServlet annotation signature. Also note that you’ve removed the filterName attribute, since the name of the filter class is used by default.

The IDE’s filter template provides a lot of interesting code which is worth inspecting in its own right. However, most of it is not needed for our purposes here. Any filter class must implement the Filter interface, which defines three methods: * init: performs any actions after the filter is initialized but before it is put into service * destroy: removes the filter from service. This method can also be used to perform any cleanup operations. * doFilter: used to perform operations for each request the filter intercepts

Use the Javadoc Index Search to pull up documentation on the Filter interface. Press Shift-F1 (fn-Shift-F1 on Mac), then type ‘Filter’ into the search field and hit Enter. Select the 'Interface in javax.servlet' entry. The Javadoc documentation displays in the lower pane of the index search tool.

In the coming steps, you run the debugger on the project and step through the doFilter method to see how it determines whether the request is bound to an existing session.

Recall that getSession() creates a new session object if the current one doesn’t exist. Here, we use getSession(false), which refrains from creating a new object if none is found. In other words, the method returns null if the session doesn’t exist.

Snapshot 6 provides you with the completed project version for this tutorial unit. One final topic concerning session management should be mentioned. You can explicitly terminate a session by calling the invalidate method on the session object. If the session is no longer needed, it should be removed in order to conserve the memory available to your server. After you complete the next unit, Integrating Transactional Business Logic, you will see how the ControllerServlet, upon successfully processing a customer order, destroys the user’s cart object and terminates the session using the invalidate method.

This is demonstrated in project snapshot 8 (and later snapshots).

Send Feedback on This Tutorial