Let me throw in my 2 cents about the StartLevel subject. I was originally of the impression that I needed to explicitly control the start order of our bundles. We have about 25 bundles that all depend on 2 core bundles. Some of the bundles' services interact with other bundles' services. Our primary (core) bundles implement BundleListener and ServiceListener and all the bundles utilize ServiceTrackers for getting at one another's services. We initially encountered some problems, but it turned out that it wasn't due to the start order of the bundles, it was due to our use of ConfigurationAdmin.
As Richard points out, all of the dependencies are handled quite nicely by the framework. We deploy our bundles by copying them into the autodeploy/bundles area (we're using GlassFish). When we start from scratch, we can drop all 25+ bundles in at once and all of the bundles will start up and resolve properly. If you try to access other services from within your BundleActivator classes, then you may encounter some contention issues. We have noticed, however, that once the bundles are started up, they retain that particular start order on framework restarts until the OSGI cache is cleared out. The one area where we did encounter problems is the use of Configurations. We have a couple of config files that we put into autodeploy/bundles that we access using the ConfigurationAdmin mechanism. These do not seem to follow any particular start order. In fact, most of the time the Configurations seem to get created after all of the bundles are resolved. When we try to access those from the BundleActivator, then there may be times when the Configuration is not available. Larry Touve --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
