karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject [HEADSUP] Persistent wiring in Karaf 4.1
Date Wed, 05 Oct 2016 06:31:22 GMT
The Karaf 4 resolver does a great job of finding a good solution for some
deployments.  Unfortunately, it's even a bit too smart.
I had a use case where the custom distribution I was creating (it includes
cxf + camel + pax-web + undertow ...) was starting correctly (the
FeaturesService uses the resolver to install the features), but if I
restart Karaf, the wiring is wrong and one bundle (the cxf jms transport)
could not be resolved.
In this scenario, there's no real bug, as felix is not greedy and try to
resolve the bundles one by one.  If I had to actually use  this
distribution, one way to work around the problem would have been to try to
influence the order in which bundles are installed, as this has an effect
on the wiring.  The problem is that it needs manual tweaking and is very
tedious and non repeatable.

Anyway, I decided to solve the problem by making the wiring a bit more
"persistent".  What happens is that the features-extension bundle is
attached as a framework extension.  It listens for bundle resolution event
and save the wiring on the file system.  When karaf restarts, the extension
loads the wiring and waits for the system bundle started event.  At this
point, it installs a resolver hook, ask  for the resolution of all bundles,
guiding the resolution with its data. This is the same process that's
performed by the FeaturesService when installing a feature.
This actually solves the problem, as all bundles are resolved and come back
in the same state they were before.

The data is stored in the following folder:

Another side effect is that the startup is a bit faster, as the resolver
only has a single way to resolve the bundles, so no time is lost in
computing a correct solution.

I just wanted to give you a heads-up on this new mechanism...

Guillaume Nodet
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

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