Thomas Diesler wrote:
This change causes regression in bundle lifecycle handling. I added test coverage for this in the framework's BundleLifecycleTestCase
<snip/>
I still need to look into the details of why this would happen.
It's happening because B's deployment unit has required-stage of "CLASSLOADER" (RESOLVED in OSGi) after the start() failed.
i.e. it wants to resolve it.
So when you install bundleX, it also says, hey B is not in the correct state and I can resolve it now,
but only by moving X to ClassLoader as well.
That is what lazy resolve is all about. It automatically resolves other classloaders that it needs if they are not resolved.
If B went back to required-stage "DESCRIBE" (INSTALLED in OSGi) after the start() failed then your test would work as expected.
I worked this out by adding the following to the test after the b.start() failure:
OSGiBundleState bs = (OSGiBundleState) getBundleManager().getBundleState(bundleB);
System.out.println(bundleB.getSymbolicName() + " state=" + ConstantsHelper.bundleState(bundleB.getState()) + " required=" + bs.getDeploymentUnit().getRequiredStage());
Which produces:
lifecycle-bundleB state=INSTALLED required=ClassLoader
So you can see the bundle state is inconsistent with the deployment unit state.