Re: SessionListener invoked sometimes and not others

[Jon Wingfield]

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 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 release when the web app 
goes away. 
How do I do that?



Use a ServletContextListener.

Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

SessionListener invoked sometimes and not others

[dean]

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 release when the web app goes away. 
How do I do that?

I was doing this in the SessionListener upon creation of the first session
and releasing when the last session went away.  But since tomcat may be
saving session, I am getting a request and getting a nullpointerexception
now since the resource had not been allocated in web app startup.

How does one deal with this kind of problem?
thanks,
dean


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SessionListener invoked sometimes and not others

[Mark Thomas]

 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 release when the web app 
 goes away. 
 How do I do that?

Use a ServletContextListener.

Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SessionListener invoked sometimes and not others

[Dean Hiller]

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 get resources and on the last one being cleaned up, I 
destroy the resources. I guess this works. I just wish I had access to 
the app lifecycle.

thanks,
dean

Mark Thomas wrote:

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 release when the web app 
goes away. 
How do I do that?
   



Use a ServletContextListener.

Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SessionListener invoked sometimes and not others

[Dean Hiller]

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 this is to 
have a ServletContextListener listening to both those servlets? On the 
first one, I get resources and on the last one being cleaned up, I 
destroy the resources. I guess this works. I just wish I had access to 
the app lifecycle.

thanks,
dean

Mark Thomas wrote:

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 release when the web app goes 
away. How do I do that?
  



Use a ServletContextListener.

Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Concurrency Issue With a SessionListener.

[Jacob Champlin]

I am having issues with a SessionListener I have written. The purpose of 
the Listener is to maintain a List of Active Users on the site. Here is 
the code for the Listener.

// BEGIN CODE
public class ActiveUsersListener implements Serializable, 
HttpSessionListener {

public static Set activeSessions = new HashSet();
public void sessionCreated(HttpSessionEvent event) {
activeSessions.add(event.getSession());
}
public void sessionDestroyed(HttpSessionEvent event) {
activeSessions.remove(event.getSession());
}
public static List getActiveUsers() {
List users = new ArrayList();
Iterator sessionIter = activeSessions.iterator();
HttpSession session = null;
EmoUser user = null;
while (sessionIter.hasNext()) {
  session = (HttpSession) sessionIter.next();
  user = (EmoUser) session.getAttribute(EmoUser.SESSION_KEY);
  if (user != null  user.hasLoggedIn()) {
users.add(user);
  }
}
return users;
}
}
// END CODE
I then have a webpage that calls ActiveUsersListener.getActiveUsers() to 
list out all the active users on the site. Note: I don't just store the 
User objects because the user object doesn't get created until the user 
logs in.

So the problem I am having is that this code works fine on a single box 
under Tomcat 5.5.4 . However, as soon as we go into a cluster we get 
lockups in Tomcat. The server is completely unresponsive, and there are 
no log/error messages.

Because of this I am assuming we have a concurrency issue, however I 
have no idea where the problem is.

A few more bits of information, we persist sessions to file system on 
shut down, and we use in memory session replication only when 
session.setAttribute() is called (DirtyFlag).

Thank you in advance for any help.
Jacob Champlin
EMO Corporation
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Concurrency Issue With a SessionListener.

[Frank W. Zammetti]

I had to do almost the exact same thing a while back...
I'm not sure what the source of your lockup is, although I can say my 
code synchronized on what would be your activeSessions Set any place it 
was accessed (probably more than I had to frankly)... I'm not even sure 
there would have been concurrency issues anyway frankly, but it seemed 
like a good idea at the time :)

One issue I'm not sure you have thought of though, and I suppose it 
could have to do with the lockup, although I'm not sure how... your list 
of users will be unique to each node in the cluster.

You would have an instance of ActiveUsersListener on each node, and each 
of those would have its own activeSessions Set, so you wouldn't have a 
consolidated list of users on your site, you'd have a list of users on a 
given node in each instance of the listener... further, if a user hits 
one node during logon, and then is directed to another, and during that 
request you try and retrieve the session from activeSessions, it won't 
be there because its in the version of activeSessions on the first node.

Where specifically does the lockup occur, meaning, is it during logon or 
a listing of users?  I'd bet you can see enough in the log to at least 
tell what method your in (well, not as the code is posted... throw some 
log outputs in sessionCreated(), sessionDestroyed() and getActiveUsers() 
so you can at least see the last place you wind up... hell, I'd put log 
messages around every single line in this listener so I could tell 
exactly where it was failing.

Frank
Jacob Champlin wrote:
I am having issues with a SessionListener I have written. The purpose of 
the Listener is to maintain a List of Active Users on the site. Here is 
the code for the Listener.

// BEGIN CODE
public class ActiveUsersListener implements Serializable, 
HttpSessionListener {

public static Set activeSessions = new HashSet();
public void sessionCreated(HttpSessionEvent event) {
activeSessions.add(event.getSession());
}
public void sessionDestroyed(HttpSessionEvent event) {
activeSessions.remove(event.getSession());
}
public static List getActiveUsers() {
List users = new ArrayList();
Iterator sessionIter = activeSessions.iterator();
HttpSession session = null;
EmoUser user = null;
while (sessionIter.hasNext()) {
  session = (HttpSession) sessionIter.next();
  user = (EmoUser) session.getAttribute(EmoUser.SESSION_KEY);
  if (user != null  user.hasLoggedIn()) {
users.add(user);
  }
}
return users;
}
}
// END CODE
I then have a webpage that calls ActiveUsersListener.getActiveUsers() to 
list out all the active users on the site. Note: I don't just store the 
User objects because the user object doesn't get created until the user 
logs in.

So the problem I am having is that this code works fine on a single box 
under Tomcat 5.5.4 . However, as soon as we go into a cluster we get 
lockups in Tomcat. The server is completely unresponsive, and there are 
no log/error messages.

Because of this I am assuming we have a concurrency issue, however I 
have no idea where the problem is.

A few more bits of information, we persist sessions to file system on 
shut down, and we use in memory session replication only when 
session.setAttribute() is called (DirtyFlag).

Thank you in advance for any help.
Jacob Champlin
EMO Corporation
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Session expiry and SessionListener problems with cluster

[Filip Hanik - Dev]

expireSessionsOnShutdown=false - on shutdown - expire sessions locally, but 
do not propagate to the cluster
expireSessionsOnShutdown=true - on shutdown - expire sessions locally, and 
propagate to the cluster
stupid name for the variable, I agree

- Original Message - 
From: Christoph Kutzinski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 09, 2004 8:00 AM
Subject: Session expiry and SessionListener problems with cluster


Hi,

I'm just playing with the Tomcat 5.5.4 cluster and encountered 2 oddities:

a) If have left expireSessionsOnShutdown=false in the configuration
I understand that this will expire the session in the local node but 
leave it alive in the other cluster nodes.
However I found out that the session will expire in the local node on 
shutdown even if there are no other nodes in the cluster. So the session 
will be lost after restart.
Is this expected behaviour or a bug?

b) I implemented a session listerner for attributes.
I noticed that the attributeAdded event from DeltaManager always return 
null as the value of the event where the normal session manager will 
return the value of the attribute added. Sourcecode:

   public void attributeAdded(HttpSessionBindingEvent evt) {
// == null with DeltaManager, != null otherwise
   Object value = evt.getValue();
   // != null in both cases
   Object value1 = evt.getSession().getAttribute(evt.getName());
   }

Is this a bug?


Thanks in advance,

Christoph

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Session expiry and SessionListener problems with cluster

[Christoph Kutzinski]

