Bundle.start() does not transition to ACTIVE

[thomas.diesler]

It seems that bundle.start() does not transition the bundle's state.

[tdiesler@tdvaio osgi-int]$ mvn -Dtest=SimpleBundleTestCase install

Running org.jboss.test.osgi.simple.SimpleBundleTestCase
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.793 sec <<< FAILURE!

java.lang.AssertionError: Bundle state expected:<32> but was:<2>
 at org.junit.Assert.fail(Assert.java:92)
 at org.junit.Assert.failNotEquals(Assert.java:689)
 at org.junit.Assert.assertEquals(Assert.java:127)
 at org.junit.Assert.assertEquals(Assert.java:514)
 at org.jboss.test.osgi.simple.SimpleBundleTestCase.testBundleInstall(SimpleBundleTestCase.java:78)

I see

 /**
 * Start a bundle
 *
 * @param bundleState the bundle state
 * @throws BundleException the bundle exception
 */
 public void start(OSGiBundleState bundleState) throws BundleException
 {
 try
 {
 // todo check actually changed state
 deployerClient.change(bundleState.getDeploymentUnit().getName(), DeploymentStages.INSTALLED);
 }
 catch (DeploymentException e)
 {
 Throwable t = e.getCause();
 if (t instanceof BundleException)
 throw (BundleException) t;
 throw new BundleException("Error starting " + bundleState, e);
 }
 }

Could you please explain how this is supposed to work?

[thomas.diesler]

I'll have a look

https://jira.jboss.org/jira/browse/JBOSGI-130
https://jira.jboss.org/jira/browse/JBOSGI-131

[thomas.diesler]

I added some cause analysis and it seems that both PackageRequirements should either not be there or get resolved.

org.osgi.framework: from declared system packages
org.jboss.test.osgi.simple.bundle: from the bundle itself

testBundleInstallLauchAPI(org.jboss.test.osgi.simple.SimpleBundleTestCase) Time elapsed: 4.215 sec <<< ERROR!
org.osgi.framework.BundleException: Cannot start bundle Bundle{simple-bundle:0.0.0}, because of unresolved dependencies
 [PackageRequirement{org.osgi.framework [0.0.0,?)}, PackageRequirement{org.jboss.test.osgi.simple.bundle [0.0.0,?)}]
 at org.jboss.osgi.plugins.facade.bundle.OSGiBundleManager.start(OSGiBundleManager.java:494)
 at org.jboss.osgi.plugins.facade.bundle.OSGiBundleState.start(OSGiBundleState.java:736)
 at org.jboss.osgi.plugins.facade.bundle.OSGiBundleState.start(OSGiBundleState.java:724)
 at org.jboss.osgi.plugins.facade.bundle.OSGiBundleWrapper.start(OSGiBundleWrapper.java:176)
 at org.jboss.test.osgi.simple.SimpleBundleTestCase.testBundleInstallLauchAPI(SimpleBundleTestCase.java:62)

[thomas.diesler]

I now throw a BundleException on unresolved RequirementDependencyItems

The problem of

org.osgi.framework.BundleException: Cannot start bundle Bundle{simple-bundle:0.0.0}, because of unresolved dependencies

PackageRequirement{org.osgi.framework [0.0.0,?)},
PackageRequirement{org.jboss.test.osgi.simple.bundle [0.0.0,?)}]

I fixed by only adding PackageRequirement for packages that are not system and not exported.

Please see OSGiBundleClassLoadingDeployer for details

This probably needs some more work, because a simple package name match between the import and the export is not sufficient

[alesj]

I fixed by only adding PackageRequirement for packages that are not system and not exported.

This looks like a hack, at least the "not exported" part.

Where it might make sense for system stuff, which doesn't go over MC's CLDescribe deployer,
hence not describing its exporting packages --> making sense to exclude them.

But I don't see why this would be useful for imports?
The imports are declarative info, so why should it be excluded if it's also found in exports?

[thomas.diesler]

Yes, I agree.

The OSGiBundleClassLoadingDeployer currently contains this TODO

// [TODO] Import package requirements should probably resolve against export capabilities
boolean isExportPackage = exportedNames.contains(packageName);

The configured system packages are now set as a filter on the parent domain. Please see OSGiClassLoaderSystem for details.

[adrian.brock]

I'd actually already fixed this TODO, but not committed it yet.

The issue is more general than your fix. My fix is to checkIncomplete()
on the deployment since there are other things besides missing dependencies that
can cause the bundle not to start.