Description of problem: The c.a.portal.Portal#addPortal method doesn't immediately set the sortKey when adding a portlet. Instead it adds the portlet to a LinkedList and processes this list, reassigning sortKeys in an afterSave() event. Unfortuntely before it adds the portlet to the list it calls 'Porlet#setPortal' which in turns sets a permission context & in turns triggers a persistence flush. This triggers the saving of both the portal & the portlet, but the portlet hasn't yet been added to the linked list so its sortKey is never set. This is problem #1 This bug only shows up when you subsequently try to view a portal page where the Portlet#getSortKey method asserts that the sort key is not null. The presence of a null sortKey would have been caught at save time if the PDL for Portlet had the cardinality set. This is bug #2. Finally, all access to the LinkedList returned by Portal#getPortletListForCell is wrapped in synchronized{} blocks, except for the addPortal method. So there is a race condition present. THis is bug #3. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Persistence enforces that sortKey is not null at save time. Additional info: The attached patch fixes bugs 1 & 3. Bug 2 needs a further small change to the PDL. It is unclear what change caused this bug to appear between Nov 15 & Dec 5 releases. Nothing has changed in the c.a.portal package, nor in the APLAWS portal application. So I assume there must have been some change in persistence / permissions. APLAWS portals in the release we just made is completely broken, so this is an urgent fix.
Created attachment 96419 [details] Patch to fix bugs 1 & 3
btw, bug and bugs with a number after it get aliased to other bugzilla numbers...hence the silly hyperlinks above.
"This bug only shows up when you subsequently try to view a portal page where the Portlet#getSortKey method asserts that the sort key is not null. The presence of a null sortKey would have been caught at save time if the PDL for Portlet had the cardinality set. This is bug #2." By the above, do you mean that you think the multiplicity for Portlet sort_key should be 1..1 instead of 0..1?
first and third issues addressed @39102
Yes, sort_key should be 1..1 since the domain layer is treating it as a required attribute, by virtue of the 'Assert' calls.
isn't that true for just portlet sort_key? it actually references application sort_key, and afaict the app domain layer does not treat sort_key as required. if you set sort_key to be 1..1 cms does not load due to the not null constraint being violated on application.
Yes that is a problem with 3 different object types sharing a single table. The DDL generator will put a NOT NULL constraint on applications, even though only the 'Portlet' subtype of 'Resource' wants it. There are two solutions I see: a) Make each object type have its own DB table b) Provide a manual 'table-applications.sql' containing the CREATE TABLE statement to disable the DDL generator for this table. Option b) is probably simplest to do.
Unless there are strenuous objections, I am going to punt on #2 until bug 112905 is addressed (not for current release). As previously noted, the constraint is already enforced by the domain layer (not ideal, but works).