Hi,
yes I already did know what this parameter means (though I only realised 
it after reading the source code ;), so the behaviour I described makes 
probably sense in this context.
But my concern is the following:
If a cluster completely fails, i.e. all nodes on the cluster crash 
(which is not so unlikely with small 2-3 node clusters), the session 
data is completely lost even if I can restart all nodes immediately.

In our case we have a cluster of just 2 nodes and we want to use a 
tomcat session replication (among other points) to be able to update the 
webapps without killing all user session on a node. So we would first 
stop Tomcat A, update its webapp, restart tomcat A and then the same for 
Tomcat B. If Tomcat B would now die while Tomcat A is down all session 
information would be lost.

I wanted to know if there is a way to handle this kind of situation.
TIA
Christoph
PS: do you have any information regarding point b?
Filip Hanik - Dev wrote:
expireSessionsOnShutdown=false - on shutdown - expire sessions locally, but 
do not propagate to the cluster
expireSessionsOnShutdown=true - on shutdown - expire sessions locally, and 
propagate to the cluster
stupid name for the variable, I agree
- Original Message - 
From: Christoph Kutzinski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 09, 2004 8:00 AM
Subject: Session expiry and SessionListener problems with cluster

Hi,
I'm just playing with the Tomcat 5.5.4 cluster and encountered 2 oddities:
a) If have left expireSessionsOnShutdown=false in the configuration
I understand that this will expire the session in the local node but 
leave it alive in the other cluster nodes.
However I found out that the session will expire in the local node on 
shutdown even if there are no other nodes in the cluster. So the session 
will be lost after restart.
Is this expected behaviour or a bug?

b) I implemented a session listerner for attributes.
I noticed that the attributeAdded event from DeltaManager always return 
null as the value of the event where the normal session manager will 
return the value of the attribute added. Sourcecode:

   public void attributeAdded(HttpSessionBindingEvent evt) {
// == null with DeltaManager, != null otherwise
   Object value = evt.getValue();
   // != null in both cases
   Object value1 = evt.getSession().getAttribute(evt.getName());
   }
Is this a bug?
Thanks in advance,
Christoph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Session expiry and SessionListener problems with cluster

[Christoph Kutzinski]

Hi,
I'm just playing with the Tomcat 5.5.4 cluster and encountered 2 oddities:
a) If have left expireSessionsOnShutdown=false in the configuration
I understand that this will expire the session in the local node but 
leave it alive in the other cluster nodes.
However I found out that the session will expire in the local node on 
shutdown even if there are no other nodes in the cluster. So the session 
will be lost after restart.
Is this expected behaviour or a bug?

b) I implemented a session listerner for attributes.
I noticed that the attributeAdded event from DeltaManager always return 
null as the value of the event where the normal session manager will 
return the value of the attribute added. Sourcecode:

  public void attributeAdded(HttpSessionBindingEvent evt) {
   // == null with DeltaManager, != null otherwise
  Object value = evt.getValue();
  // != null in both cases
  Object value1 = evt.getSession().getAttribute(evt.getName());
  }
Is this a bug?
Thanks in advance,
Christoph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Using request.getLocale() inside of the sessionListener event

[Ben Bookey]

Dear List,

We are using a sessionlistener to count users. Is it possible for us to
use the request object somehow inside of the sessionCreated event? We want
to determine the client.locale and then store this in the session object.
This would therefore mean, we can determine the language GUI interface to
sue once for a session, and
not in the'header' of every jsp page.

To me there doesnt seem a way to use the request object in this
sessionCreated event ?

I would really appreciate any help!

regards
BEn


import javax.servlet.http.HttpSessionListener;
import javax.servlet.http.HttpSessionEvent;

public void sessionCreated(HttpSessionEvent e)  {
...
count users

}

public void sessionDestroyed(HttpSessionEvent e) {
count users
}


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using request.getLocale() inside of the sessionListener event

[Tim Funk]

No. The request is not accessible inside the sessionevent.
What you probably need to do is write a filter that sets that value in the 
session (if a session exists).

-Tim
Ben Bookey wrote:
Dear List,
We are using a sessionlistener to count users. Is it possible for us to
use the request object somehow inside of the sessionCreated event? We want
to determine the client.locale and then store this in the session object.
This would therefore mean, we can determine the language GUI interface to
sue once for a session, and
not in the'header' of every jsp page.
To me there doesnt seem a way to use the request object in this
sessionCreated event ?
I would really appreciate any help!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

sessionDestroyed in SessionListener does not get called on Context destruction

[Elie Medeiros]

Hi there,

I have some tidying up to do on session destruction, which doesn't take
place when the context gets destroyed.

I am having a problem with my HttpSessionListener. It works fine when
the session is invalidated within tomcat by session.invalidate() (eg
when a user logs off), but the sessionDestroyed method does not seem to
get called when the context gets destroyed.

I have tried adding a session register with a list of all live
sessions, held as a context attribute using context.setAttribute(String,
Object). This gets called in the contextDestroyed method of the
ServletContextListener, and tried to invalidate each existing session
manually. This doesn't work however - it throws a NullPointerException
on the session object, presumably because the session doesn't exist
anymore at that point.

Any suggestions on how to get around this? I am using Tomcat 4.1.18 on
Win2k.

thanks,
Elie

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: sessionDestroyed in SessionListener does not get called on Context destruction

[Shapira, Yoav]

Hi,
Context destruction does not mean session destruction: that would be a
violation of the servlet specification ;)  The container must try to
persist data for active sessions across restarts in a robust way (I've
always had an issue for that robust word in the spec, but that's another
battle).

By the time contextDestroyed is called, all session passivation has been
done, hence your NPE.  (This is also per the servlet spec).

If you want your sessions destroyed or not persisted, consider a
different configuration for your Manager element in server.xml.

Yoav Shapira
Millennium ChemInformatics


-Original Message-
From: Elie Medeiros [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 09, 2004 7:56 AM
To: [EMAIL PROTECTED]
Subject: sessionDestroyed in SessionListener does not get called on
Context
destruction

Hi there,

I have some tidying up to do on session destruction, which doesn't take
place when the context gets destroyed.

I am having a problem with my HttpSessionListener. It works fine when
the session is invalidated within tomcat by session.invalidate() (eg
when a user logs off), but the sessionDestroyed method does not seem to
get called when the context gets destroyed.

I have tried adding a session register with a list of all live
sessions, held as a context attribute using
context.setAttribute(String,
Object). This gets called in the contextDestroyed method of the
ServletContextListener, and tried to invalidate each existing session
manually. This doesn't work however - it throws a NullPointerException
on the session object, presumably because the session doesn't exist
anymore at that point.

Any suggestions on how to get around this? I am using Tomcat 4.1.18 on
Win2k.

thanks,
Elie

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: sessionDestroyed in SessionListener does not get called on Context destruction

[Elie Medeiros]

Thanks Yoav - will check that out.

Elie

 
 Hi,
 Context destruction does not mean session destruction: that would be a
 violation of the servlet specification ;)  The container must try to
 persist data for active sessions across restarts in a robust way (I've
 always had an issue for that robust word in the spec, but that's another
 battle).
 
 By the time contextDestroyed is called, all session passivation has been
 done, hence your NPE.  (This is also per the servlet spec).
 
 If you want your sessions destroyed or not persisted, consider a
 different configuration for your Manager element in server.xml.
 
 Yoav Shapira
 Millennium ChemInformatics
 
 
 -Original Message-
 From: Elie Medeiros [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, March 09, 2004 7:56 AM
 To: [EMAIL PROTECTED]
 Subject: sessionDestroyed in SessionListener does not get called on
 Context
 destruction
 
 Hi there,
 
 I have some tidying up to do on session destruction, which doesn't take
 place when the context gets destroyed.
 
 I am having a problem with my HttpSessionListener. It works fine when
 the session is invalidated within tomcat by session.invalidate() (eg
 when a user logs off), but the sessionDestroyed method does not seem to
 get called when the context gets destroyed.
 
 I have tried adding a session register with a list of all live
 sessions, held as a context attribute using
 context.setAttribute(String,
 Object). This gets called in the contextDestroyed method of the
 ServletContextListener, and tried to invalidate each existing session
 manually. This doesn't work however - it throws a NullPointerException
 on the session object, presumably because the session doesn't exist
 anymore at that point.
 
 Any suggestions on how to get around this? I am using Tomcat 4.1.18 on
 Win2k.
 
 thanks,
 Elie
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential,
proprietary and/or privileged.  This e-mail is intended only for the
individual(s) to whom it is addressed, and may not be saved, copied,
printed, disclosed or used by anyone else.  If you are not the(an)
intended recipient, please immediately delete this e-mail from your
computer system and notify the sender.  Thank you.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SessionListener

[Shapira, Yoav]

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
Specification listeners.
- SessionListener goes in server.xml, as do all other Tomcat-specific
listeners.

SessionListener is not tied to HttpSessionListener or HttpSession
directly.  You have to do a series of casts.  The event object in the
SessionListener's SessionEvent is a catalina-specific Session
implementation.  It will also implement the HttpSession interface.  So
you can get from one to another by casting, but it's ugly (as is the
whole SessionListener solution).

