Does the 'Start-Level' a standard OSGi property ? On Fri, Oct 15, 2010 at 10:04 AM, Larry Touve <[email protected]>wrote:
> Here's how I solved this. I need to keep testing to make sure everything > works as expected. > > I created a StartupManager bundle that implements BundleListener and does > the following: > > - At activation time, it sets the Framework Start Level to 3 (this could > also be done with the system.config property) and installs a BundleListener > - The BundleListener listens for bundles to be INSTALLED. When it detects > one, it: > - Checks for a manifest header property called 'Start-Level'. If this > is set, it sets the bundle's start level to this value using the StartLevel > service. > - If there is no property set, but it is still one of my application > bundles, it sets the start level to a default value (so I don't have to add > the property to 20+ bundles) > > For the couple of bundles that I want to start first, I set the > Start-Level property to 2 in the pom file. > > I copied the StartupManager bundle into the autodeploy/bundles directory. > After it started up, I deployed my bundles by copying them to the > autodeploy/bundles directory. Using the Felix Web Console, I verified that > the Start Level of the bundles was correct. Then I shutdown the framework > and restarted it. I verified that no INSTALLED event was occurring , just > the RESOLVED and STARTED events. I checked that the Start Level was set > correctly (using the Web Console) and that all the bundles were started up > in the right order. > > Using the Web Console, I can change the Start Level back to 1 and all of > my bundles get stopped, and move to the RESOLVED state. I can start them up > again by changing the Start Level back to 3 (or higher). > > I'm still not sure why the asadmin deploy behavior is so different for the > bundles. That's something I can look into later - my deadline for this is > fast approaching. > > larry > > > >
