karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: Karaf 4.0 : new behaviour of the feature resolver
Date Wed, 11 Feb 2015 19:10:49 GMT
To add a bit more, the osgi framework resolver takes into account
Required-Capabilities and Provide-Capabilities headers, but only for
requirements / capabilities that are effective at the "resolve" level, i.e.
the one used to actually "resolve" bundles.  Capabilities and requirements
that have an "active" level (ie. the services one mainly) are thus not
taken into account by the framework during the actual bundle resolution.

One possibility would be to add a flag to ignore those.  However, this
kinda have to be a global flag, as a resolution will resolve the whole
system, not only "new" features, so in the case at hand, if the feature
resolution fail once, it will cause any further resolution to fail.  So
once a feature has been installed, the flag has been set forever.

Note that there are other solutions:
  * do nothing and force the user to fix the bundle (or use wrap:xxx to fix
it on the fly)
  * capabilities / requirements can also be added to a feature as a whole,
so the service could be advertise on a dependant feature
  * provide a way to add fixed metadata to the system

2015-02-11 19:08 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com>:

> Hi,
> as Guillaume and I have been discussing this on IRC and we didn't come up
> with a real solution we decided to move this little "rambling" to the dev
> list.
> First of all please take a look at the issue KARAF-3520 [1]
> This issue leaves us with a strange situation I'd like to briefly describe:
> - Installation of a bundle with a require-capabilties header does work
> - Installation of a feature containig the same headers doesn't work
> Reason, the Feature Installer now does have a lifecycle and therefore
> checks the Meta-Information and doesn't find the required Capability even
> though the service is available and running.
> Ergo, it fails on installing the exact same bundle with the error which is
> in the issue. [1]
> According to Guillaume, this is intentional since the feature service needs
> to rely on the meta-information available from all bundles, that are going
> to be installed with the feature (including transitive features/bundles)
> and already installed features. BUT if one bundle doesn't contain those
> "meta-data" the feature install will fail because of the missing meta-data
> but not necessarily the "requested" capability isn't there.
> I fear this is a specialty of services at this point.
> The big Issue I currently see at this point, therefore this writing.
> The user experience will suffer tremendously because installations that did
> work before < Karaf 4
> will now break. The next big discrepancy people will see, if I install the
> bundle itself it works but not the features.
> Therefore we somehow need a solution that basically fits both needs, the
> user-experience and the management of transitive dependencies through the
> feature service. The way it is working right now, is a major breaking issue
> (yes Karaf 4 is a major release therefore we are safe).
> Especially with new bundles being build by the maven-bundle-plugin those
> require headers are generated more often.
> My first Impression had been to make sure that the feature service isn't as
> strict anymore.
> For example to verify that the Required Service isn't available through the
> meta-information verify it via the service registry.
> Guillaume mentioned to me on IRC that this isn't as easy as I imagined, due
> to the restrictions on the Resolver which is used from the framework. As
> benefit with the way the features resolving works right now, transitive
> dependencies which are declared as "dependency='true'" will be removed
> during the installation of another feature in case it's not needed any
> longer.
> So it boils down to, if one bundle declares a Required-Capabilities those
> need to be fullfilled by the means of Provide-Capabilities. Otherwise it
> doesn't install the feature.
> regards, Achim
> [1] - https://issues.apache.org/jira/browse/KARAF-3520
> --
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
> Software Architect / Project Manager / Scrum Master

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