[ http://issues.apache.org/jira/browse/PLUTO-122?page=comments#action_12451798 ] Craig Doremus commented on PLUTO-122: -------------------------------------
I just realized that you need to have a portlet id in the preferences table to make sure that preferences do not get mixed up between portlets. In the Pluto driver container, you could use the portlet-name element in portlet.xml as a unique portlet id. This will not work in other containers that allow the dynamic cloning of portlet instances. Does anyone else have another idea for a unique portlet key that will work with dynamic portlet instances and also be able to be reassociated with a portlet instance between server restarts? > Portlet Preferences need to be user specific > -------------------------------------------- > > Key: PLUTO-122 > URL: http://issues.apache.org/jira/browse/PLUTO-122 > Project: Pluto > Issue Type: Bug > Components: portal driver > Affects Versions: 1.0.1-rc1, 1.0.1-rc2, 1.0.1-rc3, 1.1.0-alpha1 > Environment: All operating systems and hardware > Reporter: Craig Doremus > Fix For: 1.1.0 > > > According to the JSR-168 specification PLT.14.2: > "Portlet Specification assumes preference attributes are user specific, it > does not make any provision at API level or at semantic level for sharing > preference attributes among users." > Right now the PortletPreferences attributes are shared by all users and > stored within the portletentityregistry.xml file. I'm not sure if there will > be enough time to fix this for the final Pluto-1.0.1 release, but there > should be documentation concerning our implementation of Portlet Preferences. > As the spec says, "If a portal/portlet-container implementation provides an > extension mechanism for sharing preference attributes, it should be well > documented how the sharing of preference attributes works." > Maybe we should implement this in Pluto 1.1 in conjuction with a User > Information (PLT.17) implementation (Jira issue PLUTO-38), since both are > keyed on a specific user. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