Let's step back a minute: you have this whole hassle because you want
the user's password.  You want the user's password in order to
authenticate the user.  But with the getUserPrincipal approach, the user
is already authenticated if the Principal is not null.  Alternatively,
if you have some input screen where the user enters the username and
password, grab them there instead of from the session.  I think what's
missing here is the big picture: tell us what you're trying 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: SessionListener

Hi,

Here is how I use the HttpSessionListener.

First I create a Class that implements HttpSessionListener:
package com.gri.web;
import javax.servlet.http.*;
public MySessionListener implements HttpSessionListener
{
   private static int num_sessions = 0;
   private HttpSession session = null;

   public void sessionCreated(HttpSessionEvent se)
{
num_sessions++;
session = se.getSession();
}
public void sessionDestroyed(HttpSessionEvent se)
{ num_session--;}
public static int getNumSessions() {return num_sessions; }
 public static HttpSession getLastSession() { return session;}
}

Now include this in the web.xml for your context (directly after
filterfilter-mapping but before Servlet element):

|listener|
|||  listener-classcom.gri.web.MySessionListener/listener-class
/listener||

now all you have to do is create a JSP:
jsp:root xmlns:jsp=http://java.sun.com/JSP/Page;
jsp:directive.page import=com.gri.web.* /
jsp:text
html
body
|Last user in session:
/jsp:text
jsp:expression
MySessionListener.getLastSession().getAttribute(j_username)
/jsp:expression
|jsp:text
|Username of current person
/jsp:text
jsp:expression
session.getAttribute(j_username)
/jsp:expression
|/jsp:root

|/body
/html
/jsp:root
Hart, Justin wrote:

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.

I also haven't seen how to get a user's 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,
A SessionListener of the org.apache.catalina variety would go in the
same place as all tomcat-specific features:
$CATALINA_HOME/conf/server.xml.  That means the class specified there
must be accessible to the server classloaders, i.e. must reside in
common/lib or higher on the classloader 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: SessionListener

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 firing, any help?

I have a SessionListener that I want to go off when a user


authenticates to


my web app (this is a correct usage, right?)

So, in the web.xml of my app, I would put the lines:

web-app
 listener
 listener-class
 the class
 /listener-class
 /listener
/web-app

This should fire off when the user signs in to the page, correct?

Justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






This e-mail, including any attachments

RE: SessionListener

[Hart, Justin]

Basic authentication.  I figured it wouldn't be hard with Form authentication, but I'm 
using basic in order to match the look and feel of the rest of the site.

Yeah, saw the same problem with Basu's implementation, though I did like the idea.

Justin

-Original Message-
From: Shapira, 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:
- HttpSessionListener goes in web.xml, as do all other Servlet
Specification listeners.
- SessionListener goes in server.xml, as do all other Tomcat-specific
listeners.

SessionListener is not tied to HttpSessionListener or HttpSession
directly.  You have to do a series of casts.  The event object in the
SessionListener's SessionEvent is a catalina-specific Session
implementation.  It will also implement the HttpSession interface.  So
you can get from one to another by casting, but it's ugly (as is the
whole SessionListener solution).

Let's step back a minute: you have this whole hassle because you want
the user's password.  You want the user's password in order to
authenticate the user.  But with the getUserPrincipal approach, the user
is already authenticated if the Principal is not null.  Alternatively,
if you have some input screen where the user enters the username and
password, grab them there instead of from the session.  I think what's
missing here is the big picture: tell us what you're trying 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: SessionListener

Hi,

Here is how I use the HttpSessionListener.

First I create a Class that implements HttpSessionListener:
package com.gri.web;
import javax.servlet.http.*;
public MySessionListener implements HttpSessionListener
{
   private static int num_sessions = 0;
   private HttpSession session = null;

   public void sessionCreated(HttpSessionEvent se)
{
num_sessions++;
session = se.getSession();
}
public void sessionDestroyed(HttpSessionEvent se)
{ num_session--;}
public static int getNumSessions() {return num_sessions; }
 public static HttpSession getLastSession() { return session;}
}

Now include this in the web.xml for your context (directly after
filterfilter-mapping but before Servlet element):

|listener|
|||  listener-classcom.gri.web.MySessionListener/listener-class
/listener||

now all you have to do is create a JSP:
jsp:root xmlns:jsp=http://java.sun.com/JSP/Page;
jsp:directive.page import=com.gri.web.* /
jsp:text
html
body
|Last user in session:
/jsp:text
jsp:expression
MySessionListener.getLastSession().getAttribute(j_username)
/jsp:expression
|jsp:text
|Username of current person
/jsp:text
jsp:expression
session.getAttribute(j_username)
/jsp:expression
|/jsp:root

|/body
/html
/jsp:root
Hart, Justin wrote:

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.

I also haven't seen how to get a user's 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,
A SessionListener of the org.apache.catalina variety would go in the
same place as all tomcat-specific features:
$CATALINA_HOME/conf/server.xml.  That means the class specified there
must be accessible to the server classloaders, i.e. must reside in
common/lib or higher on the classloader 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: SessionListener

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 firing, any help?

I have a SessionListener that I want to go off when a user


authenticates to


my web app (this is a correct usage, right?)

So, in the web.xml of my app, I would put the lines:

web-app
 listener
 listener-class
 the class
 /listener-class
 /listener
/web-app

This should fire off when

RE: SessionListener

[Shapira, Yoav]

Howdy,

Basic authentication.  I figured it wouldn't be hard with Form
authentication, but I'm using basic in order to match the look and feel
of
the rest of the site.

OK, so you have basic authentication. Do you have a security-constraint
defined in web.xml?  A login-config?  You can let tomcat do the
authentication for you, and then use the HttpServletRequest methods
(getRemoteUser, getUserPrincipal, isUserInRole).  This is a standard,
easy, portable way, and you don't have to write any custom tomcat code.
Your webapp will not have access to the user's password, but you won't
need it either since the container will authenticate it for you.

Does that fill your needs?

Yoav Shapira


Yeah, saw the same problem with Basu's implementation, though I did
like
the idea.

Justin

-Original Message-
From: Shapira, 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:
- HttpSessionListener goes in web.xml, as do all other Servlet
Specification listeners.
- SessionListener goes in server.xml, as do all other Tomcat-specific
listeners.

