Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: 
 <57039.170.201.180.136.1131563539.squirrel@webmail.chiron.lunarpages.com>
In-Reply-To: <437245DC.3010106@maz.org>
References: <437245DC.3010106@maz.org>
Date: Wed, 9 Nov 2005 14:12:19 -0500 (EST)
Subject: Re: disabling sessions in certain parts of a webapp
From: "Frank W. Zammetti" <fzlists@omnytex.com>
To: "Tomcat Users List" <users@tomcat.apache.org>
Cc: users@tomcat.apache.org
User-Agent: SquirrelMail/1.4.4
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

I can't think of any drawbacks to the filter, and tha's what I would have
suggested.  Although, it probably doesn't even have to be as complicated
as a wrapper... simply check for an existing session for the paths you do
want a session created for, and if none is present go ahead and create it.
 I *think* that would do the trick.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com

On Wed, November 9, 2005 1:54 pm, Brian Moseley said:
> my web application has three separate interfaces: an html ui, webdav,
> and a custom http/xml protocol. clients of the latter two interfaces are
> unaware of the http session, so i'd prefer that sessions not even be
> constructed when requests come in through those interfaces.
>
> i see that StandardManager and PersistentManager have maxActiveSessions
> attributes, which i could potentially set to 0, but that isn't a
> solution since i *do* want to have sessions for the html ui.
>
> short of writing a new implementation of Manager, is there a way for me
> to specify that sessions should not be created for, say, all requests to
> /foo/*?
>
> one idea was a filter that wraps the request with a class that overrides
> getSession. are there any drawbacks to that approach?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org