tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: How to use setRequestedSessionId
Date Mon, 03 Jun 2002 16:10:28 GMT

On Mon, 3 Jun 2002, Subir Sengupta wrote:

> Date: Mon, 3 Jun 2002 00:24:33 -0700
> From: Subir Sengupta <>
> Reply-To: Tomcat Users List <>
> To: "''" <>
> Subject: How to use setRequestedSessionId
> Hi,
> I'm not sure how to do this and was hoping for some pointers.  I have a
> filter that intercepts the session in the request.  I then compare the
> Session Id to another value and based on some calculations either accept or
> reject the Session Id.  Here's the question.  How do I invalidate the
> session and assign my own Session Id to the request?  Or have the request
> reuse an existing session object.  setRequestedSessionId does not seem to be
> available from the filter, so I don't know how to change the session
> associated with the request.  I wrote my own version of the Standard
> Manager, but the manager doesn't have access to the request, so I can't do
> it there.
> One of the uses for this is to not create a session everytime a particular
> page is hit by a monitoring system (every 5 seconds).  Tomcat will create a
> new session every time, which is wasteful.  If I could reuse the session in
> this case, that would be ideal.
> Would a HttpRequestWrapper work here and if so can anyone provide an
> example.  I couldn't find any.
> I'm using Tomcat 4.03 on Linux.

It sounds to me like you are approaching this problem from the wrong

Tomcat creates a session automatically in only two circumstances -- when
you are using form-based login or the single sign-on facility.  In all
other cases, the application must ask for sessions to be created.

My bet is that you are running into the fact that JSP pages ask for
sessions to be created by default.  This is simple to turn off -- just put
the following at the top of the page your monitoring system is accessing:

  <%@ page session="false" %>

and making sure that you're not using form-based login or single sign-on
for this webapp.

If you really have your heart set on selectively creating the session or
not, you're best off by creating a Filter that creates a wrapper around
the request that overrides the getSession() methods.  Your wrapper
implementation can look at the request and decide whether or not to really
create it -- if so, call super.getSession() and return the value, or
otherwise just return null.  (As an added bonus, this will work on any
Servlet 2.3 container, because it does not involve modifying the container

> Thanks,
> Subir

Craig McClanahan

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message