Friday, June 26, 2015
Almost 3 years since I haven't blogged, so I'm using the fact that the Karaf 4.0 release in under vote to start again.
Karaf 4.0 brings a lot of new features, but one of the most important one is the new features service. It is originally a port of the Fuse/Fabric agent resolver to Karaf 4, but has since been extended a lot (and has actually been integrated back into Fuse 6.2).
This new features services is used to install well known features, but even if it reuses the same features xml definition, it's not limited to those anymore and works in a very different way. The main difference is that the original features service (in Karaf 2.x and 3.x) is quite blind when it comes to installing features. When a user asks for a feature installation, the process was quite simplistic: the service mainly goes through the list of bundles listed in the feature and install them. The introduction of the resolver flag brought some intelligence to the process, as the old and deprecated OBR library was used to compute which bundles were actually needed. The goal was to be smarter and not install bundles if they were not needed.
However, OBR was quite limited, and the output of OBR could theorically not be supported by the OSGi framework, or at least, not give the expected results.
The new resolver reuses the OSGi resolver, the exact same one that is used by the OSGi framework. It also reuses the same metadata extracted from the bundle headers. The new OSGi resolver is really generic and supports any kind of requirements and capabilities, even though it contains specific rules for known kind of constraints.
The new features service uses this resolver, by translating feature definitions into resoures with their requirements and capabilities, including bundles, but also conditionals, feature dependencies, etc... Once the modelling is done, the service asks the resolver for an output, and brings the framework into the desired state by installing, uninstalling, updating bundles as needed.
This is major change, even though the end-user does not always see it immediately. The features service maintains a set of requirements (usually requirement on features), and the resolution will always satisfy those requirements. This means that the installation of a feature can not fail previously installed features, nor can it installs a feature that can't be resolved.
There are lots of new stuff coming with this new features service, and I'll try to cover some of them over the next weeks.