portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Golden <ggol...@umich.edu>
Subject RE: How a Profile is associated with a request
Date Fri, 10 May 2002 18:11:20 GMT


> -----Original Message-----
> From: Paul Spencer [mailto:paulsp@apache.org] 
> 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?


> 
>  > It looks like this profile is re-set for each request by the 
> JetspeedAccessController
>  >  - if the profile for the current request is different 
> from the one  >  stored.  >  > The JetspeedAccessController 
> does a Profile.getProfile(jdata) for  > each request, 
> updating the session stored profile if different.  >  > Then 
> JetspeedTool will use that stored profile, unless it's 
> missing,  >  then it will Profiler.getProfile() and store it 
> in the session.  >  > First, I suspect that this means that 
> one user with two browser  > windows cannot be viewing two 
> different Jetspeed pages, as requests  >  from both would 
> compete for that one session stored profile slot.
> 
> 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.

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.


> 
> 
>  >
>  > Second, perhaps there's redundancy between the
>  > JetspeedAccessController setting the profile and the 
> JetspeedTool  > setting the profile.  >  > Finally, what do 
> we gain by storing the profile in the session, when  >  for 
> each request we go and compute it again anyway?  >
> 
> If the next request does not contain the psml info, i.e. 
> user/group/role 
> and page, then do we not get that profile stored the session?


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.


> 
>  > * * *
>  >
>  > Unless new data arives, I propose we move the storage of 
> the profile  >  back into the rundata proper, let the  
> JetspeedAccessController  > find it and set it in there, and 
> let the JetspeedTool find it in  > the rundata and have an 
> error condition if it is not there.  >  > - Glenn  >
> 
> 
> Paul Spencer
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> 

--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message