Thanks for addressing this gap in functionality! Did you consider an Application#sessionUnbound(o.a.w.Session) overload? It seems like that would have better symmetry with Application#newSession(). Also in my mind Sessions should simply hold data, not business logic.
In our app we don't even have a custom Session. We just use a RequestCycle subclass which stores object keys in session metadata. I started this pattern after people kept putting non-threadsafe beans into the Session (myself included :)). But maybe this is not common. Dan On Thu, Mar 8, 2012 at 8:11 AM, Martin Grigorov <[email protected]>wrote: > Hi, > > At https://issues.apache.org/jira/browse/WICKET-4444 I attached a > patch that allows users' sessions to be notified when the related http > session is invalidated > either with httpSession.invalidate() or due to inactivity by the user. > Users have been asked several times in the mailing lists for this > functionality. > > When the callback method (Session#onInvalidate) is called because of > httpSession#invalidate() then this is a http request thread and the > thread locals are available but > when it is called due to user inactivity then those are not available. > This will be properly documented. > > WDYT? Do you see problems with it ? > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com >