SessionListener is not tied to HttpSessionListener or HttpSession
directly.  You have to do a series of casts.  The event object in the
SessionListener's SessionEvent is a catalina-specific Session
implementation.  It will also implement the HttpSession interface.  So
you can get from one to another by casting, but it's ugly (as is the
whole SessionListener solution).

Let's step back a minute: you have this whole hassle because you want
the user's password.  You want the user's password in order to
authenticate the user.  But with the getUserPrincipal approach, the
user
is already authenticated if the Principal is not null.  Alternatively,
if you have some input screen where the user enters the username and
password, grab them there instead of from the session.  I think what's
missing here is the big picture: tell us what you're trying 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: SessionListener

Hi,

Here is how I use the HttpSessionListener.

First I create a Class that implements HttpSessionListener:
package com.gri.web;
import javax.servlet.http.*;
public MySessionListener implements HttpSessionListener
{
   private static int num_sessions = 0;
   private HttpSession session = null;

   public void sessionCreated(HttpSessionEvent se)
{
num_sessions++;
session = se.getSession();
}
public void sessionDestroyed(HttpSessionEvent se)
{ num_session--;}
public static int getNumSessions() {return num_sessions; }
 public static HttpSession getLastSession() { return session;}
}

Now include this in the web.xml for your context (directly after
filterfilter-mapping but before Servlet element):

|listener|
|||  listener-classcom.gri.web.MySessionListener/listener-class
/listener||

now all you have to do is create a JSP:
jsp:root xmlns:jsp=http://java.sun.com/JSP/Page;
jsp:directive.page import=com.gri.web.* /
jsp:text
html
body
|Last user in session:
/jsp:text
jsp:expression
MySessionListener.getLastSession().getAttribute(j_username)
/jsp:expression
|jsp:text
|Username of current person
/jsp:text
jsp:expression
session.getAttribute(j_username)
/jsp:expression
|/jsp:root

|/body
/html
/jsp:root
Hart, Justin wrote:

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.

I also haven't seen how to get a user's 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,
A SessionListener of the org.apache.catalina variety would go in the
same place as all tomcat-specific features:
$CATALINA_HOME/conf/server.xml.  That means the class specified there
must be accessible to the server classloaders, i.e. must reside in
common/lib or higher on the classloader 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: SessionListener

Ok, so, the listener in there must implement HttpSessionListener,
where


can


I use SessionListeners?

Justin

-Original

RE: SessionListener

[Hart, Justin]

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 operates with 
their perms in the database.  My original approach was through realm, but this left 
the problem of figuring out which user was tied to which session.

D'oh!

Nevermind, damnit...  I spent a week doing this, and I figured it out.

I wanted to use session ID, which I don't have in the realm, instead, I use their 
principal!  The principal isn't unique to the session... but it doesn't need to be, in 
fact, it's BETTER if it isn't, because then if the same user logs in multiple times, 
it will share a database connection, meaning I open fewer database connections (of 
which there are a limitted pool).

Ok, so my realm implementation will authenticate to the database, the JSP will use the 
userprincipal to pair 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 authentication.  I figured it wouldn't be hard with Form
authentication, but I'm using basic in order to match the look and feel
of
the rest of the site.

OK, so you have basic authentication. Do you have a security-constraint
defined in web.xml?  A login-config?  You can let tomcat do the
authentication for you, and then use the HttpServletRequest methods
(getRemoteUser, getUserPrincipal, isUserInRole).  This is a standard,
easy, portable way, and you don't have to write any custom tomcat code.
Your webapp will not have access to the user's password, but you won't
need it either since the container will authenticate it for you.

Does that fill your needs?

Yoav Shapira


Yeah, saw the same problem with Basu's implementation, though I did
like
the idea.

Justin

-Original Message-
From: Shapira, 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:
- HttpSessionListener goes in web.xml, as do all other Servlet
Specification listeners.
- SessionListener goes in server.xml, as do all other Tomcat-specific
listeners.

SessionListener is not tied to HttpSessionListener or HttpSession
directly.  You have to do a series of casts.  The event object in the
SessionListener's SessionEvent is a catalina-specific Session
implementation.  It will also implement the HttpSession interface.  So
you can get from one to another by casting, but it's ugly (as is the
whole SessionListener solution).

Let's step back a minute: you have this whole hassle because you want
the user's password.  You want the user's password in order to
authenticate the user.  But with the getUserPrincipal approach, the
user
is already authenticated if the Principal is not null.  Alternatively,
if you have some input screen where the user enters the username and
password, grab them there instead of from the session.  I think what's
missing here is the big picture: tell us what you're trying 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: SessionListener

Hi,

Here is how I use the HttpSessionListener.

First I create a Class that implements HttpSessionListener:
package com.gri.web;
import javax.servlet.http.*;
public MySessionListener implements HttpSessionListener
{
   private static int num_sessions = 0;
   private HttpSession session = null;

   public void sessionCreated(HttpSessionEvent se)
{
num_sessions++;
session = se.getSession();
}
public void sessionDestroyed(HttpSessionEvent se)
{ num_session--;}
public static int getNumSessions() {return num_sessions; }
 public static HttpSession getLastSession() { return session;}
}

Now include this in the web.xml for your context (directly after
filterfilter-mapping but before Servlet element):

|listener|
|||  listener-classcom.gri.web.MySessionListener/listener-class
/listener||

now all you have to do is create a JSP:
jsp:root xmlns:jsp=http://java.sun.com/JSP/Page;
jsp:directive.page import=com.gri.web.* /
jsp:text
html
body
|Last user in session:
/jsp:text
jsp:expression
MySessionListener.getLastSession().getAttribute(j_username)
/jsp:expression
|jsp:text
|Username of current person
/jsp:text
jsp:expression
session.getAttribute(j_username)
/jsp:expression
|/jsp:root

|/body
/html
/jsp:root
Hart, Justin wrote:

Ok, still, I haven't found any documentation on how to add

RE: SessionListener

[Shapira, Yoav]

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 may not have to do any custom coding, just the JDBC realm.

Yoav Shapira
Millennium ChemInformatics


-Original 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 operates with their perms in the database.  My original approach
was
through realm, but this left the problem of figuring out which user was
tied to which session.

D'oh!

Nevermind, damnit...  I spent a week doing this, and I figured it out.

I wanted to use session ID, which I don't have in the realm, instead, I
use
their principal!  The principal isn't unique to the session... but it
doesn't need to be, in fact, it's BETTER if it isn't, because then if
the
same user logs in multiple times, it will share a database connection,
meaning I open fewer database connections (of which there are a
limitted
pool).

Ok, so my realm implementation will authenticate to the database, the
JSP
will use the userprincipal to pair 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 authentication.  I figured it wouldn't be hard with Form
authentication, but I'm using basic in order to match the look and
feel
of
the rest of the site.

OK, so you have basic authentication. Do you have a security-constraint
defined in web.xml?  A login-config?  You can let tomcat do the
authentication for you, and then use the HttpServletRequest methods
(getRemoteUser, getUserPrincipal, isUserInRole).  This is a standard,
easy, portable way, and you don't have to write any custom tomcat code.
Your webapp will not have access to the user's password, but you won't
need it either since the container will authenticate it for you.

Does that fill your needs?

Yoav Shapira


Yeah, saw the same problem with Basu's implementation, though I did
like
the idea.

Justin

-Original Message-
From: Shapira, 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:
- HttpSessionListener goes in web.xml, as do all other Servlet
Specification listeners.
- SessionListener goes in server.xml, as do all other Tomcat-specific
listeners.

