Right, there is no well defined start order for bundles in the same start level - so this doesn't help us. If we need an order, we have to use different start levels
Adjusting the start level for an update should be easy (the OSGi installer does so already) and hopefully a simple fix in the launchpad. However, all this adds a lot of cruft to fix a single simple problem in a logging implementation. I see the point that slf4j releases might take some time, but I think that's the right place to fix it and avoids adding additional stuff all over the place. Carsten 2014-01-29 Bertrand Delacretaz <[email protected]> > On Wed, Jan 29, 2014 at 10:58 AM, Chetan Mehrotra > <[email protected]> wrote: > > ...So can we go for #2?... > > Which is adding custom bundle header 'x-sling-startup-order' that our > bootstrap installer takes into account? > > But how is that handled? Set the bundle's OSGi start level to a > different value than 1? > > Otherwise, if it's just the bootstrap installer that handles this > header, on the next startup the bundles will again start in an > unpredictable order, if they have the same start level. > > Changing the start level is also problematic when you upgrade an > existing system, as in this case AFAIK we don't reset the start level > for bundles that are just updated. > > So I think if we want this to be robust we need a mechanism that: > > a) Allows for setting another start level than 1 for some bootstrap bundles > > b) Adjusts the start level of existing such bundles when they are > updated by a future Sling launchpad > > -Bertrand > -- Carsten Ziegeler [email protected]
