This week's book giveaway is in the Other Open Source APIs forum. We're giving away four copies of Storm Applied and have Sean Allen, Peter Pathirana & Matthew Jankowski on-line! See this thread for details.
A request doesn't get you a session. The moment you need to put something in a session, and call the getSession() method on the request object, the container will create a session object for you. This object exists on the server. The container will also send a jsessionid in the response, which is stored in a cookie on the client (if you've got cookies enabled). Then, you will automatically send that jsessionid in the header with every request to the server, so that the container recognizes that you're the user that can speak to that particular session object. This is the container's way of maintaining state.
an HttpSessionListener just listens for certain lifecycle events in any session object, and performs a corresponding action. It has nothing to do with who has access to what.
An HttpSession object can span many requests, and many HttpSessionListeners can be registered for any and all HttpSessions.
Chanakya Gupta wrote:Summing up from Dieter and Sourabh,
- any part of the webapp can access this sessionid
(with access to request and event)
The part in the parenthesis is important here.
A ServletContextListener, for example, would not be able to access a session.
Likewise the init method in a servlet has no way to access any session information because servlets can be configured to be loaded when the container starts up, before any actual requests have been made.