-
1. Re: States under which bundles are exporting packages
thomas.diesler Sep 6, 2010 4:45 AM (in response to bosschaert)It is correct that the XModule provides access to the bundle's metadata irrespective of the bundle's state. We need that information for the resolution algorithm and perhaps some other impact analysis.
When a bundle is RESOLVED it's ClassLoader is available.
The ExportedPackage API says:
The term exported package refers to a package that has been exported from a resolved bundle. This package may or may not be currently wired to other bundles.
Can we not simply model it like this? i.e. XPackageCapability + ClassLoader available
I don't really understand what you do with the revisions here and why can getCanonicalName() access the BSN but not the version?
My understanding is that a bundle always has at least one revision (the current revision). Initially or after beeing refreshed a bundle has exactly one revision. After uninstall a bundle disappears from the framework if it has no active wires. If it has active wires it remains in the framework util that is no longer true.
-
2. Re: States under which bundles are exporting packages
bosschaert Sep 6, 2010 5:57 AM (in response to thomas.diesler)Thomas Diesler wrote:
Yes - that works too. Thanks for the tip.
Thomas Diesler wrote:
I don't really understand what you do with the revisions here and why can getCanonicalName() access the BSN but not the version?
My understanding is that a bundle always has at least one revision (the current revision). Initially or after beeing refreshed a bundle has exactly one revision. After uninstall a bundle disappears from the framework if it has no active wires. If it has active wires it remains in the framework util that is no longer true.
When the bundle is uninstalled and refreshPackages() is called, it should not have a revision any more (IMHO). refreshPackages() should force the bundle out of the system, even if it has active wire prior to this call.
The TCK calls PackageAdmin.getExportedPackages() on a bundle that has been uninstalled and refreshed. Before my changes, refresh packages always keps a revision in the system - this meant that the TCK call mentioned would return packages that it shouldn't.
I split up clearRevisions() into clearRevisions() and clearOldRevisions(), the latter keeps the most recent revision, the former removes all revisions.
clearRevisions() is called when a bundle is removed due to an uninstall(+refreshpackages). clearOldRevisions() is called when the bundle is refreshed. Does this make sense to you?
The issue with getCanonicalName() is that getVersion() depends on the current revision, which may not always exist, however the BSN is always available.
-
3. Re: States under which bundles are exporting packages
thomas.diesler Sep 6, 2010 6:11 AM (in response to bosschaert)Sorry, I don't get it.
If refresh is called on an unistalled bundle, that bundle is removed from the framework and its revisions with it.
If refresh is called on a resolved (but not uninstalled) bundle, the bundle stays in the framework and may get resolved again as part of the refresh. In any case it has a current revision.
Please explain again why a bundle should be kept in the framework without having a revision.
-
4. Re: States under which bundles are exporting packages
bosschaert Sep 6, 2010 6:38 AM (in response to thomas.diesler)Thomas Diesler wrote:
Please explain again why a bundle should be kept in the framework without having a revision.It's the test that holds on to the bundle . The revision object associated with the bundle was kept in the system because the TCK test held on to the bundle.
So the test does something like this:
1. b.uninstall();
2. packageAdmin.getExportedPackages(b); <-- expects not null, since someone is using b's packages
3. packageAdmin.refreshPackages(b);
4. packageAdmin.getExportedPackages(b); <-- expects null, but was previously returning some packages, due to a revision being kept
Thinking more about it, it might be a better idea to let getExportedPackages() check with the BundleManager that the bundle in question is still known to the system?
-
5. Re: States under which bundles are exporting packages
thomas.diesler Sep 6, 2010 6:54 AM (in response to bosschaert)Thinking more about it, it might be a better idea to let getExportedPackages() check with the BundleManager that the bundle in question is still known to the system?
Yes, all API on Bundle, BundleContext and services that operate on Bundle must check this. In AbstractBundleContext we have the notion of destroyed, which we check in every API call. In Bundle we could have a similar notion. PackageAdmin can safely ignore "destroyed" bundles.