Bug 669729
| Summary: | default dashboard is blank with new database and clean | ||
|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | Simeon Pinder <spinder> |
| Component: | Core UI | Assignee: | Jay Shaughnessy <jshaughn> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 4.0.0.B02 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-09-02 07:18:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 705059, 715334 | ||
|
Description
Simeon Pinder
2011-01-14 15:02:39 UTC
This is worse than I initially thought. Importing platforms does not fix the Dashboard retrieval issue. This appears to be a problem in the smartgwt layer itself triggered by logic in the Dashboard page. I rolled back the smartgwt version to 2.2.RHQ1 and 2.2.RHQ2 and was still not able to fix this issue. We'll have to find out which Dashboard elements or logic is causing this error and rewrite/re-implement it. It is also important to do a mvn clean of the coregui element before building to successfully clean out the old javascript elements in between tests. Without clean, junk accumulates from previous builds masking the issue. After a completely clean build and new DB I could not reproduce this issue. I'm using commit 41a92e1. If you tried to get to CoreGUI via portal war's redirect there was a problem, the "#Dashboard" url was incorrect. This is corrected now in commit 0109deb7b7f70712dbfa05e6413d0222844f5fc6. Simeon, any additional follow up? I think this can be closed. I am also able to build the Dashboard without the earlier reported problem this morning as well without any changes to the source on either of the two boxes that were used to verify the earlier problem. As there were no changes to source that could cause spontaneous recovery I believe one or some combination of the following can be used to explain the described behavior:
i)the dependencies hosted by the maven repositories must have been affected by the recent cleanup for the git repositories that happened this weekend to improve clone times.
OR
ii) some communications problem affected/corrupting dependencies or build processes of two separate linux boxes on my local network were at fault.
OR
iii) my use of mvn3 -T {N} on multi-core boxes/builds contributed to a repeatable corruption causing the described issues.
In any event, the blocking issue around Dashboard builds appears to have been resolved or is being reliably avoided.
This issue can be closed.
This was fixed a while ago. Setting for QA in the current sprint. verified through clean install. Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago. |