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.
> 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.
>
> 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?
> * * *
>
> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
