Glenn Golden wrote:
>
>>-----Original Message-----
>>From: Paul Spencer [mailto:[EMAIL PROTECTED]]
>>Sent: Friday, May 10, 2002 2:06 PM
>>To: Jetspeed Developers List
>>Subject: Re: How a Profile is associated with a request
>>
>>
>>
>>
>>Glenn Golden wrote:
>>
>> > DefaultJetspeedRunData's getProfile() setProfile() store
>>the Profile > in the getUser().getTemp("profile").
>>
>> >
>> > Does anybody know why we choose to store the profile in
>>the session > rather than the run data? >
>>
>>Rundata is recreated every request, getUser().getTemp() stays
>>around to
>>for the entire session.
>>
>
>
> Right - but we re-create the Profile for each request, so why store it long
> term like that?
>
Should like we should compare the "path". If they are different then
get the profile, other use the one in getTemp()
>
<snip>>
>>They should be 2 different sessions. I suspect two browses
>>running on
>>the same PC will share the same cookies, this the same
>>session. Browser
>>on different machines will have different sessions.
>>
>
>
> What I's saying is that two different browser windows on the same machine
> will be in the same HTTP session, and we have to allow this to happen, and
> different portal pages to be in each browser without conflict. Better yet,
> we have to allow the *same* portal page in both browsers without conflict.
>
Session management is a function of Tomcat, not jetspeed. If the user
desire 2 session on the same machine, then the user has to disable
cookies or make sure their browser do not share cookies. I do not
believe this is a Jetspeed problem.
>
> Storing Page session state information in the HTTP session introduces
> conflict between different pages in different windows.
>
> Storing the profile in the HTTP session introduces conflict of the same
> sort.
>
> And as far as I can tell, we are doing it for no benefit.
>
Tomcat is managing the session from the browser, not Jetspeed.
>
<snip>
>
>
> Each request computes the profile from the URL in JetspeedAccessController.
>
> Even if it didn't, if I request a user/group/role page, and then my next
> request is for just /portal/, the second request is for my default page, not
> the one I got the first time. This is why the $jslink is so important to
> encode all the profile page stuff so that links back will identify the
> proper page.
>
I stand corrected.
>
>>
>>Paul Spencer
>>
>>
Paul Spencer
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
