Community
Participate
Working Groups
Dropping equinox.common bundle in pickup causes Virgo to issue: [2010-12-23 23:54:08.695] fs-watcher <DE0000I> Installing bund le 'org.eclipse.equinox.common' version '3.6.0.v20100503'. [2010-12-23 23:54:09.784] fs-watcher <DE0001I> Installed bundl e 'org.eclipse.equinox.common' version '3.6.0.v20100503'. [2010-12-23 23:54:09.792] fs-watcher <DE0004I> Starting bundle 'org.eclipse.equinox.common' version '3.6.0.v20100503'. Removing the bundle from pickup after a minute produces: [2010-12-23 23:49:31.532] start-signalling-1 <DE0006E> Start failed fo r bundle 'org.eclipse.equinox.common' version '3.6.0.v20100503'. java.lang.Runti meException: bundle stopped The bundle has lazy activation policy.
After dropping the bundle it stays in LAZY state. If its manually started (via the shell) and then removed from the pickup folder then no exception is produced.
I think this is pretty much working as designed. According to the OSGi core spec, a bundle with lazy activation is intended to transition from STARTING to ACTIVE state when a class is loaded from the bundle. So in Virgo, the corresponding bundle install artifact remains in STARTING state until such a transition occurs. If the bundle is removed from pickup, then the undeploy stops the bundle. The only thing which is perhaps a little undesirable is the DE0006E Start failed message. It would be better to have the normal stopping/stopped/uninstalling/uninstalled messages in this case. So maybe we have to add a LAZY (starting) state to the InstallArtifact. Note that any plan including a lazy activation bundle will also enter the LAZY (starting) state until such time as the bundle has transitioned to ACTIVE. However, the title of this bug is that equinox.common cannot be deployed via pickup and I don't think this is the case based on the analysis above. IMO, we should either close the bug as "working as designed" or change the title to cover the stop behaviour.
You are right that the bundle is deployed. From equinox shell it seems that the bundle is not started at all (nor STARTING, neither STARTED is visible but just <<LAZY>> as a status) and this seems to be the reason for the exception on stop/removal. I've changed the bundle title, because I think the exception is confusing - the user did not performed any actions (stopping the bundle for instance) and should not normally get "bundle stopped" exception. We should at least change the behavior in this case. Addind LAZY status seems to me the right thing to do, but I'm not sure if this can be done without implications to the already working scenarios.
OSGi does not define a LAZY state of a bundle. It is an implementation-specific sub-state of STARTING detected by the following code in FrameworkCommandProvider: case Bundle.STARTING : synchronized (lazyActivation) { if (lazyActivation.contains(bundle)) { return "<<LAZY>> "; //$NON-NLS-1$ } return "STARTING "; //$NON-NLS-1$ } So I think it would be a mistake to add LAZY as a new state of InstallArtifact. For example, LAZY would be treated as a top-level state and anyone testing for STARTING would then need to be re-coded to test for STARTING or LAZY. Instead, we should probably somehow just surface the result of lazyActivation.contains(bundle) and use that to make uninstall and stop work sympathetically.
Work completed. The start tracker that throws the runtimeException will now listen for LAZY activation as well and remember. Then when stop is called before it finishes starting it will tidy up the tracker state properly (call the correct signal type in the kernel) but not throw an exception. The activation of a lazy bundle will also be logged at INFO. Unit test added
Marking as reopened as although it is fixed it results in an odd started message coming out when it is actually stopping.
Work complete, the concept of aborting a bundle start is now supported
