Hi, Craig. Done that.
But now that we clarified that the current servlet spec only contains one event, but does not say how it must be used: Would we break a lot if we still just swap some lines of code and fire the event before the session is actually timed out? We definitely would not break any specifications here...... Hiran > -----Urspr�ngliche Nachricht----- > Von: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 26. Juni 2002 19:10 > An: Tomcat Users List > Betreff: Re: AW: AW: SessionListener does not get enough information > > > A pre-shutdown event (for both sessions and applications) seems sane > enough (although adding the new method to the corresponding interfaces > would break 100% of the existing listener implementation > classes) -- the > best way to get it considered is to send mail to the Servlet > Spec feedback > address: > > [EMAIL PROTECTED] > > Craig > > > On Wed, 26 Jun 2002, Software AG wrote: > > > Date: Wed, 26 Jun 2002 11:11:09 +0200 > > From: Software AG <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > > Subject: AW: AW: SessionListener does not get enough information > > > > Hi, Craig. > > > > > -----Urspr�ngliche Nachricht----- > > > Von: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > > Gesendet: Dienstag, 25. Juni 2002 18:34 > > > An: Tomcat Users List > > > Betreff: Re: AW: SessionListener does not get enough information > > > > > > I am not convinced that it makes sense to keep SessionID > > > and according > > > > information inside the DB. Of what use is the session > > > attribute architecture > > > > then? All that would happen is that I need a session to > > > somehow generate a > > > > unique ID, and all information is then stored inside my DB. > > > That means I > > > > reproduce all the session handling code. > > > > > > > > > > Why? The servlet container already computes a unique (within > > > the scope of > > > a particular webapp) id for you, and makes it accessible. > > > Just save the > > > session id in a separate column as you store the > > > session-related stuff in > > > the database and you can do the delete I proposed later. > > > > Right. The only thing used from the session api is to have > a unique id. All > > the rest (attributes, events) must be implemented over and > over again. Was > > that the thought when the api was designed? Get me right, I > do not say it > > would not work. > > > > > > If that does not exist, does it harm to swap the few lines? > > > It would do so > > > > much good for application programming..... And if not, it > > > might be nice to > > > > split the event into session_will_be_destroyed and > > > > session_has_been_destroyed. I bet a lot of listeners are > > > more interested in > > > > the first. > > > > > > > > > > Making this change would have a very adverse effect. > > > Consider what your > > > "attribute removed" listener assumes it can do -- access > > > other things in > > > the session, right? But you'd get IllegalStateExceptions > > > now, because the > > > session has already been invalidated. That makes no sense at > > > all -- it > > > should be called > > > > I agree that after destruction a session is in a > non-operative state. But > > what if the event is fired BEFORE the session is destroyed? > At that point in > > time, the session is fully operational, and a listener can > do whatever it > > wants with the session. Obviously, adding new attributes > would not last, as > > the session is about to expire. > > > > > Note that the same design pattern applies with servlet > > > context listeners > > > -- at application shutdown, the context attributes are > removed first, > > > before contextDestroyed() is called. > > > > Note that this design pattern has been discussed by the > same people, and I > > still think that it is desireable again to have a > pre-shutdown event. All > > operating systems will send a SIGTERM before a SIGKILL to allow an > > application to peacefully shut down. Or have a look at Swing. Each > > WindowListener will get a WindowClosing event before the > window is actually > > closed. At the WindowClosing event it is even possible to > prevent the window > > from closing - the reason might be invalid or unsaved data. > > > > Taken this design pattern into the servlet api, I'd like to have a > > pre-timeout event that allows an application to handle it's > data before it > > gets thrown away, and maybe even decide to not timeout this > one session for > > whatever reason. > > > > What do you think? > > > > Hiran > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
