Red Hat Bugzilla – Bug 495506
package details, not showing Change log and File List
Last modified: 2009-09-10 16:35:31 EDT
Description of problem:
4/9 build rhel 5 x86
Navigate to a package details page.
Notice you can not see the sub items for
Click on Dependencies, now the two links
appear. I *think* the two items should
always be visible.
recreated the issues while checking a few other packages
Page was converted from perl to java. Assume we forgot to update links/acls on the
page vs old
Should be easy to fix the links to display all 3 additional tabs and not just the # Dependencies sub tab.
i looked at this before cperry assigned to jdobies. acls look ok in the navs on both perl/java stack. what is odd is after a restart or compile and restart the page displays ok. the package map that is returned by the java code does not have the archtype key in it for the refresh. the problem is either in the package acl handler or the code it calls.
ArchType needed a defined equals/hashCode method. Otherwise, the capability lookup by type was subject to object references and was non-deterministic.
not in the 422.2 build moving back to modified
Mass move to ON_QA for build on Apr 24.
same issue, may not have made it into the 4/24.1 build
fails.. not in 5/7.1 build
This only seems to occur on the first run of a new ISO installation. I temporarily increased the logging on why the ACL fails so we capture as much as possible on the rare occasion it fails. Will remove the logging (it's annoyingly chatty) after the next QA build.
Pitching back to QA. I've installed the latest ISO (May 29) twice locally and have not been able to reproduce it. I also asked jsherrill to give me a second pair of eyes on the code to see if we could find any issues, but everything looked good.
I'm wondering if the equals/hashCode changes from above for some reason weren't in the last QA build this was found on.
If you come across this again, please let me know as soon as you see it so I can take a look at the increased logging on the server.
finally working in 5/29 ;)
broken again in 6/12.1
These links aren't being displayed because the PackageAclHandler.aclPackageTypeCapable method is returning false when checking the ACL for the pages. This method will return false under the following conditions:
- The ACL does not provide any parameters. Those are defined in a static XML file that was double-checked to make sure the parameters exist. If this was the case, I doubt we'd see the non-deterministic nature of this bug.
- Any of the user, pid, or package retrieved from the DB was null. We wouldn't see the page at all if the user was null. We wouldn't see the package details if the PID or package was null. So I'm pretty confident this isn't the issue.
- The capability listing for the package's architecture is null. This is where I suspect the issue is, so more on this later.
- The capability listing for the architecture is retrieved but does not contain the ACL parameter in question. The entries in the capability listings are hard coded in the Java code, so if these were wrong I doubt we'd see the non-deterministic nature of this bug.
Given the above, I'm leaning towards the issue being in the retrieval of the capability listings for the given package architecture. These listings are returned in a map, where the key used to be (before this commit) the ArchType object itself. Previous attempts to fix this were to introduce the equals/hashCode method to this class, without which that retrieval by object is not guaranteed to be consistent. The lack of these methods was definitely a bug.
Looking further, when the capability map is created the ArchType objects being used as the keys are read from the database and held as static final objects in the PackageFactory class (the point being, they are loaded when the class itself is loaded). While in theory this should work, I have reservations about combining a hibernate retrieval with static constants in this manner.
Further investigation showed this retrieval isn't actually needed. The objects are being retrieved by the arch label which is hard coded in the PackageFactory class. Since this label is available at ACL checking time, the simpler approach is to use the label directly in the capability map. This avoids the initial DB hit to load and cache the ArchType objects (not that the queries were painful) but also makes the map retrieval simpler by simply using strings.
I'm not 100% certain this will fix the bug. However, it does remove one of the more potentially fragile areas of this flow (the database call) and simplifies the map lookup.
While I was in there, I changed the capability map to return sets instead of lists for the capabilities for a (very) minimal performance increase (and to feed my compulsion, a list just felt wrong there).
If this fails again in a future build, please let me know the machine as soon as possible, since restarting the Satellite server seems to make the issue go away and it's getting hard to have any solid time on a box that manifests the bug.
SUCCESS.. looks good :)
Verified in stage -> RELEASE_PENDING
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.