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 21:02:06 GMT
The breaking change is that features are now verified before being
installed.
In karaf < 4, there was no verification step, and the installation of the
feature was simply trying to install the bundles and start those.

If a bundle provides something but does not say so, it forbids any user to
actually use that.  For a package, if the package is not exported, no
bundle will be able to use it.
The difference is that the resolver does not use effective:="active"
requirements / capabilities into account.
However, if the bundles metadata was correct (which is not the case because
the pax-url one does not advertise the service), it would have lead to a
failure of the application as a whole, even if the bundles could be
installed and resolved.

That's why I'm not sure we should get rid of the service dependencies, as
it adds another level of verification for composing applications in OSGi.

On the diagnosis of the error, I'm now quite used to decrypt capabilities /
requirements. I suppose the ResolutionException message could be displayed
in a better way.  It currently indicates the path down to the requirement,
it may be easier to understand it the other way around:
- a service of class org.ops4j.pax.url.mvn.MavenResolver can not be found
  - which is required by bundle mybundle/1.0.0.SNAPSHOT
  - which is required by feature mybundle/1.0.0.SNAPSHOT
I suppose the error display could be improved ...


org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity; osgi.identity=mybundle;
type=karaf.feature; version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]";
filter:="(&(osgi.identity=mybundle)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))"
[caused by: Unable to resolve mybundle/1.0.0.SNAPSHOT: missing
requirement [mybundle/1.0.0.SNAPSHOT] osgi.identity;
osgi.identity=com.my.package; type=osgi.bundle;
version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; resolution:=mandatory
[caused by: Unable to resolve com.my.package/1.0.0.SNAPSHOT: missing
requirement [com.my.package/1.0.0.SNAPSHOT] osgi.service;
effective:=active;
filter:="(objectClass=org.ops4j.pax.url.mvn.MavenResolver)"]]




2015-02-11 21:32 GMT+01:00 Fabian Lange <fabian.lange@codecentric.de>:

> Hi,
> as I have found the issue, I want to just state what my expectation as
> naive developer are.
> I have a bundle in which I want to reuse the great
> org.ops4j.pax.url.mvn.MavenResolver.
>
> I checked my minimal installation and saw the service comes out of the
> box. I did not care, but I also was not able to find out who this
> service actually provides.
>
> I added a provided maven dependency and used it. I installed the
> bundle and it worked.
> But for packaging, I included my bundle in a feature and then it
> stopped working.
>
> I called Achim (who lightheaded agreed to help me out when I have
> troubles :-)) and he tried to debug this.
> Even with his in depth knowledge it took us a while to figure out (and
> subsequently also discuss in irc) that the bundle installation does a
> different thing than the feature installation.
>
> I still have not fully understood where this should be fixed. I
> understand that pax.url.mvn needs to declare this as provided, but
> right now it works for other framework services, because they come out
> of the box and nobody does the feature validation. And it just works
> because the service exists.
>
> As a naive dev, I find this very much confusing. I cannot judge if
> this is really a breaking change (which i could imagine), but it might
> affect more "system"/"framework" services, which I would love to
> re-use.
>
> Fabian
>
> On Wed, Feb 11, 2015 at 8:10 PM, Guillaume Nodet <gnodet@apache.org>
> wrote:
> >
> > 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
> > >
>

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