Would registering a javax.servlet.http.HttpSessionListener and throwing an exception in sessionCreated(..) not be the best way of tracking sessions being created?
On 7/20/05, Norbert Sándor <[EMAIL PROTECTED]> wrote: > Have you tried some tomcat user list? > Maybe they can help you more because this seems to be a lower level, servlet > (or container?) specific question. > > Br, > Norbi > > ----- Original Message ----- > From: "Fernando Padilla" <[EMAIL PROTECTED]> > To: "Tapestry users" <[email protected]> > Sent: Wednesday, July 20, 2005 8:23 PM > Subject: Re: forcing No Server Session > > > > 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] > > > > > > > > > > > > --------------------------------------------------------------------- > 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]
