Bug 534606 (RHQ-1387)

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.