On Jan 31, 2008 2:23 AM, Marat Radchenko <[EMAIL PROTECTED]> wrote: > > > <snip /> > > > > > > 3) SingleSignOutHttpSessionListener ticket/session mapping won't > > > survive server restart (even if sessions are not lost). That would be ok > > > if > > > there were any possibility to inject smarter-than-hashmap storage. However > > > it isn't possible, so the only way is a full rewrite. Additionally, it > > > will > > > have troubles in case of many sessions because it stores all of them in > > > memory. > > > > > If you had a JIRA issue I can attempt to make it similar to the > > ProxyReceptorServlet where we provide the base and you implement two methods > > that do the delete/retrieval. Though memory should not be an issue as they > > are only references to the session objects that already exist. And those > > references should be deleted when the session expires. > > > > Well, actually thing are not so simple. Servlet container (if properly > configured) can serialize sessions to persistet store (disk, db or whatever) > in order to free memory. But current implementation > of SingleSignOutHttpSessionListener will still hold references thus > preventing sessions from being garbage collected. >
True, it will hold on to it. Its designed for the "in-memory" case. If we don't store the reference in memory then I don't know how to gain a reference to that session. I don't think the Servlet API exposes a method, does it? I'd prefer not to use container specific versions if possible (because I'm assuming individual containers have a method of retrieving a session based on id). <snip /> > > > Yes, actually it can still be configured via Spring. All of the filters > > should have setters for their various properties. We haven't done extensive > > testing with it, but the goal was to allow you to either use the web.xmlfor > > simple cases, or utilizing something else like Spring. > > > > > Oh. It's my fault, a little misunderstanding of source :) I'm taking my words > back, it really can be configured via spring. > I resolved your JIRA issue about the "totally broken" part :-). It should actually now work in Spring. I added some test cases and a simple Spring configuration example. If we don't resolve the above Session stuff soon I'll cut an RC3 so other people can try out the fix for the Spring stuff (though you can also check it out from Subversion) -Scott
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
