portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luta, Raphael (VUN)" <Raphael.L...@groupvu.Com>
Subject RE: Bug in JetspeedAccessController re: Profile
Date Tue, 24 Sep 2002 13:09:01 GMT
De : Glenn Golden [mailto:ggolden@umich.edu]
> An update, after dancing with the code last evening...
> The customizers break if I change the place the profile is stored,
> it from the user.temp into the rundata.  I think the customizers expect
> profile to have a scope wider than each individual request; a scope as
> as the many requests of the customization session.  This scope is fine for
> the customizers, but is wrong for the "user", as they may be doing other
> things.  I'm spending today fixing the customizers, if I can figure them
> ;).

It should be pretty easy, you will just need to update the controller
In the buildCustomizedContent() you'll probably find getProfile() calls but
saveProfile() since there's an implicit assumption of session persistence.

> The Profile does hold the PSMLDocument, so it's not just a light weight
> thing, but the actual document as well.  This is redundant with the
> which is in the PSML managers.

Agreed. Profile holds a PSMLDocument reference simply to be able to do:


I think this is necessary if we ever want to have a "profile customization"
and let the user himself create new profiles.
I'm not sure this is currently useful however.

> The db psml manager has aggressive caching, even caching misses.  This is
> good as it reduces the backend database access.  There's a refresher
> running to make sure things in the cache are current (well, as current as
> the refresher which runs by default every 8 hours).  
> Otherwise, the pages just fill up the cache, and memory.
> We could add some cache pruning based on LRU to the refresher 
> thread, as Raphael suggests.

I'm pretty sure the Turbine GlobalCache service is implementing such a LRU
scheme so instead of using an hashtable in the PSML Managers implementation
we would just need to use the GlobalCache service and have a common 
caching implementation across PSML managers

> I would like to see the Castor PSML manager fixed up for caching to have
> same sort of thing as the db one, but I don't really use it much and not
> all in production.

I can probably fix the Castor PSML manager quite easily if you want me to do

> Back to the customizers.  I believe that they are doing things to the PSML
> document that is attached to the profile, and if we don't have this live
> past requests they don't work.  First, I think this is bad, as they are
> messing with the "live" (and possibly cached) psml document - anyone else
> visiting the page will see changes in progress, I think, and there's no
> chance to "cancel" the edit.  Also, if the user comes in with another
> window's request to another profile, it should mess up the customization
> process.  And if another user starts customizing the same profile, this
> also mess things up.


> What I want to do is let the customizers have a copy of the profile / psml
> document to work on.  This copy would be associated with the request
> - i.e. the edit copy of the page would be stored in the state manager
> by the page's profile and user session.  This means that one user could
> any number of pages at a time from different windows, as each
> state would be stored separately. It also means that any other users
> in would not see the changes until committed, and if the customizing user
> has another profile open in another window and requests come in from that,
> nothing is messed up.
> When they press the final "Apply" or "Save" or whatever, the copy would be
> put back into the PSML service, storing it on file / db and in the cache,
> and the edit copy and other state would be cleared.
> I'll look at what that might look like today.
> Comments?

+1^1024 :)

Raphaƫl Luta - raphael@apache.org
Jakarta Jetspeed - Enterprise Portal in Java

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