yes, I was thinking something like that. Or wrap it in a externalisable/serializable wrapper which has its own read resolve, but I think you idea is probably the better suggestion - thanks for the idea.
Michael. On 9/10/06, Michael Dynan <[EMAIL PROTECTED]> wrote:
Perhaps you could try creating and destroying the JCR sessions when the HttpSession is created/destroyed and passivated. The Servlet API provides the HttpSessionListener and HttpSessionActivationListener interfaces. Create a class that implements these interfaces and the JCR sessions can be created and destroyed at the appropriate times. This should help you work around the fact that the JCR session is not serializable. Michael -- Michael Dynan Director Flat Earth Technologies Limited Tel: +44(0)79 6875 3277 Registered Office: 5 Arlington Drive, Belfast, BT10 0NQ Registered in Northern Ireland No. NI048489 VAT Number: 830 8983 03 On 9 Sep 2006, at 11:54, Tobias Bocanegra wrote: > On 9/8/06, Michael Neale <[EMAIL PROTECTED]> wrote: >> Hi Nico. Is isn't really serialization per se, its more that to >> stuff it in >> a http session it is expected to be serializable. >> >> In my case, I would simply like to keep the Session around for a >> little >> while in a servlet container. > you can just store a token in the httpsession and pool the > jcrsessions yourself. > > -- > -----------------------------------------< [EMAIL PROTECTED] > >--- > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 > Basel > T +41 61 226 98 98, F +41 61 226 98 97 > -----------------------------------------------< http://www.day.com > >---
