Bug 534606 (RHQ-1387)

Summary: fix user preferences persistence
Product: [Other] RHQ Project Reporter: Joseph Marques <jmarques>
Component: Core UIAssignee: Joseph Marques <jmarques>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 1.2Keywords: Task
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-1387
Whiteboard:
Fixed In Version: 1.2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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();
user.getXXXPreference...

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