Existing Portlet Data Not Displaying after changing to Instanceable

[Sneha J, modificado hace 6 años.]

On Liferay 6.1.2. Community Edition with Glassfish3, initially a plugin portlet was deployed as non-instanceable and was functioning successfully with data stored in portlet preferences. Later the same portlet was updated to be instanceable and deployed. Strangely after deploying the updated portlet, the already existing portlet disappeared from the page while data of the portlet existed in the portlet preferences.

To get the portlet working we had to add a new portlet on the page and manually copy data of the old portlet from portlet preference to the new portlet preference. This was tedious as it had to be done for more than 50 instances of the portlet which existed on different sites and on different pages.

Ideally the old/existing portlets should been updated with latest changes and remained as is on the pages with data. (That is what happens in a general deployment). Why did the portlet disappear from the page while data existed in the portlet preferences ?
How do we avoid such scenarios further for future deployments; it is risky to copy data manually for each new deployment as portlet instance are more than 50 ?

Thanks In Advance.

[David H Nebinger, modificado hace 6 años.]

Sneha J:

Ideally the old/existing portlets should been updated with latest changes and remained as is on the pages with data. (That is what happens in a general deployment). Why did the portlet disappear from the page while data existed in the portlet preferences ?
How do we avoid such scenarios further for future deployments; it is risky to copy data manually for each new deployment as portlet instance are more than 50 ?

Portlet preferences are tied to portlet instance id.

When you put a non-instanceable portlet on a page, let's call it Foo, your portlet instance id will end up being something like just Foo. Portlet prefs, stored in the DB, will be for the portlet instance id Foo. If you could (but you can't) drop multiple copies of the portlet on the page, they would all share the same portlet prefs because each one would still be portlet id Foo.

Now if you change it to be instanceable and deploy it, replacing the original, everything changes.

For instanceable portlets, the portlet instance id changes so each individual instance has a unique id. You'll get things like Foo_02fea8c9b, Foo_48aae492, etc. These are not exact as there is an algorithm for determining the actual portlet id, but I think you get the picture.

For each portlet instance, it has a unique id and, of course, those ids are not going to match the id Foo in the database where the old prefs are stored.

How do you prevent this from happening? You don't do it. It is not a valid "development pattern" to create all portlets as non-instanceable during development, testing, and deployment and finally, when approved, switch it to instanceable.

Instanceable vs non-instanceable should be known before development starts. You'll know if you are going to have only one per page or will allow for more than one on a page. This is a design-time aspect that should be reflected in your portlet before development starts. Set it up correctly from the beginning, then it will not have to worry about some future portlet id change.

Before you say, "Liferay should change the portlet id and prefs for me from Foo to Foo_02fea8c9b", I would have to respond with "Why?" I mean, a deployment overwrites the last portlet, there is no logic that runs during undeployment (to purge records previously tied to portlet id Foo), there is no reliable way at start to know that Foo_02fea8c9b is the right replacement of Foo (and not Foo_48aae492), so there is no real way to programmatically derive a way forward and consistently test the outcomes to ensure it was working. Given all of that, it is clear that Liferay can not and should not be trying to do this kind of thing for you.