portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Golden <ggol...@umich.edu>
Subject How a Profile is associated with a request
Date Fri, 10 May 2002 17:07:10 GMT
DefaultJetspeedRunData's getProfile() setProfile() store the Profile in the

Does anybody know why we choose to store the profile in the session rather
than the run data?

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.

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?

* * *

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
Glenn R. Golden, Systems Research Programmer
University of Michigan School of Information
ggolden@umich.edu               734-615-1419

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

View raw message