Hello Bram, On May 29, 2013, at 20:38 PM, Bram Pouwelse <[email protected]> wrote:
> I'm aware that it's a bad practice to depend on deployment / start > order..... But the application is using JPA for persistence to reslove most > of the start / deployment order issues I'm currently using the Karaf > container with and use the features to provision the "platform" > functionality JTA, JPA (OpenJPA) JNDI and the last feature that gets > installed is the ace managementagent. > After that I'm using Ace to deploy my application bundles. I'll have to > investigate further which bundles in my application are still picky about > start order ... The biggest issue with depending on startup order is not the startup itself (by specifying the order there, you can indeed make things work) but subsequent updates. Let's say you have three bundles and depend on them starting in order: B1 -> B2 -> B3. Now assume you have an update for B2. During this update it will be stopped, and the new version restarted. B3 however, depended on B2 already being started, so chances are high that during the update, B3 will get confused because it does not expect B2 to disappear at all after it has started itself. So solving the startup problem then introduces an update problem. The only thing you can now do is the following: assign startlevels to the bundles and use an update process that is aware of these startlevels, as follows: Assume we start by giving bundle B1 startlevel 1, B2 = 2, B3 = 3. If we manage to assign those startlevels before starting the bundles, the order in which they start will be enforced by the startlevel service. That is good. Now what happens if we update B2. If our management agent detects that B2 needs updating, it can first bring the framework down to its startlevel, so 2 in this case, then do the update, and then go back to the highest startlevel again. That way, B3 is started again after B2 and will probably work just fine. This has two downsides: 1) If you update "core" bundles, you are practically stopping and restarting the whole application, which defeats the purpose of OSGi and performing "live" updates. 2) Bundles that assume certain startup ordering sometimes do not do proper cleanup when they are stopped. This is obviously not always the case, but I've seen bundles misbehave like that. If that happens, you'll have a tough time OSGi-ifying such code anyway and you might have to patch third party code anyway to make it behave. Further background info on startlevels in a blog article I wrote: http://www.planetmarrs.net/start-levels-in-osgi/ Greetings, Marcel
