We have in one MWS CAF portlet application on the inbox results page a extended portlet url of type action with 4 url parameters, one action parameter and 3 render parameters. When the url is clicked the value “true” is passed for the portlet preference “isResultsViewDisabled” from the inbox results portlet. In the inbox results portlet based on the value of this portlet preference the search is executed or not.
The extended portlet url is located inside a portlet simple link.
Similar we have on the task details page an extended portlet url (of type render) inside a portlet simple link, this time with two parameters, one of which sets the value of the above mentioned portlet preference to false.
The problem we had in our production environment was that the value of the portlet preference got stuck to “true”. The value did not change even if the user logged out of the application and logged back in. We tried to redeploy the CAF portlet application but the value was still “true”. After removing completely the CAF portlet application and a new deployment the value of the portlet preference got back to normal and was set each time one of the “extended portlet url” was clicked. The problem reproduced on all 4 MWS nodes from the cluster and for each user.
Does anybody encounter the same behaviour when a portlet preference value got “stuck” ? Is there a possibility to clear somehow the values of one or all portlet preferences of one task application via the admin or sysadmin user at runtime? Shouldn’t a CAF portlet application deployment reset the values of all portlet preferences?
Regarding the two suggestions :
Check if the parameter value contains the expected value before open the link. → normally yes. On the day we had the production issue : no! The value got stuck to “true” and did not change even if the application was redeployed.
Debug the target portlet. See what happen with the preference when the portlet initializes or any event before this phase. → Unfortunately I am not able to reproduce this behavior anymore so the only data I have now are logs.
I was wandering if somebody did encounter something similar and would have a hint on what we could analyze now from the logs we have from when the error occurred.
I would also like to know what happens at deployment time with the values of the portlet preferences. Aren’t the old values overwritten at deployment time?
the problem occurred only once and can not be reproduced in any other environment. However I would like to find out what might have cause a portlet preference which should be stored per portlet instance not to be refreshed with an new portlet instance.
Deployment of the portlet application shouldn’t discard the old portlet instance and create a new one?
The portlet.xml/wm-portlet.xml is simply providing the default value for the specific preference when the a portlet instance does not already have a value stored in its property bag. So re-deploying the CAF app does not, and should not, replace the values stored in the property bag of already existing portlet instances as that could lead to loss of important data.
If there are specific portlet instances that you can enumerate and want to update during deployment, then you can use an xmlImport file to change the property value on those specific instances.
When you select the specific portlet instance in the “MWS Admin” view in Designer, the “Properties” view of Designer will show you a unified view of the properties that are stored for that thing.
As for where they are stored, the persisted portlet preferences are stored somewhere in the MWS database. The actual storage location for each preference is an internal implementation detail and depends on the “scope” defined for the preference in the wm-portlet.xml file.
For example, of the preference “scope” is:
config - this value is stored in the database in a location that is shared by all instances of that portlet type
content - this value is stored in the database record of each portlet instance and shared by all users
user - this value is stored in the database of each portlet instance, but each user has their own value
session - this value is never stored in the database, it is a transient value that is stored in memory until the user logs out.