In that case as Valentin says there is no other way to get to this. I have to admit I always thought it was odd that OSGi didn't make it easier to get the packages imported from a bundle. The framework must hold this information for class loading to work efficiently. There might be API's in specific implementations that allow for this more efficiently, but that isn't ideal.
On the subject of the MBeans looking at the PackageStateMBean the getExportingBundle allows you to specify a package name and version and returns the id of the exporting bundle. Do you know what should happen if the package is exported by multiple bundles? Alasdair 2010/1/8 Alan Keane <[email protected]>: > This would be somewhat static and would not give any indication of the > runtime > resolution of optional imports etc. > The bundle headers are available through another method on the > BundleStateMBean. > > Alan > > On Fri, Jan 8, 2010 at 9:26 PM, Alasdair Nottingham <[email protected]> wrote: > >> Can you not call Bundle.getHeaders().get("Import-Package")? >> >> That will return a them all as a single string, but we have code in >> the application component that can correctly split this up in the >> individual packages. We could move this into the util package so it >> can be shared. >> >> Alasdair >> >> 2010/1/8 Alan Keane <[email protected]>: >> > I'm looking for a standard way through the Framework API to inspect a >> > bundle's resolved bundle dependencies and imported packages. >> > The BundleStateMBean defines a #getImportedPackages(long bundleId) & >> > #getRequiredBundles(long) method. >> > >> > The processing used for getImportedPackages >> > (FrameworkUtils#getBundleImportedPackages) >> > in particular will iterate through all bundles in the framework, query >> for >> > ExportedPackages on each one and check for a match on the importing >> bundles. >> > >> > Any ideas on a more efficient (standard) way of doing this? >> > >> > Cheers, >> > Alan >> > >> >> >> >> -- >> Alasdair Nottingham >> [email protected] >> > -- Alasdair Nottingham [email protected]
