RedirectException is an elegant way of cut your logic whereever you are. I'm not against it. It's really usefull (although it looks like old goto sentence). Ok, it's not really an exception. Let's say you are throwing a thing to get cought by someone that know s what to do with that throwable. You get nervous when people use exceptions like that, and i get nervous when people start discussing only on how to name something. It's really the best approach you can have. You do that, or you start returning 0s and 1s like your functions in Ansi C.
On 7/20/05, Danie Honig <[EMAIL PROTECTED]> wrote: > > I believe you can detect session created without using an exception as > the signal. I think there is an event you can trap, > but I'm talking blindly on this from memory, which may or may not be > correct. I get nervous when people use exceptions > for things that are expected and therefore not "Exceptional". I like > to let my exceptions be exceptional. For example, > the PageRedirectException gets under my skin for the same reason. > > john mcteague wrote: > > >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] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
