Not sure if I understand it fully, but I found JIRA's use of osgi "startup" 
pretty good. It seems very controlled, as it actively monitors plugins (osgi 
bundles of course) on startup and waits a given timeout until they start. If 
they fail to start, they get disabled. You see this all happening in the 
logging (e.g. when developing a JIRA plugin). It seems made so that non-core 
stuff can't bring the system down. I don't know much about the internals 
though, I assume they know what are "plugin" bundles and what are "core system" 
ones.

Cheers,
Alex

> On 09.07.2015, at 05:55, Bertrand Delacretaz <[email protected]> wrote:
> 
> Hi,
> 
> While working on SLING-4851 to extract the launchpad start levels
> sequencing logic (aka "wait for the installer to do its thing at each
> increasing start level") into independent bundles, I wrote a proof of
> concept using the following API:
> 
>  public interface StartLevelChangeBarrier {
>    CountDownLatch getStartLevelLatch(int startLevel);
>  }
> 
> Modules can supply such a service so that the new start levels
> sequencer waits for their CountDownLatches to go to zero before
> proceeding to the next start level.
> 
> The main advantage is that this avoids the current 2-seconds delay
> between start levels that the launchpad currently needs, if we can
> adapt the OSGi installer to provide this service efficiently. And if
> the installer still needs this delay, it would at least be internal to
> that module.
> 
> See the ticket for more details, feedback is welcome - I might not
> work on this again for about two weeks but as usual feel free to steal
> the good ideas if there are any ;-)
> 
> -Bertrand

Reply via email to