tomcat-users mailing list archives

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

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:

<Context>

     <!-- Default set of monitored resources -->
     <WatchedResource>WEB-INF/web.xml</WatchedResource>

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

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

</Context>

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"  
type="javax.sql.DataSource"
              maxActive="100" maxIdle="30" maxWait="10000"
              username="XXXXX" password="XXXXX"
              driverClassName="com.mysql.jdbc.Driver"
              url="jdbc:mysql://localhost:3306/sb_data"
              validationQuery="select 1"/>
</Context>

So I understand http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html 
:

	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  
Implementation":

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

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

	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  
"SESSIONS.ser".

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/  
configBean.bp=/strongbrain/

Great!
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:

> -----BEGIN PGP SIGNED MESSAGE-----
> 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="http://tiles.apache.org/tags-tiles" prefix="tiles" %>
>> <%@ taglib uri="http://java.sun.com/jstl/core_rt" 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAksWpHgACgkQ9CaO5/Lv0PBaUQCfbcuQ+bgTQKudElNSi0i9Y8eX
> x1wAoKyA9rQPGuJ5AzFw0GIvuHhJt7X8
> =gOgm
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message