portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glenn R. Golden" <ggol...@umich.edu>
Subject Re: Bug in JetspeedAccessController re: Profile
Date Mon, 23 Sep 2002 19:41:41 GMT
David (et. al.) -

If we want everything in the session to be serializable, then we need to 
pay close attention to the http version of the state manager service, 

This stores objects in the session, StateEntry (defined within and 
private to that file), which holds a map of the objects that the users 
of this service have placed into state.

I think that StateEntrys must be serializable, which I think we can 
achieve... but won't all the objects that any user of the state manager 
service need also to be serializable?  This is a larger issue and places 
additional demands on the Jetspeed developer.  Not unreasonable ones, 
but we should make our case as to why this is necessary.

- Glenn

On Monday, September 23, 2002, at 01:04  PM, David Sean Taylor wrote:

> You will get a big +1 from me, that is as long as you don't break 
> anything
> ;)
> We are just looking into making all objects serializable that are put 
> in the
> session.
> And I was just hoping we could remove the profile object, since its 
> nested
> with other objects.
> Why not simply use the DefaultJetspeedRunData's profile in the get and 
> set
> methods
>     private Profile profile = null;
> A profile is only good per request, I agree the current code is wrong 
> and
> should be changed to use the data member and not get/setTemp
>> -----Original Message-----
>> From: Glenn Golden [mailto:ggolden@umich.edu]
>> Sent: 23 September 2002 18:04
>> To: 'Jetspeed-Dev (jetspeed-dev@jakarta.apache.org)'
>> Subject: Bug in JetspeedAccessController re: Profile
>> The JetspeedAccessController sets the profile based on the
>> current request into the data's user's setProfile() (which is
>> stored in the user's temp area).
>> This is wrong.  The scope in which the data is stored
>> (session - user) is way to broad for the scope in which the
>> data is valid (session - user - request).
>> If two requests come in from the same user, and are worked on
>> overlapped, and are from two different profiles, the second
>> to start will re-set the profile that the first set, and they
>> will both get the second's profile if either call the data's
>> getProfile().
>> My Jetspeed app. is actually running into this occasionally!
>> I will fix this.  Either by putting in this:
>> Profile.getProfile(this)
>> In DefaultJetspeedRunData's getProfile() and nothing in the
>> setProfile(), effectively not caching the profile,
>> or cache the profile for the current thread using a hashtable
>> based on thread somewhere where the rundata can find it for set/get.
>> Any other ideas?
>> Comments?  Thanks!
>> - 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>
> BBCi at http://www.bbc.co.uk/
> This e-mail (and any attachments) is confidential and may contain
> personal views which are not the views of the BBC unless specifically
> stated.
> If you have received it in error, please delete it from your system, do
> not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately. Please note that the
> BBC monitors e-mails sent or received. Further communication will
> signify your consent to this.
> --
> To unsubscribe, e-mail:   <mailto:jetspeed-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:jetspeed-dev-
> help@jakarta.apache.org>

- Glenn

Glenn R. Golden    Systems Research Programmer
School of Information             University of Michigan
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