> -----Original Message----- > From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 19, 2003 3:58 PM > To: [EMAIL PROTECTED] > Subject: Re: Any reason to keep an instance of HttpSession in RunData? > > > "Quinton McCombs" <[EMAIL PROTECTED]> writes: > > >Why are we keeping a reference to the session in > DefaultTurbineRunData? > >Turbine is passed the HttpRequest and HttpResponse objects. The > >HttpResponse contains the HttpSession. Anything wrong with making > >DefaultTurbineRunData return request.getSession()? > > Hm, > > as this is set in the TurbineRunDataService by calling > > data.setSession(data.getRequest().getSession(true)) > > I see no real problem replacing getSession() with returning > req.getSession() (which is equivalent with req.getSession(true)). > > We must deprecate and remove setSession from RunData, because > after doing so it is a noop. > > Only problem that might crop up is, that with the current > model, we have a definite session start (first creation of a > rundata object ensures that at least getSession(true) is > called once so a session is set up. > When we return req.getSession() from rundata and the user > never calls data.getSession(), we might not get a session for > a long time. Could this be a problem for us? > > Regards > Henning
We could change data.setSession(...) to data.getSession(). It would have the same effect for us. Even without doing this, the session validator will handle it for us when it tries to see if the is a User object in the session. I am not sure that we want to depend on this though... I think just calling data.getSession during the creation of the RunData is a cleaner approach to ensure that we always have a session. > > > > >-------------------------------------------- > >Quinton McCombs > >NequalsOne - HealthCare marketing tools > mailto:[EMAIL PROTECTED] > >http://www.NequalsOne.com > > >> -----Original Message----- > >> From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, March 19, 2003 3:38 PM > >> To: [EMAIL PROTECTED] > >> Subject: Re: Unexpected problem with changes to Turbine.loginAction > >> > >> > >> "Quinton McCombs" <[EMAIL PROTECTED]> writes: > >> > >> >I just got the following error during login. I suppose this > >> is why the > >> >code originally get an array and steped through it that > way. I just > >> >wonder why. I would have thought that the session would only be > >> >modified in the current thread... > >> > >> Hm, > >> > >> that one is cute. I will give it a look tomorrow. > >> > >> Regards > >> Henning > >> > >> -- > >> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen > INTERMETA GmbH > >> [EMAIL PROTECTED] +49 9131 50 654 0 > http://www.intermeta.de/ > >> > >> Java, perl, Solaris, Linux, > xSP Consulting, Web Services > >> freelance consultant -- Jakarta Turbine Development -- > hero for hire > >> > >> > --------------------------------------------------------------------- > >> 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] > > > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH > [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ > > Java, perl, Solaris, Linux, xSP Consulting, Web Services > freelance consultant -- Jakarta Turbine Development -- hero for hire > > --------------------------------------------------------------------- > 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]
