On 7/29/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> Craig McClanahan wrote the following on 7/29/2005 12:43 PM:
>
> > One approach to consider is to make your listener implement
> > HttpSessionAttributeListener as well as HttpSessionListener. That
> > means you'll hear about session attributes being removed -- which is
> > what happens as the session is being invalidated or timed out. All of
> > these calls will happen before the sessionDestroyed() notification.
>
> Another option might be to implement HttpSessionBindingListener? You
> could store all items you care about in one class that implemeents
> HttpSessionBindingListener (maybe call it UserSessionWrapper). The
> benefit is you'll have access to all the vars in one spot so clean up
> will be easy. This too will be used in conjunction wtih your
> SessionListener.
>
> For example in your SessionListener...
>
> sessionCreated(..) {
> session.setAttribute("UserSessionWrapper", new Sessionrapper() );
>
>
> Then in your UserSessionWrapper...
>
> UserSessionWrapper implements HttpSessionBindingListener
>
>
> Integer someVariable;
>
> public void valueBound(HttpSessionBindingEvent event) {
> //you could intialize some stuff here if you want
> }
>
> public void valueUnbound(HttpSessionBindingEvent event) {
>
> /*but here is the important cleanup part. You can
> now persist stuff like "someVariable" above. During the course of the
> user's session you'll have access to this class so you can modify items
> in it. If you want to get really dynamic you could just have one Map as
> a property and add what you need to that map during the course of the
> application. When valueUnbound is called (which happens when session
> expires) you can persist the whole map or the values that you want out
> of it*/
>
>
The HttpSessionBindingListener approach would definitely work ... but
it requires that your model objects (or the UserSessionWrapper in this
case) to be aware of, and dependent on, the servlet API. Since the
availability of HttpSessionAttributeListener (Servlet 2.3) I have
preferred using that instead, since the model objects can be
blissfully unaware of what's going on here. Persistence becomes a
function of the listener, not a function of the model object.
>
>
> --
> Rick
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
