Unexpected dependee state changes

[thomas.diesler]

Bundle B depends on bundle X

install(X)
install(B)

start(B)

B == ACTIVE
X == RESOLVED

uninstall(X)

B == ACTIVE

The MC framework unexpectedly changes the state of B to RESOLVED

https://jira.jboss.org/jira/browse/JBOSGI-213

[thomas.diesler]

4.4.10 Uninstalling Bundles

Once this method returns, the state of the OSGi Service Platform must be the same as if the bundle had never been installed, unless:

* The uninstalled bundle has exported any packages (via its Export-Package manifest header)
* The uninstalled bundle was selected by the Framework as the exporter of these packages.

If none of the old exports are used, then the old exports must be removed. Otherwise, all old exports must remain available for existing bundles and future resolves until the refreshPackages method is called or the Framework is restarted.

[alesj]

Isn't it OK that B was un-winded, as its dependency X was uninstalled?
e.g. it cannot be active, if it's missing X's packages

[thomas.diesler]

It's not quite ok AFAIK

If this bundle has exported any packages, the Framework must continue to make these packages 
available to their importing bundles until the PackageAdmin.refreshPackages method has been 
called or the Framework is relaunched.

[thomas.diesler]

Bundle B may also use a BundleTracker to catch and react upon the state change of bundle X. This however would create a tight coupling between B and X, which you generally would like to avoid.

After uninstall of X, B should still be able to load classes from X. ServiceTracker should be used to act upon the unregistered services from X, but this would apply to bundleX.stop() as well.

[alesj]

I realize that this behaviour may not be natural to MC, but it is how OSGi works AFAIU.

After uninstall of X, B should still be able to load classes from X. ServiceTracker should be used to act upon the unregistered services from X, but this would apply to bundleX.stop() as well.

Both of these seem very un-natural to me.
* class leakage?
* stale services usage
* ...

Is there a valid reason to allow this?
Does it say when the PackageAdmin::refresh needs to be invoked?
(btw: why is PA even mentioned wrt core framework? shouldn't core be "self-sufficient")

[thomas.diesler]

I think the difference is between implicit and explicit re-wiring of the bundle graph. The OSGi spec chooses the explicit approach where you have to explicitly use PackageAdmin or restart the framework to cause a rewiring.

An implicit approach would mean that on every bundle update/uninstall the framework would bounce every bundle that depends on the uninstalled bundle causing a potential change in behaviour (because they wire to something else)

Anyway, this is how the spec defines the classloading sematics of uninstalled bundles.

Stale services can be avoided by using ServiceTracker i.e. you should never hold on to a service that is not being tracked.