Hi, In my quest to make the installation/update/removal of bundles by jcrinstall less asynchronous (see also SLING-733), I had a chat with Felix and we talked about using OSGi start levels more systematically in Sling, and especially in jcrinstall.
Here's a set of proposed changes to jcrinstall, comments are welcome. 1. The jcrinstall bundle is installed with a low start level (say 20), lower than that of "application bundles" 2. Bundles installed by jcrinstall are set to a higher start level (say 50), configurable in the jcrinstall service. 3. All initial bundle install/remove/update calls made by jcrinstall happen in its activate() method The goal is to make sure all bundle operations made by jcrinstall happen before any of the bundles that it installs actually start - that should help make the startup sequence more predictable. Furthermore: 4. If the repository service goes away, jcrinstall brings the OSGi framework's current start level down to its own start level (20 in our example), and if possible (how?) makes sure all services that were started at higher levels are stopped. 5. When the repository service comes back, the 1/2/3 rules above apply, to make sure all bundle operations happen before bundles installed by jcrinstall are started. 6. Once this is done, jcrinstall tells the OSGi framework to return to the start level that was current before 4. I'll hopefully start working on this next week. -Bertrand
