You can't, as this would be a security risk. Atleast it isn't exposed through the J2EE API...
There are two options: 1) get the Tomcat source caode and find out what other public methods are available. 2) get the Tomcat source, and rewrite it to break open the required functionality.
Note I'm not saying you should do the second point, just that you can. The security aspects should not be discounted.
Sounds like this could become pretty Tomcat specific, I'm moving this to the Apache/Tomcat forum.
You're quite right, the way you've approached it, but the problem I find is that when people start building something like this, they can't help re-inventing session manangement and this is something I find very dangerous.
Just to state again Ben's is a workable solution, but don't take it any further!
Originally posted by David O'Meara: You're quite right, the way you've approached it, but the problem I find is that when people start building something like this, they can't help re-inventing session manangement and this is something I find very dangerous.
Just to state again Ben's is a workable solution, but don't take it any further!
Anytime you build something yourself, you need to weigh the 'benefit vs risk' in doing so. If you're going to add this functionality to a real production app, think hard about what you're exposing and to whom.
With this same technique, you could choose to expose only a subset from within your session. For example, you could create a userBean with properties that you want to expose and store a reference to that object instead of the session itself. You could also use the "Facade Pattern" to wrap the sessions that you are exposing which would also allow you to limit what methods and properties are exposed.
In otherwords, building it yourself can be much safer than having the methods exposed as part of the Servlet Spec but it is up to you to understand the risks involved.
Stefan Evans
Bartender
Joined: Jul 06, 2005
Posts: 1005
posted
0
An alternative approach to the SessionListener, is to use a session binding listener.
A lot of web applications require a login, and put a "user" object in session when login is successful. If you make that user object implement "HttpSessionBindingListener" then it will fire an event any time that object is put into a session/removed from a session (ie presumably at Login, and logout/session expiry)
The most common reason I can think of that people want all the current sessions for is to iterate through and find out if that user is logged in already. A HttpSessionBindingListener may be more appropriate way to handle that requirement.
pavan kumar singaraju
Greenhorn
Joined: Aug 29, 2005
Posts: 5
posted
0
HI All, thanks for the good advices and alternatives provided.