Hi Marcel, Thanks for your clarification, I'm aware of the fact that I cant update the "core" bundles but need some starting point to be able to improve ;)
It gets even worse .... OpenJPA uses a javaagent for runtime enhancement of the Entity classes when the classes are resolved. For now I can live with not being able to update the core / platform bundles and try to focus on being able to do "live" updates for my application components. Regards, Bram 2013/5/29 Marcel Offermans <[email protected]> > 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 > >
