hi Karaf devs-
i have a question about start-level behaviour in karaf/felix. the osgi
spec says that start-levels should increase 1 by 1 during startup [1].
this doesn't seem to be happening in a clean karaf-based environment.
what we observe is that startlevel jumps directly to the `beginning`
level (100 in our case) before our boot bundles (at
karaf.startlevel.bundle=80) are started -- a log(startlevel) in one of
the boot bundle activators shows "100" on a clean install. on a
subsequent startup it shows "80":
/bin/start
....
2020-11-23T11:32:01,159 - INFO 175 o.a.b.u.o.OsgiActivator
[tures-3-thread-1] Starting org.apache.brooklyn.utils-common [175], at
start level 100, state 8
....
/bin/stop
....
2020-11-23T11:40:04,651 - INFO 175 o.a.b.u.o.OsgiActivator
[FelixStartLevel] Stopping org.apache.brooklyn.utils-common [175]
....
/bin/start
....
2020-11-23T11:40:15,431 - INFO 175 o.a.b.u.o.OsgiActivator
[FelixStartLevel] Starting org.apache.brooklyn.utils-common [175], at
start level 80, state 8
we are on 4.2.8. there are related issues [2] where this has been
observed, but this particular issue wasn't the focus; other suggestions
in those issues, to set `featuresBootAsynchronous=false` and to add
items to `startup.properties` are not working for us (although maybe I'm
not adding the right bundles to startup.properties).
i totally buy the argument that declarative dependencies are better in
most cases, but i think this is one of those use cases where relying on
start-levels is justified. one actual problem we're trying to solve is
preventing hot deployment until after all the boot bundles are started.
but because startlevel is jumping directly to 100, these settings don't
work as expected:
felix.fileinstall.start.level=95
felix.fileinstall.active.level=95
we'd expect based on startlevel that fileinstall shouldn't start until
boot bundles are installed (startlevel 80). but instead fileinstall
starts trying to hot-deploy right away, because startlevel jumped to
100, and because our boot bundles aren't yet available, it fails for a
while. once the boot bundles are installed, the hot-deploy bundles get
wired in fine and it all works, and the start-levels as shown in
`bundle:list` are as expected (80 and 95), but we'd ilke not to have all
the failed hot-deployment attempts, and there might be hot-deployed
bundles that users install which interfere with the boot wiring in ways
we don't want (offering other services, etc). so this seems a common
and desirable use case for startlevels to be obeyed -- useful enough
anyway that the fileinstall authors provided those settings!
we also have another related problem that this is blocking, that we
would like some of our bundles not to do some initalization until
user-supplied hot-deploy bundles are installed, as discussed on the
Apache Brooklyn ML (and hence the cross-post).
so ... is there a way to have a karaf clean startup see our boot bundles
and start levels and not jump to 100, so it completes startlevel 80
before startlevel 95 kicks in? ... or some other way to have fileinstall
not run until our boot bundles are installed?
many thanks.
best
alex
[1]
https://docs.osgi.org/specification/osgi.core/7.0.0/framework.startlevel.html
-- section 9.3.1
> The Framework must then increase or decrease the active start level
by 1 until the requested start level is reached.
> The Framework must not increase to the next active start level until
all started bundles have returned from their BundleActivator.start method
[2] Related issues:
https://issues.apache.org/jira/browse/KARAF-4261
https://issues.apache.org/jira/browse/KARAF-4723
https://issues.apache.org/jira/browse/KARAF-4578
https://issues.apache.org/jira/browse/KARAF-4498
PS: related curiousity, if i set `beginning=90` in the above case and
then manually increase the startlevel to 100 later, it works, but i have
the `org.apache.servicemix.bundles.dom4j` bundle in my deploy/
directory, and that makes Karaf destroy lots of the blueprint services
we created during boot. i can't see why they would, as a bundle it
seems pretty simple, our other bundles don't use the dom4j classes, the
logs don't give any reason why in this case, and if it's hot-deployed
early we don't have any issues; so again I'm grateful if anyone has
thoughts on why this would happen!
