States under which bundles are exporting packages

[bosschaert]

While looking at the PackageAdmin TCK I came across the following issue.

The TCK installs two bundles, one depends on the other. Both bundles export a package.

First the test checks that PackageAdmin.getExportedPackage(String) returns something for both of them

It then uninstalls the first bundle. It checks that the bundles still exports the packages, as PackageAdmin.refreshPackages() isn't yet called.

Subsequently it calls PackageAdmin.refreshPackages(). At this point the first bundle is removed, and the second bundle is moved back to the installed state, as its missing its dependency.

After this PackageAdmin.getExportedPackage(String) is called again on each of the two packages and it's expected to return null for both.

So I was thinking to implement this behaviour. It seems like that the behaviour could be defined such that if a bundle is in the INSTALLED state, it never exports a package, while in any other state (including UNINSTALLED) it potentially exports packages. The actually package information is obtained from the resolver module, which knows nothing about bundle state. The problem was that using the resolver information would return exported packages even in the INSTALLED state which is clearly not correct.

This got me passing the particular test, but I can't say I have a great feeling about it. Any other ideas on how to implement this?

[thomas.diesler]

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.

[bosschaert]

Thomas Diesler wrote:

Can we not simply model it like this? i.e. XPackageCapability + ClassLoader available

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.

[thomas.diesler]

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.

[bosschaert]

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?

[thomas.diesler]

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.