Each Portlet instance will call CPortletAdapter.initPortletWindow(), which in turn will get the PortletDefinitionImpl for a given portletDefinitionId. Since the two portlets have the same portletDefinitionId (say "foo.Bar"), they get the same object returned and proceed to call the PortletDefinitionImpl.setChannelDefinition() method, associating the single Portlet object with the channel instance data.

Each time that a Portlet instance does this, it then calls PortletDefinitionImpl.loadPreferences(), which appends to or overwrites a previous portlet's definition preferences.

There are a number of additional problems with this, causing it to be difficult to fix. It appears each Portlet - not each Portlet instance - has its own CPortletAdapter instance, so when the portal calls CPortletAdapter.isCacheValid(), it is also shared among each Portlet. Also, the synchronization should have some work done.

The "fix" I tested disables caching, as it appears this would be a significant amount of work to fix. The workaround that I found is as follows:

in PortletDefinitionImpl.java, on line 215 (in loadPreferences()) add:
preferences = new PreferenceSetImpl();

in CPortletAdapter.java, line 532 (after try { in getMarkup()) add:

PortletWindowImpl wnd = (PortletWindowImpl)cd.getPortletWindow();
PortletEntityImpl ent = (PortletEntityImpl)wnd.getPortletEntity();
PortletDefinitionImpl def = (PortletDefinitionImpl)ent.getPortletDefinition();
ChannelDefinition channelDefinition = ChannelRegistryStoreFactory.getChannelRegistryStoreImpl().getChannelDefinition(Integer.parseInt(sd.getChannelPublishId()));
def.setChannelDefinition(channelDefinition);
def.loadPreferences();

That will load the preferences each time a channel is rendered.

Also, disable caching in CPortletAdapter.java, line 638 (in isCacheValid()), make it return true;

I also synchronized both methods getMarkup() and initPortletWindow() with an inner synchronized(this){} block instead of function-level synchronization... I had to remove some inner synchronized() blocks to avoid deadlock. I'm not sure how the function calls are ordered, but that could pose a problem. It seems to work fine for me, however.

To disable caching, in CPortletAdapter.java, line 638 (in isCacheValid()), make it return false;

FALSE, not true...

Keith described the problem well, I'm going to see if I can add a bit more detail to the problem and describe what would need to be done to fix it.

The source of the problem is the portlet domain object architecture of uPortal 2. To start the JSR-168 portlet specification & Pluto, the reference JSR-168 container, define the following domain object levels for portlets

PortletDeployment
-Generally this equates to each <portlet> tag in the portlet.xml.
-uPortal 2 does not have a PortletDeployment object.

PortletDefinition
-Generally this equates to publishing a PortletDeployment in the portal.
-uPortal 2 groups this both the deployment information and the publishing information into this object.

PortletEntity
-Generally this equates to a user subscribing to a PortletDefinition.
-uPortal 2 follows the general practice.

PortletWindow
-Generally this equates to a user placing a PortletEntity on their layout.
-uPortal 2 follows the general practice.

From those descriptions we can base the problem description. The way preferences are advertised to work in uPortal 2 has three layers. The base layer is defined in the portlet.xml, the next layer is defined during publishing in ChannelManager, the final layer is defined by the portlet code while the user is interacting with it.

This layering is supposed to allow increasing levels of customization for a portlet. Example: A weather portlet could have a default location ZIP code in the portlet.xml. The administrator then publishes the portlet multiple times specifying different ZIP codes for each published portlet. The end user can override the published ZIP code to get weather they are interested in. None of these saved ZIP codes should interfere.

With the current uPortal 2 codebase there is only one PortletDefinition per PortletDeployment instead of one PortletDefinition per published instance of the PortletDeployment. This one PortletDefinition object is where the one definition level portlet preferences object is stored.

At the beginning of rendering each portlet loads its definition and entity preferences from the backing store. If there are multiple portlets based on the same deployment on a single tab they are all using the same PortletDefinition object. Each rendering portlet would load the definition preferences associated with its channel ID into the one PortletDefinition object. Now there is one portlet preferences object which contains some non-deterministic layering of preferences from all of the portlets based on that portlet deployment on that tab.

Now that the shared PortletDefinition has been identified as the problem a fix needs to be determined.

The correct approach to resolving this issue would be to rename the uPortal 2 PortletDefinition object to PortletDeployment. The majority of the information it provides is actually from the portlet.xml. A new PortletDefinition should be created and keyed on the channel definition ID. This object would provide the preferences for the definition level.

A quick work-around that does not involve modifying uPortal code is to create a portlet deployment entry for each portlet you would like to publish. Instead of publishing 'WeatherPortletApp.3DayForcastPortlet' multiple times the portlet XML would define multiple, uniquely named portlets '3DayForcastPortlet1', '3DayForcastPortlet2', ... and each would be published just once.

i thought this could be fixed by making renderCharacters a synchronized method; however, initPortletWindow() is also called from getRuntimeData(), and this seems to be the method that always makes the call.

the temp fix i used, is to synchronize the renderCharacters method and force initPortletWindow to be called everytime from within renderCharacters. in other words, i added the "synchronized" keyword to the renderCharacters method and commented the "if" logic that surrounds the initPortletWindow call.

can anyone comment on the overall impact of this as a temp solution? could this cause serious performance problems, or have any other adverse affects?

note: there may be an additional need to force initPortletWindow to be called everytime there is a multi-published portlet on the user's layout? further testing should be done to determine this.

The current architecture and database structure can adequately support the separation of portlet definition, publication, and subscription level preferences; however, the current code does not adequately manage the loading of preferences to allow preservation of this separation during the users session.

Today, preferences are loaded in the following three phases:
1. The PortletDefinition object is loaded with preference values that were specified in the portlet.xml file at deploy time.
2. The PortletDefinition object is then loaded with preference values that were specified in the chanpub.xml file at publish time. These preference relationships are stored in the PORTLET_DEFINITION_PREFS and PORTLET_PREF_VALUES tables in the database. At runtime, they override any preferences of the same name that were previously loaded from the portlet.xml file.
3. The PortletEntity object is loaded with preference values that were specified by the user during or after subscription time. These preference relationships are stored in the PORLET_ENTITY_PREFS and PORTLET_PREF_VALUES tables in the database.

The PortletDefinition object is keyed on portletDefinitionId, which is unique to a portlet deployment descriptor specified in the portlet.xml. However, the portlet publication is keyed on chan_id, which is unique to a portlet publication descriptor specified in the chanpub.xml. There is a one (portletDefinitionId) to many (chan_id) relationship between these two keys. Therefore, in phase two of the preferences load, the publication preferences for a given chan_id are overwriting any previous publication preferences sharing that specific portletDefinitionId.

At render time, PortletEntity preferences override any preferences of the same name that were previously loaded from the PortletDefinition object. Because these are stored in two separate objects at runtime, no overwrites occur. This explains why user subscription preferences have never been an issue, while publication preferences have been a problem.

To correct this, we can treat the publication preferences (stored in PORTLET_DEFINITION_PREFS) as default values in the PortletEntity preferences (stored in PORTLET_ENTITY_PREFS), rather than overrides to the values in PortletDefinition preferences.

In the future, preferences would be loaded in the following three phases:
1. As before, the PortletDefinition object is loaded with preference values that were specified in the portlet.xml file at deploy time.
2. The PortletEntity object is loaded with preference values that were specified in the chanpub.xml file at publish time. These preference relationships would still be stored in the PORTLET_DEFINITION_PREFS and PORTLET_PREF_VALUES tables in the database.
3. The PortletEntity object is loaded with preference values that were specified by the user during or after subscription time. These preference relationships are stored in the PORLET_ENTITY_PREFS and PORTLET_PREF_VALUES tables in the database. At runtime, they override any preferences of the same name that were previously loaded from the PORTLET_DEFINITION_PREFS database table.

At render time, PortletEntity preferences would still override any preferences of the same name that were previously loaded from the PortletDefinition preferences. However, now the publication preferences would be applied to the unique instance of the subscription rather than the shared instance of the definition.

The only foreseeable drawback to this solution highlights the key difference between this solution and Eric's analysis:

The publication preferences would be loaded for each subscription of the portlet prior to applying user subscription preferences. This would not cause performance degradation from today's baseline, because the same preference loads occur currently (the preferences are just being loaded into different objects than before, to allow more predictable results). However, Eric's recommended solution would create an object that allowed the true separation of publication from subscription, and this may provide a slight performance enhancement over either method described herein.

However, the benefit is an easily implemented fix to the bug with no anticipated impact to function or performance. A coded solution is attached as ModifiedSource.zip

I'm at the JA-SIG conference right now, but will try to take a closer look at your patch when I get back.

The entity level preferences will need to be physically layered instead of just loading the publish preferences and then the entity preferences into the same object. The persistence layer may also need to be updated to deal with this layered preferences system.

Also a quick guide for submitting patches is available: http://www.ja-sig.org/wiki/display/UPC/Contributing+Patches

My thought being – if a user CAN change a preference, once they've been to the preferences screen I don't want to change the values without them initiating some action, seems that it breaks user expectations. And most instances where an admin wants to update preferences are preferences that I don't want the user to change, or am just providing a suggested default in which case picking up updates is perhaps not so important.

The real solution, which should be possible with some work, is to re-work the entity model to store the preferences in a layered manner in memory. The definition preferences would get loaded into the base layer of the entity and then entity preferences would get loaded into the layer on top of that. Changes to preferences made by the portlet would only affect the top layer of preferences which would be persisted on a .store() call as the entity preferences.

this could use a second or third set of eyes and some additional testing.

i have another recommendation in the works... i will post it for review after a little more testing...

please test and provide feedback or recommended improvements.

i can't quite get used to this bug tracking tool. i don't understand why a comment made when saving an attachment, shows no association to the attachment.

Sweet!

Jason

–

Jason Shao
Application Developer
Office of Instructional & Research Technology
Rutgers University
v. 732-445-8726 | f. 732-445-5539 | jayshao@rutgers.edu