tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Bowen <>
Subject Re: [Solved+Question]SessionListener not being invoked
Date Fri, 04 Dec 2009 03:33:35 GMT

This seems to be the source of the problem.  Just to be sure I'm on  
target, I'll run through
a few details, and then I have a follow-on question.  My tomcat-6.0.20/ 
conf/context.xml is the
one shipped with the download:


     <!-- Default set of monitored resources -->

     <!-- Uncomment this to disable session persistence across Tomcat  
restarts -->
     <Manager pathname="" />

     <!-- Uncomment this to enable Comet connection tacking (provides  
          on session expiration as well as webapp lifecycle) -->
className="org.apache.catalina.valves.CometConnectionManagerValve" />


And the app-specific context doesn't say anything about Manager:

<Context path="" debug="5" reloadable="true" crossContext="true">

    <Resource name="jdbc/sb_data" auth="Container"  
              maxActive="100" maxIdle="30" maxWait="10000"
              username="XXXXX" password="XXXXX"
              validationQuery="select 1"/>

So I understand 

	A Manager element MAY be nested inside a Context component.
	If it is not included, a default Manager configuration will be 	
	created automatically, which is sufficient for most requirements.

to say that the app will get a default Manager, which is the "Standard  

	Tomcat provides two standard implementations of Manager for use - the  
default one stores active sessions

In addition, under the Standard Implementation "pathname" attribute, I  

	Absolute or relative (to the work directory for this Context)  
pathname of the file in which session state will be
	preserved across application restarts, if possible. The default is  

Poking around, I found SESSIONS.ser in  ~work/Catalina/localhost/ 
strongbrain.  Being naturally short-tempered and brutish,
I simply deleted ~work/Catalina/localhost/ , and restarted Tomcat.   
Then when I connected to the app with a browser,
I got the desired:

INFO: Server startup in 3728 ms
++++Enter sessionCreated
+++++++++SessionListener: isNew=true  baseprefix=/strongbrain/  

So now the question is this:  Is the simplest principled, patient, and  
gentle way of suppressing session persistence for my
particular app to add the following Manager config element to my  
webapp's context.xml?
	<Manager pathname="" />

And if I wanted all apps to suppress persistence, then I would just  
uncomment that in ~conf/context.xml.

Many thanks!
Ken Bowen

On Dec 2, 2009, at 12:31 PM, Christopher Schultz wrote:

> Hash: SHA1
> Ken,
> On 12/1/2009 2:36 PM, Ken Bowen wrote:
>> No, we always create a session (or want to).
>> The only <%@ in the welcome page are
>> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
>> <%@ taglib uri="" prefix="tiles" %>
>> <%@ taglib uri="" prefix="c" %>
>> As I mentioned at the end of the initial email,  this all works  
>> (i.e.,
>> as session is created) when I run the same welcome page with the same
>> SessionListener and the indicated change to the context-param ; and  
>> run
>> it as webapps/strongbrain/ instead of webapps/ROOT.  That's what's so
>> mysterious.
>> Obviously, something else is being changed too.   But sessions have
>> never been optional in this app.
> I didn't quite understand your original report, but is it possible  
> that
> one of these clients already has a valid session and therefore a new  
> one
> isn't being created?
> That might be possible, even after a webapp/container restart if you
> have Tomcat configured to persist sessions across such restarts (which
> is the default configuration).
> - -chris
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla -
> x1wAoKyA9rQPGuJ5AzFw0GIvuHhJt7X8
> =gOgm
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message