SessionListener is not tied to HttpSessionListener or HttpSession
directly.  You have to do a series of casts.  The event object in the
SessionListener's SessionEvent is a catalina-specific Session
implementation.  It will also implement the HttpSession interface.  So
you can get from one to another by casting, but it's ugly (as is the
whole SessionListener solution).

Let's step back a minute: you have this whole hassle because you want
the user's password.  You want the user's password in order to
authenticate the user.  But with the getUserPrincipal approach, the
user
is already authenticated if the Principal is not null.  Alternatively,
if you have some input screen where the user enters the username and
password, grab them there instead of from the session.  I think what's
missing here is the big picture: tell us what you're trying 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: SessionListener

Hi,

Here is how I use the HttpSessionListener.

First I create a Class that implements HttpSessionListener:
package com.gri.web;
import javax.servlet.http.*;
public MySessionListener implements HttpSessionListener
{
   private static int num_sessions = 0;
   private HttpSession session = null;

   public void sessionCreated(HttpSessionEvent se)
{
num_sessions++;
session = se.getSession();
}
public void sessionDestroyed(HttpSessionEvent se)
{ num_session--;}
public static int getNumSessions() {return num_sessions; }
 public static HttpSession getLastSession() { return session;}
}

Now include this in the web.xml for your context (directly after
filterfilter-mapping but before Servlet element):

|listener|
|||  listener-classcom.gri.web.MySessionListener/listener-class
/listener||

now all you have to do is create a JSP:
jsp:root xmlns:jsp=http://java.sun.com/JSP

RE: SessionListener

