ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram Pouwelse <>
Subject Re: My first impression of ace
Date Wed, 29 May 2013 21:39:09 GMT
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.


2013/5/29 Marcel Offermans <>

> Hello Bram,
> On May 29, 2013, at 20:38 PM, Bram Pouwelse <> 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:
> Greetings, Marcel

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message