Felix Meschberger <[EMAIL PROTECTED]> writes: > If you stop the bundle, the bundle is stopped (if not started) and > permanently marked stopped.
That started to dawn on me as I was finishing writing my message: the absence of being permanently marked as started is the same as being permanently marked as stopped. I never found this asserted in the specification, but it's the behavior exhibited by Felix as of now. > If stop and restart the framework, the bundle is still permanently > makred stopped and will not be started even though it could be > started as per the start level. > > Consequently, the system works as specified. I follow your logic, per the assertion about permanent marking above. > Regarding, whether Resolver.deploy(boolean) should start resources > added to the resolver but not selected for deployment: I am more > happy with the situation of the Resolver not touching the state > existing bundles. That said, I am in favor of not having the > resolver start bundles not elected for deployment. Where we differ here is in the "not elected for deployment" qualifier. I'll describe my anticipated use case and see if my preference still holds up through the description. In my system, the application running the OSGi framework is a client to a server that provides bundles for download, and directs the client to "make use of" certain bundles. The server will tell the client to use bundles "foo" and "bar" today, where these bundles should be installed (if not already), started, and certain advertised services provided by the bundles and detected by the application should be used. Once these services have been used once, the bundles can be stopped and even uninstalled, but for now I'm assuming the bundles are just stopped. The next time the application runs, it may be directed by the server to "make use of" bundles "foo" and "quux". The second one would need to be downloaded, but the first one is still installed from a previous run. If the application operates by constructing filters to discover resources with OBR, it doesn't need to know that "foo" is already installed and "quux" isn't; the OBR discover-resolve-deploy interface accommodates ensuring both "foo" and "quux" will be present and resolvable at the end. But when the application tries to deploy "foo" and "quux", passing the true "start" parameter to Resolver.deploy(), "quux" will be started but "foo" will not be, as "foo" had been stopped on a previous run. In order to make sure that each of the bundles targeted for deployment get started, the application would have to inspect the set returned by Resolver.getRequiredResources(), looking for a symbolic name match to see if each of its targets are mentioned. Those not mentioned would then need to be started explicitly. This seems needlessly complex, especially given the contract implied by the "start" parameter accepted by Resolver.deploy(). Doesn't supplying a true "start" parameter mean, "Start all of these up"? The present behavior is more like, "Start up the ones I don't have, even though I'm not sure which ones those are." -- Steven E. Harris
