Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 3714 invoked from network); 6 Feb 2001 23:19:44 -0000 Received: from web1901.mail.yahoo.com (128.11.23.50) by h31.sny.collab.net with SMTP; 6 Feb 2001 23:19:44 -0000 Received: (qmail 23538 invoked by uid 60001); 6 Feb 2001 23:19:49 -0000 Message-ID: <20010206231949.23537.qmail@web1901.mail.yahoo.com> Received: from [38.203.49.2] by web1901.mail.yahoo.com; Tue, 06 Feb 2001 15:19:48 PST Date: Tue, 6 Feb 2001 15:19:48 -0800 (PST) From: Mel Martinez Subject: Re: Common Session code 3.3/4.0 (was: [VOTE] New Committer: Kief Morris) To: tomcat-dev@jakarta.apache.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N --- cmanolache@yahoo.com wrote: > > IMHO it would be a mistake to write a session > manager using the same > abstractions as in a servlet container - after all > the task is to store > data and the requirements are pretty specific ) > I'd like to poke my $.02 in and say I totally agree with Costin. The only 'connection' required between the servlet container apis and persistent session management is state maintenance, which can be encapsulated in some sort of session identifier (i.e. cookie typically) which can be built independent of the actual container by using the standard servlet APIs (v 2.2 is sufficient). Other than that, the actual implementation of a persistant session managment API does not have to have anything to do with the servlet container or even the servlet API. I have built such a beast and it is, as Costin advocates, independent of servlet container. It is proprietary, so I can't give it to the project, but the basic principal is simple: 1 - Use the standard servlet API's to establish a 'session identifier' (cookies work fine for 90% of the browser world out there). 2 - use this as a key into your persistant session store. Naturally, there are some other details involving assertaining the 'active' or inactive state of the session, time out of session ids,authentication controls, etc., but even all that does not have to depend on the servlet container. You should come up with a scheme that is pluggable as to where the actual data is stored (i.e. disk files vs (shared) RDBMS vs whatever). Just my $.02. Mel __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/