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
