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/
