ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: My first impression of ace
Date Wed, 29 May 2013 20:48:46 GMT
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

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