I've often wished when developing web apps that I could have more
insight into user's sessions (i.e. what sessions are active, expired,
when was the session created, etc.) This could be really useful for
an administrative interface, for example.
These types of methods could be useful for that, but don't seem needed
for normal session usage - the user shouldn't even see expired
sessions! (so I agree these shouldn't be in the Session interface) If
anything, I'd move these to a sub-interface called ManagedSession or
something like that. I'm not against removing them completely, but
think it'd be worth talking through the above mentioned usage first.
The SessionEventListener could help solve that usage, although it'd
sure be nice to be able to call SessionManager.getActiveSessions(),
etc. (we'd want to make sure the returned info is immutable for the
most part I think)
I'm not saying we have to fully solve this usage now, just wanted to
consider it before making the decision to remove metadata methods from
the interface.
Jeremy
On Jul 30, 2008, at 11:32 AM, Les Hazlewood wrote:
So in my review of the code in prep for RC1 last night, I found
something
I'd never really thought about before:
Should the Session *Interface* have the two methods
getStopTimestamp() and
isExpired() at all?
I remember those existing in the implementation specifically to
handle the
case where Sessions were persistent beyond their user lifetime -
e.g. in
environments that do user activity reporting, they could organize user
events based on sessions, etc. But the framework couldn't use
stopped or
expired sessions anymore.
It seems as if implementation methods bubbled their way up into the
interface.
Would a user ever need to call getStopTimestamp() or isExpired()?
In our web support for example, these methods would never return
anything
useful: getStopTimestamp() would _always_ return null and
isExpired() would
_always_ return false, because of our WebSessionManager logic:
When a Subject is being constructed for the incoming Request, the
WebSessionManager it tries to acquire the user's corresponding
session (if
it exists). If it does exist, but that session is invalid (that is,
stopped
or expired), it suppresses resulting InvalidSessionException (prints
out a
trace message really) and returns null to the caller. The caller
views this
as an indication that the session doesn't exist, and it must create
a brand
new one if it needs to use a Session.
Because of this logic, those two methods are probably meaningless.
I also
think that our logic to ignore invalid sessions and create a brand
new one
when necessary is the right way to go - it is how web containers
work, and
everyone is pretty much happy with that behavior.
Do you guys agree? Do you see a need to retain them in the
interface? (They
would stay in the implementation because the implementation needs to
use
them to determine if in fact it is invalid or not).
I'm just looking for your thoughts if you have any...
Les
