It wasn't, but I like your thinking. You could look to see if the
Import-Package has optional imports or check for DynamicImport-Package
and if so do it the expensive way, but if they are not there use the
method I suggested. You'll have to check the fragments too, but that
might be possible.
Alasdair
On 8 Jan 2010, at 23:26, Jarek Gawor <[email protected]> wrote:
I don't know if that's what Alasdair meant but you could parse the
Import-Package header and using PackageAdmin check if one of the
bundles that exports a given import package is actually wired to the
importing bundle. That should be more efficient than going through all
bundles and all exports. However, if bundle has DynamicImport-Package
might as well do the full scan.
Jarek
On Fri, Jan 8, 2010 at 4:40 PM, Alan Keane <[email protected]>
wrote:
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]
