Currently I do have a listener to at least warn me when a session is destroyed and created, but it only tells me after the fact, and I don't think there is a way I can cancel the session creation, and it doesn't tell me who/when/why created the session.
That's why altering the HttpServletRequest is the right way to get closer to the point of action, and I can print out the stack trace at that point to help me figure out who/why created the session. but please, let's keep discussing :) Norbert Sándor wrote: > Maybe throw an exception in HttpSessionListener.sessionCreated() - of > course you should configure your servlet container for this. > > Br, > Norbi > > ----- Original Message ----- From: "Patrick Casey" <[EMAIL PROTECTED]> > To: "'Tapestry users'" <[email protected]> > Sent: Wednesday, July 20, 2005 6:32 PM > Subject: RE: forcing No Server Session > > >> >> How about you just set up a visit object that throws an error in its >> constructor? >> >> --- Pat >> >>> -----Original Message----- >>> From: Fernando Padilla [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, July 20, 2005 9:25 AM >>> To: Tapestry users >>> Subject: forcing No Server Session >>> >>> We are developing a high load application. One of our requirements is >>> to have no server side sessions. >>> >>> As the documentation says, Tapestry tries it's best to not start a >>> HttpSession until it has to. But I need a tighter guarantee, that it >>> does not start a HttpSession ever. For example I would prefer Tapestry >>> to throw an error if any components declare a property persistent, or >>> ever tries to create a session, so that we can replace that component. >>> >>> >>> Any ideas on how I can accomplish this? >>> >>> Does there happen to be a service whose job is to create sessions, that >>> I could replace with HiveMind? >>> >>> >>> >>> I just figured out one way; as I was writing this. >>> >>> Use a Webapp Filter to replace the HttpServletRequest object with one >>> that reimplements the getSession methods to throw an exception. >>> >>> >>> This will force the guarantee of no serverside sessions. But the >>> question still remains, how will Tapestry react. Could Tapestry work >>> under such a strict environment, etc. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
