Re: [Solved+Question]SessionListener not being invoked
Caldarale, Charles R wrote: >> From: Ken Bowen [mailto:kbo...@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 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [Solved+Question]SessionListener not being invoked
> From: Ken Bowen [mailto:kbo...@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 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Solved+Question]SessionListener not being invoked
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:kbo...@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 element is nested inside of a 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-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
RE: [Solved+Question]SessionListener not being invoked
> From: Ken Bowen [mailto:kbo...@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 element is nested inside of a 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Solved+Question]SessionListener not being invoked
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:kbo...@als.com] Subject: Re: [Solved+Question]SessionListener not being invoked Note that the path attribute is not allowed (if your 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? 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-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
RE: [Solved+Question]SessionListener not being invoked
> From: Ken Bowen [mailto:kbo...@als.com] > Subject: Re: [Solved+Question]SessionListener not being invoked > > Note that the path attribute is not allowed (if your 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? > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Solved+Question]SessionListener not being invoked
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: WEB-INF/web.xml And the app-specific context doesn't say anything about Manager: type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="1" username="X" password="X" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/sb_data" validationQuery="select 1"/> 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? 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
