Fabulous!! Thanks Craig! Much appreciated. --Pinghua
On Tuesday, Oct-05-1999 15:29 PM (PDT) [EMAIL PROTECTED] (Craig McClanahan)
wrote:
|> Pinghua Young wrote:
|>
|> > Craig, I think you probably misunderstood my question. Our application
|> > has a requirement to clear some data stored in a user's session when
|> > an external event occurs. Or more precisely, here's what happens:
|> >
|> > #1. An external event occurs (eg weather goes bad);
|> > #2. It notifies one servlet housed in our web servlet application,
|> > and sends along a userID;
|> > #3. This servlet of ours then has to find out if this user is login
|> > to our web server or not;
|> > #4. If yes, then clear the data from his session, so that new data
|> > can be retrieved from database;
|> >
|> > With the current servlet API, I just can't seem to be able to do
|> > what I want without some sort of problems.
|> >
|>
|> There are several ways to approach a problem like this that don't require you to
|scan through the list of
|> active sessions (and that's good, because the mechanism to do so got removed in
|2.1). Here's one way that is
|> consistent with the usual JavaBeans design patterns (see the JavaBeans
|specification for more information):
|>
|> * The servlet that receives notifications about weather
|> changes is, or is associated with, an object that allows
|> you to register interest in hearing about events. Using
|> the usual JavaBeans naming patterns, you might have
|> methods like addWeatherChangeListener and
|> removeWeatherChangeListener.
|>
|> * When a user logs on, one of the things you do
|> is store a new instance of a particular bean
|> (let's call it LoginBean) in the user's session.
|>
|> * This LoginBean implements HttpSessionBindingListener,
|> so it's valueBound() method gets called when this object
|> is added to a user session. One of the things that you get
|> in the event argument is a reference to the session you just
|> got added to -- save this in a local instance variable inside
|> the LoginBean.
|>
|> * When the valueBound() method is called, this object should
|> also register itself as an event listener for WeatherChangeEvent
|> events. This is done by calling the addWeatherChangeListener
|> method of the registration object described earlier.
|>
|> * Whenever your servlet receives a weather change notification,
|> it constructs a WeatherChangeEvent and sends it along to
|> all the interested listeners (i.e. the LoginBean instances that
|> have registered themselves). Each receiver of the event can
|> look at the other properties of the event (such as the username)
|> to decide whether or not it is interested. Note that each receiver
|> can apply their own rules to decide what events are relevant --
|> you no longer have to centralize this decision as you would in a
|> model where the event sender was iterating through the user
|> sessions.
|>
|> * If the receiving LoginBean is interested, it can access the session
|> that it's bound to (because we saved a reference to it in the
|> valueBound method), and it can therefore modify the user objects
|> stored in that session (or even invalidate it, if the event was
|> "Floyd is coming -- log off quick and get under cover!" :-).
|>
|> * The valueUnbound() method of the LoginBean will be called when
|> the user logs off, or when the session is invalidated (such as on a
|> timeout). At that time, it should deregister itself as a listener for
|> the weather change events, because it no longer cares.
|>
|> You will see this approach a lot in Model-View-Controller (MVC) based design
|patterns and architectures. It is
|> particularly evident in GUI toolkits like AWT and Swing, but the event listener
|concept is quite useful
|> generally in architectures where external stimuli causes things to happen
|asynchronously. The design patterns
|> outlined in the JavaBeans Specification are very helpful in building classes that
|implement this style.
|>
|> Craig McClanahan
|>
|> ___________________________________________________________________________
|> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
|> of the message "signoff SERVLET-INTEREST".
|>
|> Archives: http://archives.java.sun.com/archives/servlet-interest.html
|> Resources: http://java.sun.com/products/servlet/external-resources.html
|> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
