You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ken Bowen <kb...@als.com> on 2009/12/01 18:56:49 UTC
SessionListener not being invoked
My setup: Mac OS X 10.5.8, Tomcat/6.0.20[from apache], java version
"1.6.0_15"
I'm starting Tomcat with ~bin/startup.sh.
I have a SessionListener which is not being invoked when I connect to
the webapp,
and I don't understand why.
The SessionListener works correctly in a a slight variation of the
circumstances.
The problem circumstance is when the app is running as the default
ROOT webapp,
by dropping ROOT.war into webapps.
The relevant part of web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<!-- ============================================ Welcome File List -->
<welcome-file-list>
<welcome-file>pages/welcome.jsp</welcome-file>
</welcome-file-list>
<!-- ============================================ Listener
Registration -->
<listener>
<listener-class>com.strongbrain.listener.AppListener</listener-
class>
</listener>
<listener>
<listener-class>com.strongbrain.listener.SessionListener</
listener-class>
</listener>
<!-- ============================================ Context Parameters -->
<context-param>
<param-name>baseprefix</param-name>
<param-value>/</param-value>
</context-param>
.........etc........
The SessionListener class:
package com.strongbrain.listener;
import javax.servlet.http.HttpSession;
import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionListener;
import com.strongbrain.ConfigBean;
import com.strongbrain.Constants;
public class SessionListener implements HttpSessionListener
{
public void sessionCreated(HttpSessionEvent httpSessionEvent) {
System.out.println("++++Enter sessionCreated");
HttpSession session = httpSessionEvent.getSession();
ConfigBean configBean = new ConfigBean();
String baseprefix =
httpSessionEvent
.getSession
().getServletContext().getInitParameter(Constants.BASEPREFIX);
if (baseprefix != null){
configBean.setBaseprefix(baseprefix);
}
System.out.println("+++++++++SessionListener: isNew="+session.isNew()
+" baseprefix="+baseprefix+"
configBean.bp="+configBean.getBaseprefix());
session.setAttribute(Constants.CONFIG_BEAN, configBean);
}
public void sessionDestroyed(HttpSessionEvent arg0) {
}
}
When I start Tomcat with the app (as ROOT.war) in webapps, and then
connect with a browser,
catalina.out looks like this:
.....(usual stuff)
Dec 1, 2009 12:14:42 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 2823 ms
[Deprecated] Xalan:
org.apache.xalan.processor.TransformerFactoryImpl <<<<< Browser
connect above here
adl=5 <<<<< Healthy
trace output from class invoked on welcome.jsp
Notice that neither of the System.out.println's in the
SessionListener.sessionCreated method appear.
BUT: When I run this in the non-ROOT configuration, things work. In
that case, the only difference in the code above is in
web.xml:
<context-param>
<param-name>baseprefix</param-name>
<param-value>/strongbrain/</param-value>
</context-param>
In that case, catalina.out shows:
Dec 1, 2009 12:30:34 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 3072 ms
++++Enter sessionCreated
+++++++++SessionListener: isNew=true baseprefix=/strongbrain/
configBean.bp=/strongbrain/
[Deprecated] Xalan: org.apache.xalan.processor.TransformerFactoryImpl
adl=5
This behavior is occurring both on my (development) Mac,
and on a remote CentOS 5 system running Tomcat/6.0.18 under java
version "1.6.0_12"
In all cases, the browser connects to the expected welcome page.
At present, I'm at a loss as to what to look for; I hope someone here
can point me in the right direction.
Thanks in advance,
Ken Bowen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SessionListener not being invoked
Posted by Ken Bowen <kb...@als.com>.
Chris,
That's a point I hadn't thought of. I'll explore it.
Thanks,
Ken
On Dec 2, 2009, at 12:31 PM, Christopher Schultz wrote:
> 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).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Solved+Question]SessionListener not being invoked
Posted by David Smith <dn...@cornell.edu>.
Caldarale, Charles R wrote:
>> From: Ken Bowen [mailto:kbowen@als.com]
>> Subject: Re: [Solved+Question]SessionListener not being invoked
>>
>> This project has been sputtering along for a fair number of
>> years, and my context.xml almost certainly began life inside
>> conf/server.xml.
>>
>
> Once upon a time, I believe <Context> elements had to be in server.xml, but that predates my Tomcat experience.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>
>
>
>
Tomcat 3 did it that way. I think the idea of moving the context
elements out to their own file started in tomcat 4 but that was a long
time ago and my memory is a little fuzzy.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [Solved+Question]SessionListener not being invoked
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Ken Bowen [mailto:kbowen@als.com]
> Subject: Re: [Solved+Question]SessionListener not being invoked
>
> This project has been sputtering along for a fair number of
> years, and my context.xml almost certainly began life inside
> conf/server.xml.
Once upon a time, I believe <Context> elements had to be in server.xml, but that predates my Tomcat experience.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Solved+Question]SessionListener not being invoked
Posted by Ken Bowen <kb...@als.com>.
Thanks. This project has been sputtering along for a fair number of
years, and my context.xml almost certainly began life inside conf/
server.xml. I would be fairly confident in betting that I moved it
out on earlier advice from you, but that I didn't clean it up then.
Well, I have now.
Cheers,
Ken
On Dec 3, 2009, at 11:02 PM, Caldarale, Charles R wrote:
>> From: Ken Bowen [mailto:kbowen@als.com]
>> Subject: Re: [Solved+Question]SessionListener not being invoked
>>
>> One question: What does it mean to say "the path attribute is not
>> allowed"? (My context.xml is in META-INF). Should I be seeing a
>> complaint when Tomcat starts the app?
>
> Unfortunately, Tomcat won't complain about it (although I think it
> should). The path attribute is only valid when the <Context>
> element is nested inside of a <Host> element in conf/server.xml -
> which is very strongly discouraged. Using a path attribute in any
> other circumstance is not permitted, but not diagnosed. At best, it
> will confuse anyone looking at your configuration, possibly thinking
> that something meaningful is being done with it.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
> PROPRIETARY MATERIAL and is thus for use only by the intended
> recipient. If you received this in error, please contact the sender
> and delete the e-mail and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> 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
RE: [Solved+Question]SessionListener not being invoked
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Ken Bowen [mailto:kbowen@als.com]
> Subject: Re: [Solved+Question]SessionListener not being invoked
>
> One question: What does it mean to say "the path attribute is not
> allowed"? (My context.xml is in META-INF). Should I be seeing a
> complaint when Tomcat starts the app?
Unfortunately, Tomcat won't complain about it (although I think it should). The path attribute is only valid when the <Context> element is nested inside of a <Host> element in conf/server.xml - which is very strongly discouraged. Using a path attribute in any other circumstance is not permitted, but not diagnosed. At best, it will confuse anyone looking at your configuration, possibly thinking that something meaningful is being done with it.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Solved+Question]SessionListener not being invoked
Posted by Ken Bowen <kb...@als.com>.
Thanks Chuck.
One question: What does it mean to say "the path attribute is not
allowed"? (My context.xml is in META-INF). Should I be seeing a
complaint when Tomcat starts the app?
--Ken
On Dec 3, 2009, at 10:42 PM, Caldarale, Charles R wrote:
>> From: Ken Bowen [mailto:kbowen@als.com]
>> Subject: Re: [Solved+Question]SessionListener not being invoked
>>
>> <Context path="" debug="5" reloadable="true" crossContext="true">
>
> Note that the path attribute is not allowed (if your <Context>
> element is in a standard location), and the debug attribute hasn't
> been used in some years. Use conf/logging.properties to set the
> desired logging level.
>
>> 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="" />
>
> Yes, that is the documented and recommended way:
> "Restart persistence may be disabled by setting this attribute to an
> empty string."
>
> The above quote is taken from:
> http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html
>
>> And if I wanted all apps to suppress persistence, then I would just
>> uncomment that in ~conf/context.xml.
>
> Also true.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
> PROPRIETARY MATERIAL and is thus for use only by the intended
> recipient. If you received this in error, please contact the sender
> and delete the e-mail and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> 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
RE: [Solved+Question]SessionListener not being invoked
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Ken Bowen [mailto:kbowen@als.com]
> Subject: Re: [Solved+Question]SessionListener not being invoked
>
> <Context path="" debug="5" reloadable="true" crossContext="true">
Note that the path attribute is not allowed (if your <Context> element is in a standard location), and the debug attribute hasn't been used in some years. Use conf/logging.properties to set the desired logging level.
> 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="" />
Yes, that is the documented and recommended way:
"Restart persistence may be disabled by setting this attribute to an empty string."
The above quote is taken from:
http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html
> And if I wanted all apps to suppress persistence, then I would just
> uncomment that in ~conf/context.xml.
Also true.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Solved+Question]SessionListener not being invoked
Posted by Ken Bowen <kb...@als.com>.
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
Re: SessionListener not being invoked
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
Re: SessionListener not being invoked
Posted by Ken Bowen <kb...@als.com>.
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.
--Ken
On Dec 1, 2009, at 1:42 PM, Caldarale, Charles R wrote:
> session=
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: SessionListener not being invoked
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Ken Bowen [mailto:kbowen@als.com]
> Subject: SessionListener not being invoked
>
> I have a SessionListener which is not being invoked when I connect to
> the webapp, and I don't understand why.
Most likely because your webapp didn't choose to create a session. You'll need to look at the code in your webapp to see under what circumstances it decides to do so. Normally, a session will be created for a JSP-based action unless you have inhibited it with <%@ page session="false" %>; what's in your welcome.jsp?
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org