| Summary: | Viewing an OSGi state dump fails | ||
|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Glyn Normington <glyn.normington> |
| Component: | web-admin | Assignee: | Chris Frost <eclipse> |
| Status: | CLOSED FIXED | QA Contact: | Project Inbox <virgo-inbox> |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse, tjwatson |
| Version: | 3.0.1.RELEASE | ||
| Target Milestone: | 3.6.0.M01 | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
| Bug Depends on: | 352217, 361905 | ||
| Bug Blocks: | |||
|
Description
Glyn Normington
The bug is caused during analysis of the state dump by Virgo. StandardStateHolder uses an instance of StandardStateService to read the OSGi state dump, but the StandardStateService instance refers to the live region digraph and so when StandardStateHolder uses the StandardStateService instance to access region related information, this gives the wrong results because it knows nothing of the coregion (used to hold temporary bundle ids created during the "side state" resolution process). The precise solution is not yet clear, but it will involve accessing region information via a QuasiFramework instance which has been loaded with the dumped region digraph. The approach to browsing OSGi state dumps in the admin console is changing radically under bug 360993. When that bug has been implemented, this bug should be fixed. Therefore no further work is planned on this bug as it would be a waste of effort. (In reply to comment #2) > The approach to browsing OSGi state dumps in the admin console is changing > radically under bug 360993. When that bug has been implemented, this bug should > be fixed. Therefore no further work is planned on this bug as it would be a > waste of effort. Out of curiosity, did the bug 361905 contribute to this issue and is that fix in bug 361905 needed for the changes discussed in bug 360993 to properly work? (In reply to comment #3) > (In reply to comment #2) > > The approach to browsing OSGi state dumps in the admin console is changing > > radically under bug 360993. When that bug has been implemented, this bug should > > be fixed. Therefore no further work is planned on this bug as it would be a > > waste of effort. > > Out of curiosity, did the bug 361905 contribute to this issue and is that fix > in bug 361905 needed for the changes discussed in bug 360993 to properly work? Good questions! The answers are: no and no. The only contribution of bug 361905 to this issue is the confusion factor caused by the broken invariant in the "live" digraph (which is -- the subject of this bug -- confused with the digraph reconstituted from the dump). Bug 361905 breaks the invariant of the "live" digraph by leaving bundleId->Region mappings around for regions(*) which have been removed. When the digraph is persisted and read back in, the bundleId->Region mapping is reconstructed from the region contents and so any effects of bug 361905 are removed from the reconstituted digraph. * - only one region, the "coregion", is actually removed. It is repeatedly created and removed, each time the deployment pipeline runs. Once the Equinox region bundle is upgraded to pick up the fix to bug 361905, all that remains to do is to fix the admin app code which uses the wrong instance of the region digraph. However, this code will be deleted by bug 360993, so once bug 360993 is fixed, this bug should also be verified and closed. New Admin Console is merged in to the Kernel complete with a state dump viewer. |