Hi Hiran, I just bugged into this problem yesterday. I don't understand why the sessionlistener is designed this way... (Explanation please ?) A workaround I thought, was to use the attributelistener instead. When one attribute I choose is removed, I understand the next step is the session to be removed. So, I use this attribute value for my work. Offcourse, it's not perfect and it might be pronable to mistakes, but this is the fastest way for me to solve the problem. Regards, Tamir
-----Original Message----- From: Software AG [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 1:25 PM To: Tomcat Users List Subject: SessionListener does not get enough information Hi there. I have a web application that stores some information into a database. Now if the "transaction" is not complete (which means the user did not go through a page asking "do you want to save [y/n]?") all stored data shall be dropped again. I detect this "dropped transaction" with a SessionListener, since after some time all inactive sessions are discarded. The problem is now that when the SessionListener.sessionDestroyed method is called, all attributed have already been removed from the session, so I do not really know what data needs to be deleted. In my eyes the real solution is to change the code in StandardSession.expire() to first fire the event and then clear the attributes. But I do not want to rely on anyone installing that web application to have a modified version of Tomcat. Does anyone know about an elegant workaround for this problem? 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]>
