Bug 534606 - (RHQ-1387) fix user preferences persistence
fix user preferences persistence
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: Joseph Marques
: Task
Depends On:
  Show dependency treegraph
Reported: 2009-01-22 07:16 EST by Joseph Marques
Modified: 2009-02-11 09:24 EST (History)
0 users

See Also:
Fixed In Version: 1.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joseph Marques 2009-01-22 07:16:00 EST
user preferences is stored in session, but this creates odd caching semantics if not accessed properly.  if you want to update some preference, this will work:

WebUser user = EnterpriseFacesContextUtility.getWebUser();

but this won't:

Subject subject = WebUtility.getSubject(FacesContextUtility.getRequest());
new XXXPreferences(subject);

this deals with the fact that the preferences are actually stored as a Configuration object hanging off of the subject object.  so, i'm accessing that linked structure in the first example, whereas i'm ignoring the existence of it in the second form and creating a new preferences object in the second scenario.  so, the first form will set AND get the preferences correct, but the second form will ONLY set the preferences correctly.  if you try to get the preferences by any method after executing the 2nd form, it will hit the object facade stored in the session, which doesn't know about the update.  this should be fixed so that the consistency between the in-memory and persistence preferences are transparent to the user of either API.
Comment 1 Joseph Marques 2009-02-05 19:41:56 EST
rev2937 - start to lock-down access to objects at the web layer, as a precursor to unifying access to user preferences; 
rev2939 - further restrict access to the web user preferences; 
Comment 2 Joseph Marques 2009-02-10 08:54:21 EST
rev2992 - finish locking down access to the WebUser object, it is now set/unset/retrieved singularly from SessionUtils; 
also, upon getting WebUser, it's corresponding preferences are reloaded (now it doesn't matter if prefs were changed directly vis SQL or through an instance of SubjectBasePreferences that did not go through the WebUser in session); 
Comment 3 Red Hat Bugzilla 2009-11-10 15:31:50 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1387

Note You need to log in before you can comment on or make changes to this bug.