Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 24881 invoked from network); 24 Jun 2002 11:34:41 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 24 Jun 2002 11:34:41 -0000 Received: (qmail 11966 invoked by uid 97); 24 Jun 2002 11:34:32 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 11950 invoked by uid 97); 24 Jun 2002 11:34:32 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 11938 invoked by uid 98); 24 Jun 2002 11:34:31 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: From: tamir To: 'Tomcat Users List' Subject: RE: SessionListener does not get enough information Date: Mon, 24 Jun 2002 14:54:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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:sag@stark-verlag.de] 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: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: