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
