You haven't really explained what you want to do with the session.
Joined: Jun 28, 2008
I want to store the session in a Map with session related data (such as Creation Time, IP, etc). So I am unsure about the place where I should implement the map to get the data.
When I use the listener, then I can store the HTTPSession but has no access to ServletRequest-Object.
So I assume, that I need only a filter, because a filter has access to the HTTPSession and the ServletRequest-Object. Am I right?
Or do I need both -filter and listener? The clickstream-API needs both, but is it not enough to have only the listener? I mean, when a session is created, then I can get the (requested?) SessionObject from my filter and not only from my listener. Where lies the difference? [ October 16, 2008: Message edited by: nimo frey ]
Why would you want to store a reference to the session? This is odd, uncustomary, and not very safe. You should never be storing references to container resources such as sessions, requests, responses and so on.
I agree with Bear about storing sessions. If clickstream stores the session for what it does then it is poorly designed. It does not need to do it.
From the docs, the Filter is used to track a user's movement through the web site. It gets info for each request and stores it. Where it stores it is unimportant - possible in some user token inside the session or in a context-wide storage location mapped to a user.
The Session Listener is to track when a session ends. When the session ends (presumably user-log out) then the filter is used to send the tracked information into a log file. It could get that information out of the same storage that the filter uses - either from a token in the session, or from a context wide map.
In neither case do you need to store a reference to the session itself, and if clickstream is doing it then it shouldn't be looked at as normal procedure.