I’ve mentioned the UserContainer and ApplicationContainer classes in previous chapters without defining exactly what they are. These two classes are not part of the Struts framework—I created them as part of the example Storefront application. The purpose of these classes is to store user and application-specific information in instances of these classes, rather than in the HttpSession and ServletContext objects, respectively.

One of the problems with storing data in the HttpSession is that the interface to store and retrieve data from the session object is not strongly typed. In other words, the interface for any data is:

public void setAttribute( "permissionsKey", permissions );
public Object getAttribute( "permissionsKey" );

The client must be aware of the key at which the data is stored in order to put an object into or retrieve an object from storage. Some programmers prefer a more strongly typed interface instead:

userContainer.setPermissions( permissions );
userContainer.getPermissions(  );

Here, the client doesn’t have to worry about what key the object is being stored under or how it’s being stored. It can be an HttpSession object or some other data store; the client is not made aware of this because it’s not forced to use the methods of the HttpSession directly.

There’s nothing really complicated about the UserContainer class itself. It’s an ordinary JavaBean that contains instance variables, along with public getters and setters for the properties. Example 9-5 illustrates a basic UserContainer class.

package com.oreilly.struts.storefront.framework;
import java.util.Locale;
import javax.servlet.http.HttpSessionBindingListener;
import javax.servlet.http.HttpSessionBindingEvent;
import com.oreilly.struts.storefront.customer.view.UserView;

/**
 * Used to store information about a specific user. This class is used
 * so that the information is not scattered throughout the HttpSession.
 * Only this object is stored in the session for the user. This class
 * implements the HttpSessionBindingListener interface so that it can
 * be notified of session timeout and perform the proper cleanup.
 */
public class UserContainer implements HttpSessionBindingListener {

  // The user's shopping cart
  private ShoppingCart cart = null;
  //  Data about the user that is cached
  private UserView userView = null;

  /**
   * The Locale object for the user. Although Struts stores a Locale for
   * each user in the session, the locale is also maintained here.
   */
  private Locale locale;

  public UserContainer(  ) {
    super(  );
    initialize(  );
  }

  public ShoppingCart getCart(  ) {
    return cart;
  }

  public void setCart(ShoppingCart newCart) {
    cart = newCart;
  }

  public void setLocale(Locale aLocale) {
    locale = aLocale;
  }

  public Locale getLocale(  ) {
    return locale;
  }

  /**
   * The container calls this method when it is being unbound from the
   * session.
   */
  public void valueUnbound(HttpSessionBindingEvent event) {
    // Perform resource cleanup
    cleanUp(  );
  }

  /**
   * The container calls this method when it is being bound to the
   * session.
   */
  public void valueBound(HttpSessionBindingEvent event) {
    // Don't need to do anything, but still have to implement the
    // interface method.
  }

  public UserView getUserView(  ) {
    return userView;
  }

  public void setUserView(UserView newView) {
    userView = newView;
  }

  /**
   * Initialize all of the required resources
   */
  private void initialize(  ) {
    // Create a new shopping cart for this user
    cart = new ShoppingCart(  );
  }

  /**
   * Clean up any open resources. The shopping cart is left intact
   * intentionally.
   */
  public void cleanUp(  ) {
    setUserView( null );
  }
}

One thing to notice is that the UserContainer class in Example 9-5 implements the HttpSessionBindingListener interface. The methods of this interface allow the UserContainer to be notified when it is bound to and unbound from the session. This allows it to perform any necessary cleanup on the object. An instance of the UserContainer is created for each new user at the time the user enters the application. The UserContainer object itself is stored in the session, and it must have the duration of the session. If the user exits and re-enters the site, a new UserContainer typically is created for that user.

The ApplicationContainer is used for a similar purpose, but at the application level, not the session level. It’s useful for storing or caching information that is needed by all users across the application. Things such as selection lists, configuration properties, and other non-client-specific data that you need to get once and hold on to are candidates for the ApplicationContainer class. This class is created when the application is first started and destroyed when the application exits.