Bug 111730 - Portal#addPortlet doesn't reliably set the sortKey attribute.
Portal#addPortlet doesn't reliably set the sortKey attribute.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity high
: ---
: ---
Assigned To: Richard Li
Jon Orris
:
Depends On: 112905
Blocks: 106481
  Show dependency treegraph
 
Reported: 2003-12-09 09:06 EST by Daniel Berrange
Modified: 2007-04-18 13:00 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-09 10:38:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to fix bugs 1 & 3 (1.80 KB, patch)
2003-12-09 09:07 EST, Daniel Berrange
no flags Details | Diff

  None (edit)
Description Daniel Berrange 2003-12-09 09:06:41 EST
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.
Comment 1 Daniel Berrange 2003-12-09 09:07:18 EST
Created attachment 96419 [details]
Patch to fix bugs 1 & 3
Comment 2 Richard Li 2003-12-09 09:23:46 EST
btw, bug and bugs with a number after it get aliased to other bugzilla
numbers...hence the silly hyperlinks above.
Comment 3 Richard Li 2004-01-05 12:48:08 EST
"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?
Comment 4 Richard Li 2004-01-05 12:50:16 EST
first and third issues addressed @39102
Comment 5 Daniel Berrange 2004-01-05 12:53:55 EST
Yes, sort_key should be 1..1 since the domain layer is treating it as
a required attribute, by virtue of the 'Assert' calls.
Comment 6 Richard Li 2004-01-05 13:04:26 EST
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.
Comment 7 Daniel Berrange 2004-01-05 13:14:19 EST
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.
Comment 8 Richard Li 2004-01-05 14:22:16 EST
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).

Note You need to log in before you can comment on or make changes to this bug.