As Thomas indicated, you're confusing wiring and start stop. The wiring is basically creating a class path for the bundles. Since the java VM is very picky there is no way you can do anything useful in java before a class can properly link to its context. Start and stop in OSGi is different. It tells a bundle to provide its function or not. When you use services this model makes a lot of sense.
So you're using in the wrong way. As with any technology it is a bad idea to go against its intended usage, however close it may seem. If I get your root requirement then I think the best solution is to create a "management" bundle. This bundle looks at your property and installs the proper bundle. This can be done quite easily with the OSGi api and saves some memory as well.
Unfortunately, in Eclipse you will then be confronted with the little problem of starting your management bundle ...
Kind regards,
Peter Kriens Sent from my iPad
Right, so taking a deeper look, it seems that the version dependencies are all fixed early on in the framework's startup during the call to SystemState.resolve(). So, even if I call stop() later oniensfor the 2.0 bundle, it is already wired to other bundles (and will get restarted when a class of its is loaded). So, it looks like calling stop and start in downstream bundles is happening too late. This brings me back to my original solution, which I want to avoid is to get into the framework early enough so that I have control over how the resolving happens.
|