She wants to listen for a context initialization event, so that she can get the context init parameters and run some code before the rest of the app can service a client.

She needs something that can be sitting there, waiting to be notified that the app is starting up.

But which part of the app could do the work? You don’t want to pick a servlet—that’s not a servlet’s job.

There’s no problem in a plain old standalone Java app, because you’ve got main()! But with a servlet, what do you do?

You need something else. Not a servlet or JSP, but some other kind of Java object whose sole purpose in life is to initialize the app (and possibly to uninitialize it too, cleaning up resources when it learns of the app’s demise...).

We can make a separate class, not a servlet or JSP, that can listen for the two key events in a ServletContext’s life—initialization (creation) and destruction. That separate class implements javax.servlet.ServletContextListener.

javax.servlet.ServletContextListener

We need a separate object that can:

A ServletContextListener class:

Now we’ll walk through the steps of making and running a ServletContextListener. This is just a simple test class so that you can see how all the pieces work together; we’re not using the database connection example because you’d have to set up a database to make it work. But the steps are the same regardless of the code you put in your listener callback methods.

In this example, we’ll turn a String init parameter into an actual object—a Dog. The listener’s job is to get the context init parameter for the dog’s breed (Beagle, Poodle, etc.), then use that String to construct a Dog object. The listener then sticks the Dog object into a ServletContext attribute, so that the servlet can retrieve it.

The point is that the servlet now has access to a shared application object (in this case a Dog), and doesn’t have to read the context parameters. Whether the shared object is a Dog or a database connection doesn’t matter. The key is to use the init parameters to create a single object that all parts of the app will share.

In this example, we’ll put a Dog into a ServletContext.

Our Dog example:

Maybe you’re still wondering how the Container discovers and uses the listener... You configure a listener the same way you tell the Container about the rest of your web app—through the web.xml Deployment Descriptor!

For our context listener test example, we need to write the classes and the web.xml file.

For ease of testing, we’ll put all of the classes in the same package: com.example

It works just like other types of listeners you might be familiar with, such as Swing GUI event handlers. Remember, all we need to do is get the context init parameters to find out the dog breed, make the Dog object, and put the Dog into the context as an attribute.

Oh yeah, we need a Dog class—the class representing the object we’re going to store in the ServletContext, after reading the context init parameters.

This is the class that tests the ServletContextListener. If everything is working right, by the time the Servlet’s doGet() method runs for the first time, the Dog will be waiting as an attribute in the ServletContext.

Now we tell the Container that we have a listener for this app, using the <listener> element. This element is simple—it needs only the class name. That’s it.

This is the web.xml file inside the WEB-INF directory for this web app.

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

  <servlet>
    <servlet-name>ListenerTester</servlet-name>
    <servlet-class>com.example.ListenerTester</servlet-class>
  </servlet>

  <servlet-mapping>
    <servlet-name>ListenerTester</servlet-name>
    <url-pattern>/ListenTest.do</url-pattern>
  </servlet-mapping>

  <context-param>
    <param-name>breed</param-name>
    <param-value>Great Dane</param-value>
  </context-param>

  <listener>
    <listener-class>
       com.example.MyServletContextListener
    </listener-class>
  </listener>

</web-app>

Let’s get it all working. The steps are:

Bring up your browser and let’s hit the servlet directly. We didn’t bother making an HTML page, so we’ll access the servlet by typing in the URL from the servlet mapping in the DD (ListenTest.do).

If you get a NullPointerException, you didn’t get a Dog back from getAttribute(). Check the String name used in setAttribute() and make sure it matches the String name you’re using in getAttribute().

Recheck your web.xml and make sure the <listener> is registered.

Try looking at the server logs and see if you can find out if the listener is actually being called.

To make it as confusing as possible, we gave everything a subtly different name. We want to make sure you’re paying attention to how these names are used, and when you name everything the same, it’s tough to tell how the names affect your app.

Servlet class name: ListenerTester.class

Web app directory name: listenerTest

URL pattern mapped to this servlet: ListenTest.do

Here’s the scenario from start (app initialization) to finish (servlet runs). You’ll see in step 11 we condensed the Servlet initialization into one big step.

Where there’s a lifecycle moment, there’s usually a listener to hear about it. Besides context events, you can listen for events related to context attributes, servlet requests and attributes, and HTTP sessions and session attributes.

Exercise

Pick the Listener

Match the scenario on the left with the listener interface (at the bottom of the page) that supports that goal. Use each interface only once. (Yes, we KNOW we haven’t looked at these yet. See what you can come up with just by looking at the names. Answers are on the next page, so don’t peek!)

Scenario	Listener interface
You want to know if an attribute in a web app context has been added, removed, or replaced.	_______________________________________________________________________
You want to know how many concurrent users there are. In other words, you want to track the active sessions.	_______________________________________________________________________
You want to know each time a request comes in, so that you can log it.	_______________________________________________________________________
You want to know when a request attribute has been added, removed, or replaced.	_______________________________________________________________________
You have an attribute class (a class for an object that will be put in an attribute) and you want objects of this type to be notified when they are bound to or removed from a session.	_______________________________________________________________________
You want to know when a session attribute has been added, removed, or replaced.	_______________________________________________________________________

Choose from these listener interfaces. Use each listener only once.

You might be confused about the difference between an HttpSessionBindingListener and an HttpSessionAttributeListener. (Well, not you, but someone you work with.)

A plain old HttpSessionAttributeListener is just a class that wants to know when any type of attribute has been added, removed, or replaced in a Session. But the HttpSessionBindingListener exists so that the attribute itself can find out when it has been added to or removed from a Session.

package com.example;

import javax.servlet.http.*;

public class Dog implements HttpSessionBindingListener {
   private String breed;

   public Dog(String breed) {
     this.breed=breed;
   }

   public String getBreed() {
     return breed;
   }
   public void valueBound(HttpSessionBindingEvent event) {
     // code to run now that I know I'm in a session
   }

   public void valueUnbound(HttpSessionBindingEvent event) {
     // code to run now that I know I am no longer part of a session
   }
}

Exercise

Remembering the Listeners

Do your best to fill in the slots in this table. Keep in mind that the listener interfaces and methods follow a consistent naming pattern (mostly).

Answers are at the end of the chapter.

Attribute listeners
Other lifecycle listeners
Methods in all attribute listeners (except binding listener)
Lifecycle events related to sessions (excluding attribute-related events)
Lifecycle events related to requests (excluding attribute-related events)
Lifecycle events related to servlet context (excluding attribute-related events)