[Hart, 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.

Thanks for bouncing ideas off me!  It's been most fun :-)

-Original Message-
From: Shapira, Yoav [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 may not have to do any custom coding, just the JDBC realm.

Yoav Shapira
Millennium ChemInformatics


-Original 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 operates with their perms in the database.  My original approach
was
through realm, but this left the problem of figuring out which user was
tied to which session.

D'oh!

Nevermind, damnit...  I spent a week doing this, and I figured it out.

I wanted to use session ID, which I don't have in the realm, instead, I
use
their principal!  The principal isn't unique to the session... but it
doesn't need to be, in fact, it's BETTER if it isn't, because then if
the
same user logs in multiple times, it will share a database connection,
meaning I open fewer database connections (of which there are a
limitted
pool).

Ok, so my realm implementation will authenticate to the database, the
JSP
will use the userprincipal to pair 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 authentication.  I figured it wouldn't be hard with Form
authentication, but I'm using basic in order to match the look and
feel
of
the rest of the site.

OK, so you have basic authentication. Do you have a security-constraint
defined in web.xml?  A login-config?  You can let tomcat do the
authentication for you, and then use the HttpServletRequest methods
(getRemoteUser, getUserPrincipal, isUserInRole).  This is a standard,
easy, portable way, and you don't have to write any custom tomcat code.
Your webapp will not have access to the user's password, but you won't
need it either since the container will authenticate it for you.

Does that fill your needs?

Yoav Shapira


Yeah, saw the same problem with Basu's implementation, though I did
like
the idea.

Justin

-Original Message-
From: Shapira, 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:
- HttpSessionListener goes in web.xml, as do all other Servlet
Specification listeners.
- SessionListener goes in server.xml, as do all other Tomcat-specific
listeners.

SessionListener is not tied to HttpSessionListener or HttpSession
directly.  You have to do a series of casts.  The event object in the
SessionListener's SessionEvent is a catalina-specific Session
implementation.  It will also implement the HttpSession interface.  So
you can get from one to another by casting, but it's ugly (as is the
whole SessionListener solution).

Let's step back a minute: you have this whole hassle because you want
the user's password.  You want the user's password in order to
authenticate the user.  But with the getUserPrincipal approach, the
user
is already authenticated if the Principal is not null.  Alternatively,
if you have some input screen where the user enters the username and
password, grab them there instead of from the session.  I think what's
missing here is the big picture: tell us what you're trying 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: SessionListener

Hi,

Here is how I use the HttpSessionListener.

First I create a Class that implements HttpSessionListener:
package com.gri.web;
import javax.servlet.http.*;
public MySessionListener implements HttpSessionListener
{
   private static int num_sessions = 0;
   private HttpSession session = null;

   public void sessionCreated(HttpSessionEvent se)
{
num_sessions++;
session = se.getSession();
}
public void sessionDestroyed(HttpSessionEvent se)
{ num_session

Re: SessionListener

[Christopher Schultz]

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 there a particular reason for the database access paranoia? Most apps
connect to the db using the same login regardless of the user actually 
logged in to the application. They use other types of permission 
checking to see if you can perform some action, instead of relying on 
thr database for that kind of checking.

I absolutely agree that having multiple layers of security is great, but 
this one may make your application suck really bad, especially if you 
are using a db like Oracle, where the database connections are anything 
but lightweight.

-chris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SessionListener

[Hart, Justin]

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 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 there a particular reason for the database access paranoia? Most apps
connect to the db using the same login regardless of the user actually 
logged in to the application. They use other types of permission 
checking to see if you can perform some action, instead of relying on 
thr database for that kind of checking.

I absolutely agree that having multiple layers of security is great, but 
this one may make your application suck really bad, especially if you 
are using a db like Oracle, where the database connections are anything 
but lightweight.

-chris


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

SessionListener

[Hart, Justin]

My SessionListener doesn't seem to be firing, any help?

I have a SessionListener that I want to go off when a user authenticates to my web app 
(this is a correct usage, right?)

So, in the web.xml of my app, I would put the lines:

web-app
listener
listener-class
the class
/listener-class
/listener
/web-app

This should fire off when the user signs in to the page, correct?

Justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SessionListener

[Hart, Justin]

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 firing, any help?

I have a SessionListener that I want to go off when a user authenticates to my web app 
(this is a correct usage, right?)

So, in the web.xml of my app, I would put the lines:

web-app
listener
listener-class
the class
/listener-class
/listener
/web-app

This should fire off when the user signs in to the page, correct?

Justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SessionListener

[Shapira, Yoav]

Howdy,
A SessionListener of the org.apache.catalina variety would go in the
same place as all tomcat-specific features:
$CATALINA_HOME/conf/server.xml.  That means the class specified there
must be accessible to the server classloaders, i.e. must reside in
common/lib or higher on the classloader 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: SessionListener

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 firing, any help?

I have a SessionListener that I want to go off when a user
authenticates to
my web app (this is a correct usage, right?)

So, in the web.xml of my app, I would put the lines:

web-app
   listener
   listener-class
   the class
   /listener-class
   /listener
/web-app

This should fire off when the user signs in to the page, correct?

Justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SessionListener

[Hart, Justin]

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.

I also haven't seen how to get a user's 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,
A SessionListener of the org.apache.catalina variety would go in the
same place as all tomcat-specific features:
$CATALINA_HOME/conf/server.xml.  That means the class specified there
must be accessible to the server classloaders, i.e. must reside in
common/lib or higher on the classloader 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: SessionListener

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 firing, any help?

I have a SessionListener that I want to go off when a user
authenticates to
my web app (this is a correct usage, right?)

So, in the web.xml of my app, I would put the lines:

web-app
   listener
   listener-class
   the class
   /listener-class
   /listener
/web-app

This should fire off when the user signs in to the page, correct?

Justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SessionListener

[Shapira, Yoav]

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 className=mypackage.myclass ... /  There is a generic
example in the Engine configuration reference, and another more specific
example in the Host configuration reference.  Neither, however, is a
SessionListener example.

There IS one specific, full-features SessionListener example: the
SingleSignOn valve.  It's present (but commented out) in server.xml by
default, and you can take a look at the source code.  It's a more
complicated and confusing example because it's also a Valve ;(  But then
again, I wouldn't even bother with this whole approach when you have the
HttpSessionListener as part of the servlet specification.

where ... are attributes specific to your listener.  (The astute reader
would recognize the above as a commons Digester bean-based
initialization pattern).

I also haven't seen how to get a user's credentials from a HttpSession,
or
how to get a Session from an HttpSessionListener.  Could you throw me a
bone?

If the user is authenticated by the server, typically the information is
not in the session, it's in the request:
HttpServletRequest#getUserPrincipal.  A common use-case is to stuff this
in the session via a filter.

If you had an attribute called username that something was stuffing into
the session, i.e. something like a filter calling
session.setAttribute(username, something), then an
HttpSessionAttributeListener's attributeAdded would be called with the
attribute name and latest value.

Yoav




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SessionListener

[Hart, Justin]

I still don't see how one gets a session from HttpSession or user credentials?  I see 
how to get a UserPrincipal, but without the password, I still can't authenticate the 
user :-/  Am I missing something?

Justin

-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: 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 is the similar but not quite the same to the portable one:
listener className=mypackage.myclass ... /  There is a generic
example in the Engine configuration reference, and another more specific
example in the Host configuration reference.  Neither, however, is a
SessionListener example.

There IS one specific, full-features SessionListener example: the
SingleSignOn valve.  It's present (but commented out) in server.xml by
default, and you can take a look at the source code.  It's a more
complicated and confusing example because it's also a Valve ;(  But then
again, I wouldn't even bother with this whole approach when you have the
HttpSessionListener as part of the servlet specification.

where ... are attributes specific to your listener.  (The astute reader
would recognize the above as a commons Digester bean-based
initialization pattern).

I also haven't seen how to get a user's credentials from a HttpSession,
or
how to get a Session from an HttpSessionListener.  Could you throw me a
bone?

If the user is authenticated by the server, typically the information is
not in the session, it's in the request:
HttpServletRequest#getUserPrincipal.  A common use-case is to stuff this
in the session via a filter.

If you had an attribute called username that something was stuffing into
the session, i.e. something like a filter calling
session.setAttribute(username, something), then an
HttpSessionAttributeListener's attributeAdded would be called with the
attribute name and latest value.

Yoav




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SessionListener

[Atreya Basu]

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 examples.

Cheers,

Shapira, Yoav wrote:

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 className=mypackage.myclass ... /  There is a generic
example in the Engine configuration reference, and another more specific
example in the Host configuration reference.  Neither, however, is a
SessionListener example.
There IS one specific, full-features SessionListener example: the
SingleSignOn valve.  It's present (but commented out) in server.xml by
default, and you can take a look at the source code.  It's a more
complicated and confusing example because it's also a Valve ;(  But then
again, I wouldn't even bother with this whole approach when you have the
HttpSessionListener as part of the servlet specification.
where ... are attributes specific to your listener.  (The astute reader
would recognize the above as a commons Digester bean-based
initialization pattern).
 

I also haven't seen how to get a user's credentials from a HttpSession,
   

or
 

how to get a Session from an HttpSessionListener.  Could you throw me a
bone?
   

If the user is authenticated by the server, typically the information is
not in the session, it's in the request:
HttpServletRequest#getUserPrincipal.  A common use-case is to stuff this
in the session via a filter.
If you had an attribute called username that something was stuffing into
the session, i.e. something like a filter calling
session.setAttribute(username, something), then an
HttpSessionAttributeListener's attributeAdded would be called with the
attribute name and latest value.
Yoav



This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged.  This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender.  Thank you.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

--

Developer
Greenfield Research Inc.
atreya(AT)greenfieldresearch(DOT)ca
(902)422-9426


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SessionListener

[Hart, Justin]

If this can be done with HttpSessionListener, than I am game.

What I want to do, is get the username and password when the user signs on, so I can 
then use this data to authenticate the user to other programs as themselves.

I'm using BASIC authentication, and trying to avoid having them sign 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,

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 examples.

Cheers,

Shapira, Yoav wrote:

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 className=mypackage.myclass ... /  There is a generic
example in the Engine configuration reference, and another more specific
example in the Host configuration reference.  Neither, however, is a
SessionListener example.

There IS one specific, full-features SessionListener example: the
SingleSignOn valve.  It's present (but commented out) in server.xml by
default, and you can take a look at the source code.  It's a more
complicated and confusing example because it's also a Valve ;(  But then
again, I wouldn't even bother with this whole approach when you have the
HttpSessionListener as part of the servlet specification.

where ... are attributes specific to your listener.  (The astute reader
would recognize the above as a commons Digester bean-based
initialization pattern).

  

I also haven't seen how to get a user's credentials from a HttpSession,


or
  

how to get a Session from an HttpSessionListener.  Could you throw me a
bone?



If the user is authenticated by the server, typically the information is
not in the session, it's in the request:
HttpServletRequest#getUserPrincipal.  A common use-case is to stuff this
in the session via a filter.

If you had an attribute called username that something was stuffing into
the session, i.e. something like a filter calling
session.setAttribute(username, something), then an
HttpSessionAttributeListener's attributeAdded would be called with the
attribute name and latest value.

Yoav




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  


-- 

Developer
Greenfield Research Inc.
atreya(AT)greenfieldresearch(DOT)ca
(902)422-9426



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SessionListener

[Atreya Basu]

Hi,

Here is how I use the HttpSessionListener.

First I create a Class that implements HttpSessionListener:
package com.gri.web;
import javax.servlet.http.*;
public MySessionListener implements HttpSessionListener
{
  private static int num_sessions = 0;
  private HttpSession session = null;
  public void sessionCreated(HttpSessionEvent se)
   {
   num_sessions++;
   session = se.getSession();
   }
   public void sessionDestroyed(HttpSessionEvent se)
   { num_session--;}
   public static int getNumSessions() {return num_sessions; }
public static HttpSession getLastSession() { return session;}
}
Now include this in the web.xml for your context (directly after 
filterfilter-mapping but before Servlet element):

|listener|
|||  listener-classcom.gri.web.MySessionListener/listener-class
/listener||
now all you have to do is create a JSP:
jsp:root xmlns:jsp=http://java.sun.com/JSP/Page;
jsp:directive.page import=com.gri.web.* /
jsp:text
html
body
|Last user in session:
/jsp:text
jsp:expression
MySessionListener.getLastSession().getAttribute(j_username)
/jsp:expression
|jsp:text
|Username of current person
/jsp:text
jsp:expression
session.getAttribute(j_username)
/jsp:expression
|/jsp:root
|/body
/html
/jsp:root
Hart, Justin wrote:
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.

I also haven't seen how to get a user's 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,
A SessionListener of the org.apache.catalina variety would go in the
same place as all tomcat-specific features:
$CATALINA_HOME/conf/server.xml.  That means the class specified there
must be accessible to the server classloaders, i.e. must reside in
common/lib or higher on the classloader 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: SessionListener
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 firing, any help?

I have a SessionListener that I want to go off when a user
   

authenticates to
 

my web app (this is a correct usage, right?)

So, in the web.xml of my app, I would put the lines:

web-app
listener
listener-class
the class
/listener-class
/listener
/web-app
This should fire off when the user signs in to the page, correct?

Justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   





This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged.  This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender.  Thank you.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

--

Developer
Greenfield Research Inc.
atreya(AT)greenfieldresearch(DOT)ca
(902)422-9426


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SessionListener

[Jon Wingfield]

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 somehting like a 
'sessionWillBeDestroyed' event.
since the sessionDestroyed method in a sessionListener seems to be 
called after the session was destroyed.

Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SessionListener

[Peter Maas]

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 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 somehting like a 
'sessionWillBeDestroyed' event.
since the sessionDestroyed method in a sessionListener seems to be 
called after the session was destroyed.

Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SessionListener

[Jon Wingfield]

;) 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 the javadoc in section SRV.15.1.14.1 of the spec.

We're still on 4.1.x and have to jump through a few hoops to properly 
persist data on sessionDestroyed(). :(

You could put in a Bugzilla report against 5.0.12.

Jon

Peter Maas wrote:

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 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 somehting like a 
'sessionWillBeDestroyed' event.
since the sessionDestroyed method in a sessionListener seems to be 
called after the session was destroyed.

Peter




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SessionListener

[Christopher Schultz]

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 container will do is notify you that the session 
is in the process of being destroyed.

-chris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SessionListener

[Peter Maas]

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 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 container will do is notify you that the 
session is in the process of being destroyed.

-chris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SessionListener

[Tim Funk]

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.
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 container will do is notify you that the 
session is in the process of being destroyed.

-chris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SessionListener

[Tatu Vanhanen]

 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 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 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 container will do is notify you that the
  session is in the process of being destroyed.
 
  -chris
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SessionListener

[Christopher Schultz]

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SessionListener

[Jean-Francois Arcand]

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 want.

-- Jeanfrancois



Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

SessionListener

[Peter Maas]

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.

Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: SessionListener does not get enough information

[Software AG]

Hi, Craig.

I am not convinced that it makes sense to keep SessionID and according
information inside the DB. Of what use is the session attribute architecture
then? All that would happen is that I need a session to somehow generate a
unique ID, and all information is then stored inside my DB. That means I
reproduce all the session handling code.

Maybe I missed something in the servlet spec 2.3, but can you please point
me to the section that says something like ...session attributes must be
deleted before the session destroyed event is fired...?

If that does not exist, does it harm to swap the few lines? It would do so
much good for application programming. And if not, it might be nice to
split the event into session_will_be_destroyed and
session_has_been_destroyed. I bet a lot of listeners are more interested in
the first.

Hiran


 -Ursprüngliche Nachricht-
 Von: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
 Gesendet: Montag, 24. Juni 2002 18:28
 An: Tomcat Users List
 Betreff: RE: SessionListener does not get enough information
 
 
 
 
 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 into this problem yesterday. I don't 
 understand why the
  sessionlistener is designed this way...
 
 Well, the servlet spec does mandate calls in this order ... 
 which makes
 much more logical sense than the alternative (session is 
 destroyed but it
 still has things in it???).
 
 For your problem at hand, some appropriate database design 
 should do the
 trick -- simply expose session_id as a column in the database tables
 containing the transactional information.  In your sessionDestroyed()
 method, execute a SQL statement like
 
   delete from transaction_table where session_id = ?
 
 because you can still get the session id out of the session destroyed
 event.  You'll want to consider indexing on session_id to make this
 operation run quickly enough.
 
 Craig McClanahan
 
 
  (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 removed.
  So, I use this attribute value for my work.
  Offcourse, it's not perfect and it might be pronable to 
 mistakes, but this
  is the fastest way for me to solve the problem.
  Regards,
  Tamir
 
 
  -Original Message-
  From: Software AG [mailto:[EMAIL PROTECTED]]
  Sent: Monday, June 24, 2002 1:25 PM
  To: Tomcat Users List
  Subject: SessionListener does not get enough information
 
 
  Hi there.
 
  I have a web application that stores some information into 
 a database.
  Now if the transaction is not complete (which means the 
 user did not go
  through a page asking do you want to save [y/n]?) all 
 stored data shall be
  dropped again. I detect this dropped transaction with a 
 SessionListener,
  since after some time all inactive sessions are discarded.
 
  The problem is now that when the 
 SessionListener.sessionDestroyed method is
  called, all attributed have already been removed from the 
 session, so I do
  not really know what data needs to be deleted.
 
  In my eyes the real solution is to change the code in
  StandardSession.expire() to first fire the event and then clear the
  attributes. But I do not want to rely on anyone installing that web
  application to have a modified version of Tomcat.
 
  Does anyone know about an elegant workaround for this problem?
 
  Hiran
 
  --
  To unsubscribe, e-mail:
  mailto:[EMAIL PROTECTED]
  For additional commands, e-mail:
  mailto:[EMAIL PROTECTED]
 
  --
  To unsubscribe, e-mail:   
mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
mailto:[EMAIL PROTECTED]




--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: AW: SessionListener does not get enough information

[Craig R. McClanahan]

On Tue, 25 Jun 2002, Software AG wrote:

 Date: Tue, 25 Jun 2002 10:47:14 +0200
 From: Software AG [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: 'Tomcat Users List' [EMAIL PROTECTED]
 Subject: AW: SessionListener does not get enough information

 Hi, Craig.

 I am not convinced that it makes sense to keep SessionID and according
 information inside the DB. Of what use is the session attribute architecture
 then? All that would happen is that I need a session to somehow generate a
 unique ID, and all information is then stored inside my DB. That means I
 reproduce all the session handling code.


Why?  The servlet container already computes a unique (within the scope of
a particular webapp) id for you, and makes it accessible.  Just save the
session id in a separate column as you store the session-related stuff in
the database and you can do the delete I proposed later.

 Maybe I missed something in the servlet spec 2.3, but can you please point
 me to the section that says something like ...session attributes must be
 deleted before the session destroyed event is fired...?


Rats ... all I've got are my notes of discussions with the spec lead where
this was the intended behavior; it wasn't spelled out specifically.  I
will add this to the list of stuff that needs to be clarified in 2.4
(which should go into public review shortly).

 If that does not exist, does it harm to swap the few lines? It would do so
 much good for application programming. And if not, it might be nice to
 split the event into session_will_be_destroyed and
 session_has_been_destroyed. I bet a lot of listeners are more interested in
 the first.


Making this change would have a very adverse effect.  Consider what your
attribute removed listener assumes it can do -- access other things in
the session, right?  But you'd get IllegalStateExceptions now, because the
session has already been invalidated.  That makes no sense at all -- it
should be called

Note that the same design pattern applies with servlet context listeners
-- at application shutdown, the context attributes are removed first,
before contextDestroyed() is called.

 Hiran


Craig


  -Ursprüngliche Nachricht-
  Von: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
  Gesendet: Montag, 24. Juni 2002 18:28
  An: Tomcat Users List
  Betreff: RE: SessionListener does not get enough information
 
 
 
 
  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 into this problem yesterday. I don't
  understand why the
   sessionlistener is designed this way...
 
  Well, the servlet spec does mandate calls in this order ...
  which makes
  much more logical sense than the alternative (session is
  destroyed but it
  still has things in it???).
 
  For your problem at hand, some appropriate database design
  should do the
  trick -- simply expose session_id as a column in the database tables
  containing the transactional information.  In your sessionDestroyed()
  method, execute a SQL statement like
 
delete from transaction_table where session_id = ?
 
  because you can still get the session id out of the session destroyed
  event.  You'll want to consider indexing on session_id to make this
  operation run quickly enough.
 
  Craig McClanahan
 
 
   (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 removed.
   So, I use this attribute value for my work.
   Offcourse, it's not perfect and it might be pronable to
  mistakes, but this
   is the fastest way for me to solve the problem.
   Regards,
   Tamir
  
  
   -Original Message-
   From: Software AG [mailto:[EMAIL PROTECTED]]
   Sent: Monday, June 24, 2002 1:25 PM
   To: Tomcat Users List
   Subject: SessionListener does not get enough information
  
  
   Hi there.
  
   I have a web application that stores some information into
  a database.
   Now if the transaction is not complete (which means the
  user did not go
   through a page asking do you want to save [y/n]?) all
  stored data shall be
   dropped again. I detect this dropped transaction with a
  SessionListener,
   since after some time all inactive sessions are discarded.
  
   The problem is now that when the
  SessionListener.sessionDestroyed method is
   called, all attributed have already been removed from the
  session, so I do
   not really know what data needs to be deleted.
  
   In my eyes the real solution is to change the code in
   StandardSession.expire() to first fire the event and then clear the
   attributes. But I do not want to rely on anyone installing that web
   application to have a modified version of Tomcat.
  
   Does

SessionListener does not get enough information

[Software AG]

Hi there.

I have a web application that stores some information into a database.
Now if the transaction is not complete (which means the user did not go
through a page asking do you want to save [y/n]?) all stored data shall be
dropped again. I detect this dropped transaction with a SessionListener,
since after some time all inactive sessions are discarded.

The problem is now that when the SessionListener.sessionDestroyed method is
called, all attributed have already been removed from the session, so I do
not really know what data needs to be deleted.

In my eyes the real solution is to change the code in
StandardSession.expire() to first fire the event and then clear the
attributes. But I do not want to rely on anyone installing that web
application to have a modified version of Tomcat.

Does anyone know about an elegant workaround for this problem?

Hiran

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: SessionListener does not get enough information

[tamir]

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 removed.
So, I use this attribute value for my work.
Offcourse, it's not perfect and it might be pronable to mistakes, but this
is the fastest way for me to solve the problem.
Regards,
Tamir


-Original Message-
From: Software AG [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 24, 2002 1:25 PM
To: Tomcat Users List
Subject: SessionListener does not get enough information


Hi there.

I have a web application that stores some information into a database.
Now if the transaction is not complete (which means the user did not go
through a page asking do you want to save [y/n]?) all stored data shall be
dropped again. I detect this dropped transaction with a SessionListener,
since after some time all inactive sessions are discarded.

The problem is now that when the SessionListener.sessionDestroyed method is
called, all attributed have already been removed from the session, so I do
not really know what data needs to be deleted.

In my eyes the real solution is to change the code in
StandardSession.expire() to first fire the event and then clear the
attributes. But I do not want to rely on anyone installing that web
application to have a modified version of Tomcat.

Does anyone know about an elegant workaround for this problem?

Hiran

--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

AW: SessionListener does not get enough information

[Ralph Einfeldt]

Define a class (bean) that store the information
that the user has to confirm. Let this classs
implement the HttpSessionBindingListener
and do the 'rollback' in the valueUnbound() 
method.

 -Ursprüngliche Nachricht-
 Von: Software AG [mailto:[EMAIL PROTECTED]]
 Gesendet: Montag, 24. Juni 2002 13:25
 An: Tomcat Users List
 Betreff: SessionListener does not get enough information
 
 I have a web application that stores some information into a database.
 Now if the transaction is not complete (which means the 
 user did not go through a page asking do you want to save [y/n]?)
all 
 stored data shall be dropped again. I detect this dropped
transaction 
 with a SessionListener, since after some time all inactive sessions
are 
 discarded.
 

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: SessionListener does not get enough information

[Gabriel Gajdos]

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 Hashtable (scope application) with objects for your session identified by 
key sessionID String.

On sessionCreated you add some pointer to your temporary data
On sessionDestroyed you just take the correct object and drop its data.

Another way is to use finalizers (= I do not recommend).

GG


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: SessionListener does not get enough information

[Craig R. McClanahan]

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 into this problem yesterday. I don't understand why the
 sessionlistener is designed this way...

Well, the servlet spec does mandate calls in this order ... which makes
much more logical sense than the alternative (session is destroyed but it
still has things in it???).

For your problem at hand, some appropriate database design should do the
trick -- simply expose session_id as a column in the database tables
containing the transactional information.  In your sessionDestroyed()
method, execute a SQL statement like

  delete from transaction_table where session_id = ?

because you can still get the session id out of the session destroyed
event.  You'll want to consider indexing on session_id to make this
operation run quickly enough.

Craig McClanahan


 (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 removed.
 So, I use this attribute value for my work.
 Offcourse, it's not perfect and it might be pronable to mistakes, but this
 is the fastest way for me to solve the problem.
 Regards,
 Tamir


 -Original Message-
 From: Software AG [mailto:[EMAIL PROTECTED]]
 Sent: Monday, June 24, 2002 1:25 PM
 To: Tomcat Users List
 Subject: SessionListener does not get enough information


 Hi there.

 I have a web application that stores some information into a database.
 Now if the transaction is not complete (which means the user did not go
 through a page asking do you want to save [y/n]?) all stored data shall be
 dropped again. I detect this dropped transaction with a SessionListener,
 since after some time all inactive sessions are discarded.

 The problem is now that when the SessionListener.sessionDestroyed method is
 called, all attributed have already been removed from the session, so I do
 not really know what data needs to be deleted.

 In my eyes the real solution is to change the code in
 StandardSession.expire() to first fire the event and then clear the
 attributes. But I do not want to rely on anyone installing that web
 application to have a modified version of Tomcat.

 Does anyone know about an elegant workaround for this problem?

 Hiran

 --
 To unsubscribe, e-mail:
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]

 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

SessionListener

[Alin Simionoiu]

Does anybody use SessionListener?..
I try to use this, but is absolutly an nightmare to 
put everithing in place.
I cannot find a very clear documentation about how 
the web.xml file should be set.

Alin

RE: SessionListener

[William Kaufman]

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?

-- Bill K.

-Original Message-
From: Alin Simionoiu [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 2:20 PM
To: [EMAIL PROTECTED]
Subject: SessionListener


Does anybody use SessionListener?..
I try to use this, but is absolutly an nightmare to put everithing in place.
I cannot find a very clear documentation about how the web.xml file should
be set.

Alin

RE: SessionListener

[Robert Petersen]

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 or in the right 
directory in the
WEB-INF/classes.

- 
Robert
http://www.orangefood.com

  -Original Message-From: Alin Simionoiu 
  [mailto:[EMAIL PROTECTED]]Sent: Thursday, May 17, 2001 2:20 
  PMTo: [EMAIL PROTECTED]Subject: 
  SessionListener
  Does anybody use SessionListener?..
  I try to use this, but is absolutly an nightmare 
  to put everithing in place.
  I cannot find a very clear documentation about 
  how the web.xml file should be set.
  
  Alin

Re: SessionListener

[Alin Simionoiu]

In Servlet API spec, which is in this moment in draft, is added the concept
of HttpSessionListener.
Using this you can receive events like SessionCreated and SessionDestroyed.
I try to use those events, but I didn't find any good documentation.

It's seems that, after you build a class 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 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?

 -- Bill K.

 -Original Message-
 From: Alin Simionoiu [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, May 17, 2001 2:20 PM
 To: [EMAIL PROTECTED]
 Subject: SessionListener


 Does anybody use SessionListener?..
 I try to use this, but is absolutly an nightmare to put everithing in
place.
 I cannot find a very clear documentation about how the web.xml file should
 be set.

 Alin

Re: SessionListener

[Alin Simionoiu]

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
 of HttpSessionListener.
 Using this you can receive events like SessionCreated and
SessionDestroyed.
 I try to use those events, but I didn't find any good documentation.

 It's seems that, after you build a class 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 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?
 
  -- Bill K.
 
  -Original Message-
  From: Alin Simionoiu [mailto:[EMAIL PROTECTED]]
  Sent: Thursday, May 17, 2001 2:20 PM
  To: [EMAIL PROTECTED]
  Subject: SessionListener
 
 
  Does anybody use SessionListener?..
  I try to use this, but is absolutly an nightmare to put everithing in
 place.
  I cannot find a very clear documentation about how the web.xml file
should
  be set.
 
  Alin