And possibly a HttpSessionActivationListener object as a session
attibute. The sessionDidActivate() method on the object gets called if
the session is still valid when tomcat restarts. You can use this to fix
your state.
HTH,
Jon
Mark Thomas wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
So after a restart of tomcat, I login and it appears the
session is still
valid, so it does not go through my session listener.
I need to be aware of the web application lifecycle and want to grab a
resource when the webapp starts and
My web app has two servlets. One JSF Faces servlet and another servlet
for processing AJAX requests from javascript. I want to know when the
app starts and when the app is done. Is the only way to do this is to
have a ServletContextListener listening to both those servlets? On the
first one, I
whoops, nevermind. stupid question I found out after poking around.
dean
Dean Hiller wrote:
My web app has two servlets. One JSF Faces servlet and another servlet
for processing AJAX requests from javascript. I want to know when the
app starts and when the app is done. Is the only way to do
to do, what
authentication mechanism you're using, and let's forget about the
tomcat-specific hacks for a minute ;)
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Atreya Basu [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2003 4:37 PM
To: Tomcat Users List
Subject: Re
, Yoav [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 9:00 AM
To: Tomcat Users List
Subject: RE: SessionListener
Howdy,
Senor Basu, your solution is seriously not thread-safe. But that's for
you to worry about it, maybe it's good enough for your needs ;)
As for Senor Hart's questions
AM
To: Tomcat Users List
Subject: RE: SessionListener
Howdy,
Senor Basu, your solution is seriously not thread-safe. But that's for
you to worry about it, maybe it's good enough for your needs ;)
As for Senor Hart's questions:
- HttpSessionListener goes in web.xml, as do all other Servlet
the authenticated user to their connection... better yet, the
hash, so it's a bit more optimal.
*SLAPS FOREHEAD!*
Justin
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 9:13 AM
To: Tomcat Users List
Subject: RE: SessionListener
Howdy,
Basic
Message-
From: Hart, Justin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 9:22 AM
To: Tomcat Users List
Subject: RE: SessionListener
How will the container get my user logged into the database? My plan
was
to use the username password to authenticate to my database so the
user
only
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 9:23 AM
To: Tomcat Users List
Subject: RE: SessionListener
Howdy,
Yes, now you got it ;) It's these simple misunderstandings that often
cause a lot of debate. As a bonus, your approach will work very well in
any J2EE container.
You
Justin,
Won't quite do it, JDBCRealm looks for users in a database, I want to
connect a user TO a database using their credentials, but the code to
do this feat will be quite minimal by comparison.
This will make it hard to use a connection pool (which you mentioned
that you do/want to do).
Is
Unfortunately, the paranoia is founded in this case, though I do agree.
Justin
-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 10:23 AM
To: Tomcat Users List
Subject: Re: SessionListener
Justin,
Won't quite do it, JDBCRealm
Ok, so, the listener in there must implement HttpSessionListener, where can I use
SessionListeners?
Justin
-Original Message-
From: Hart, Justin
Sent: Monday, December 01, 2003 11:34 AM
To: Tomcat Users List (E-mail)
Subject: SessionListener
My SessionListener doesn't seem to be
hierarchy.
The above is true for Valves, Realms, Listeners, etc, that are
proprietary to tomcat.
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Hart, Justin [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2003 11:53 AM
To: Tomcat Users List
Subject: RE
an HttpSessionListener. Could you throw me a bone?
Justin
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2003 2:52 PM
To: Tomcat Users List
Subject: RE: SessionListener
Howdy,
A SessionListener of the org.apache.catalina variety would go
Howdy,
Ok, still, I haven't found any documentation on how to add a
SessionListener in the server.xml file, and adding one using the
listener
tags defined for web.xml files doesn't seem to work.
The XML is the similar but not quite the same to the portable one:
listener
: Monday, December 01, 2003 3:18 PM
To: Tomcat Users List
Subject: RE: SessionListener
Howdy,
Ok, still, I haven't found any documentation on how to add a
SessionListener in the server.xml file, and adding one using the
listener
tags defined for web.xml files doesn't seem to work.
The XML
Sorry,
I should have added to this earlier, but I thought that SessionListener
should go in the web.xml document under the Listener element. Or am I
thinking about HttpSessionListener which is different
Anyways if it is HttpSessionListener that you are talking about I can
provide some
on a second time,
any way to get the username and password using HttpSessionListener without having them
retype the data?
Justin
-Original Message-
From: Atreya Basu [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2003 4:07 PM
To: Tomcat Users List
Subject: Re: SessionListener
Sorry
credentials from a HttpSession, or how to get a Session from an HttpSessionListener. Could you throw me a bone?
Justin
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2003 2:52 PM
To: Tomcat Users List
Subject: RE: SessionListener
Howdy
Not in servlet 2.3 containers. Servlet spec 2.4 has changed the
semantics of the sessionDestoyed method so Tomcat 5 should notify before
the session is invalidated...
http://java.sun.com/j2ee/1.4/docs/api/index.html
HTH,
Jon
Peter Maas wrote:
Hi,
I wondered if there is a way detect
Since we're developing on tomcat 5.0.12 the container should be 2.4
but still it is called after the session was invalidated.
Peter
Jon Wingfield wrote:
Not in servlet 2.3 containers. Servlet spec 2.4 has changed the
semantics of the sessionDestoyed method so Tomcat 5 should notify
before
;) That's why i put the ellipsis at the end of the sentence.
The change to the spec + javadoc occurred in the last draft of the spec
(a couple of months ago, i think) so maybe tomcat 5 hasn't caught up
yet. The change isn't discussed in the spec and is only exposed via the
published javadoc and
Peter,
I wondered if there is a way detect somehting like a
'sessionWillBeDestroyed' event.
since the sessionDestroyed method in a sessionListener seems to be
called after the session was destroyed.
I don't think you can 'veto' the destruction of a session, if that's
what you mean. All the
What I actually want to do is call some destruct methods in objects
bound to the session...
P
Christopher Schultz wrote:
Peter,
I wondered if there is a way detect somehting like a
'sessionWillBeDestroyed' event.
since the sessionDestroyed method in a sessionListener seems to be
called
You might be able to use HttpSessionAttributeListener
-Tim
Peter Maas wrote:
What I actually want to do is call some destruct methods in objects
bound to the session...
P
Christopher Schultz wrote:
Peter,
I wondered if there is a way detect somehting like a
'sessionWillBeDestroyed' event.
You might be able to use HttpSessionAttributeListener
...or HttpSessionBindingListener. The container calls the
valueUnbound(HttpSessionBindingEvent event) when the object is removed from
the session (e.g. when session is destroyed). I am using this one =)
- Tatu V.
Peter Maas wrote:
What
Peter,
What I actually want to do is call some destruct methods in objects
bound to the session...
Oh! Okay the session is completely in tact when this notifications
is received. So, you can certainly destruct those objects from the
sessionDestroyed method.
-chris
Peter Maas wrote:
Hi,
I wondered if there is a way detect somehting like a
'sessionWillBeDestroyed' event.
since the sessionDestroyed method in a sessionListener seems to be
called after the session was destroyed.
Use Tomcat 5 ;-) The Servlet spec has been modified to do exactly what
you
Hi Hiran,
I just bugged into this problem yesterday. I don't understand why the
sessionlistener is designed this way...
(Explanation please ?)
A workaround I thought, was to use the attributelistener instead.
When one attribute I choose is removed, I understand the next step is the
session to be
Another idea (I do not like HttpSessionBindingListener):
On sessionDestroyed you should be able to get Session ID information.
So just write your method:
MySessionDataDropper.drop(String sessionID) or (MyObject data)
which will drop all data identified by sessionID.
Imagine:
You have one
On Mon, 24 Jun 2002, tamir wrote:
Date: Mon, 24 Jun 2002 14:54:00 +0200
From: tamir [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: 'Tomcat Users List' [EMAIL PROTECTED]
Subject: RE: SessionListener does not get enough information
Hi Hiran,
I just bugged
You mean HttpSessionBindingListener? (I can't find any other reference to
Listener in tomcat/conf/* or the JSDK 2.2 spec; nor can I find that class
in the Tomcat sources.)
That's not related to web.xml, and I find it pretty easy to use. What
troubles are you having?
Yup -
My
web.xml looks like this:
listener
listener-classcom.orangefood.java.servlet.http.SessionTracker/listener-class
/listener
Make
sure the listerer tags are after any filter-mapping tags and before any
servlet tags.
Then
just make sure your class is in a .jar in the WEB-INF/lib
that implements
HttpSessionListener, you need to specify this class in web.xml file.
Alin
- Original Message -
From: William Kaufman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 17, 2001 3:56 PM
Subject: RE: SessionListener
You mean HttpSessionBindingListener? (I can't find any
Sorry :)
I mean in Servlet API 2.3...
- Original Message -
From: Alin Simionoiu [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 17, 2001 4:45 PM
Subject: Re: SessionListener
In Servlet API spec, which is in this moment in draft, is added the
concept
36 matches
Mail list logo