> We can make fixes to the 1.0.x branch for you, but I am reluctant to make > changes to the 1.0 version.
Very understandable. We'll just bump up to the 1.0.2 release. That jump has been on the back burner for a while, so it's good to get an excuse to push it through. :-) > You might look into having your session management system let Lift know that > the session is going down. Lift *should* be tied to the container's session > and if it's not working, please get us a repro case and we'll fix it. Looking into it now. It's also possible that Spring Security isn't killing off the session properly, in which case Lift is more than justified in hanging onto whatever information it has left. If it turns out that the session is dying but Lift still isn't firing Unlisten on its own, then I'll do what I can to get you a reproducible test case. Time is a little tight right now though, so I may not be able to do much more than report the bug in a case-less state. > Is this an issue that needs to be solved this week? If not, I'll have more > time next week and can putter around with Jetty and see what I can learn > about what it does with comet, NIO, etc. and see if there's a better way to > give you what you need. The sooner the better, but we understand that you have other things to do. We're going to forge ahead with the Listen/Unlisten trick coupled with some extra hooks in Spring Security working under the assumption that we'll be able to make it solid enough for now. If and when you find a better way to do this, we'll switch to that technique moving forward. So in other words, feel free to putter as soon as you get the chance! We would certainly appreciate anything you can come up with. Daniel -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
