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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org