Informal Survey - Use of Listeners

[Bert Bates]

Hey Servlet / JSP campers!
We'd like to compile a list of real-world examples of using the various (what are there, about 812?), listener interfaces and classes in the javax.servlet and javax.servlet.http packages. So, for instance, who's ever used HttpSessionAttributeListener, and why did you use it? How about the other 'attribute' listeners? Tell us your stories! (You might get 15 minutes of fame in the upcoming Head First Servlets book!)
Thanks,
Bert

[Chris Mathews]

I increasingly use ServletContextListeners to load configuration information at server startup. It sure beats the ole Servlet with a load-on-startup=1 trick or at least it feels like less of a hack to me.

[Chris Mathews]

I've also found HttpSessionListener useful for doing things like tracking which users are currently online.

[Bear Bibeault]

What Chris said, and what Chris said, These are the two uses to which I have put listeners.

[Kyle Brown]

In one financial planning application we used the HttpSessionListener (specifically on valueUndound when the session died) to record information that a user had entered on a long-running process into a relational database keyed by their userid. Then even though the session died, and they were forced to log back in to the application as a result, we could fetch back their application state and redirect them to the right page to let them continue where they left off.
Kyle
[ April 09, 2004: Message edited by: Kyle Brown ]

[Bert Bates]

Cool start! I guess I'd agree that HttpSession and ServletContext are probably the most frequently used...
Has anyone ever used SessionBinding in real life?
How about any of the XxxxxAttribute listeners?
Does anybody use SessionActivation? Do you worry about your sessions getting passivated?

[rick zorich]

Try this listener. But, please be careful, you will throw a java.lang.StackOverflowError if you let the count go too high. Maybe someone will post code to catch it gracefully.

package pack1;   
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class RequestTimer implements ServletRequestListener {
  Hashtable table;
  public RequestTimer(){
                        table = new Hashtable();
  }
  public void requestInitialized(ServletRequestEvent sre) {
               HttpServletRequest request = (HttpServletRequest)sre.getServletRequest();
               table.put(request,new Long(System.currentTimeMillis()));
  }
  public void requestDestroyed(ServletRequestEvent sre) {
               HttpServletRequest request = (HttpServletRequest)sre.getServletRequest();
               long time = System.currentTimeMillis() - ((Long)table.get(request)).longValue();
               table.remove(request);
               request.getSession().setAttribute("lastRequest",new Long(time));
  }
}

For testing you could use the following two JSPs.
A.jsp

<%
      Integer count = (Integer)request.getAttribute("count");
      if(count==null){
                  count = new Integer(0);
                  request.setAttribute("count",count);
      }
      if(count.intValue()<=10){       
                            pageContext.forward("B.jsp");
      }  
      Long lastRequest = (Long)session.getAttribute("lastRequest");
      if(lastRequest!=null){
           out.print("Duration of last request in milliseconds "
                                        + lastRequest.longValue());
      }else{out.print("hello");}
%>   

and B.jsp

<%
      Integer count = (Integer)request.getAttribute("count");
      request.setAttribute("count",new Integer(count.intValue() + 1));
      pageContext.forward("A.jsp");
%>      

[rick zorich]

The first time you request A.jsp, the output is "hello". Refresh it couple times to see different times.

[Ray Stojonic]

I used an HttpSessionBindingListener to maintain a context level record locking device.
The basics:
user1 opens record1 to edit some information, listener is added to their session and entry made in lock minder.
user2 attempts to open record1 to edit some information, lock minder reports record1 is already open for editing, so user2 receives the option to be notified when the record1 becomes available, record opens in read-only mode.
user1 logs out/closes record/times out, listener removes entry from lock minder and unlocks record in database (forgot to mention that above...), user2 receives an email letting them know they may now edit the record.