Yes, that's because equinox does store the wiring persistently, so once the FeaturesService has applied its own wiring, rebooting is safe. This is mostly a problem for felix, I agree.
2016-10-05 14:03 GMT+02:00 Jamie G. <[email protected]>: > Thank you Guillaume for the heads up - I've seen similar issue crop up > in OpenDaylight, luckily using Equinox as the core seemed to resolve > their issue in most cases. > > --J > > On Wed, Oct 5, 2016 at 2:31 AM, Guillaume Nodet <[email protected]> wrote: > > 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: > > data/cache/bundle0/wiring > > > > 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: [email protected] > > Web: http://fusesource.com > > Blog: http://gnodet.blogspot.com/ > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
