Issue Details (XML | Word | Printable)

Key: GLASSFISH-13169
Type: Improvement Improvement
Status: Closed Closed
Resolution: Invalid
Priority: Critical Critical
Assignee: Sanjeeb Sahoo
Reporter: Tom Mueller
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
glassfish

Add diagnostic information to explain why a module is being resolved

Created: 27/Aug/10 10:22 AM   Updated: 11/Mar/13 03:29 PM   Resolved: 11/Mar/13 03:20 PM
Component/s: OSGi
Affects Version/s: 3.1
Fix Version/s: None

Time Tracking:
Not Specified

Environment:

Operating System: All
Platform: All


Issuezilla Id: 13,169
Tags:
Participants: Richard S. Hall, Sanjeeb Sahoo and Tom Mueller


 Description  « Hide

The OSGi shell permits one to view what modules have been resolved at a
particular point in time. However, it is also important to know why a module
has been resolved. What module was it that triggered getting a module resolved?

This is a request to add diagnostic information to the system so that one can
find out why a module was resolved. Preferably, this would show the entire chain
of resolutions, starting with the explicit activation of a module, i.e., a
module that is in the Active state. For example, if module A is activated, and
it references module B which reference modules C which in turn references D, it
should be possible to execute some command or view some log output and see:

D <-- C <-- B <-- A

The inspect command in the OSGi shell does this to some extent. However, it is
not clear what the meanings of package, bundle, fragment and service are WRT an
OSGi module, and the dependencies as shown by that command appear to be
theoretical based on what is declared in the meta data rather than what actually
happened when a module was loaded.



Sort Order: Ascending order - Click to sort in descending order
kenaiadmin made changes - 26/Nov/10 12:14 AM
Field Original Value New Value
issue.field.bugzillaimportkey 13169 44773
Chris Kasso made changes - 13/Dec/10 03:36 PM
Fix Version/s not determined [ 11149 ]
Tom Mueller made changes - 06/Mar/12 10:45 PM
Assignee dochez [ dochez ] Sanjeeb Sahoo [ ss141213 ]
Sanjeeb Sahoo made changes - 11/Mar/13 03:54 AM
Status Open [ 1 ] Resolved [ 5 ]
Resolution Won't Fix [ 2 ]
Tom Mueller made changes - 11/Mar/13 03:10 PM
Resolution Won't Fix [ 2 ]
Status Resolved [ 5 ] Reopened [ 4 ]
Sanjeeb Sahoo made changes - 11/Mar/13 03:20 PM
Status Reopened [ 4 ] Closed [ 6 ]
Resolution Invalid [ 6 ]