You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Achim Nierbeck <bc...@googlemail.com> on 2015/02/11 19:08:12 UTC
Karaf 4.0 : new behaviour of the feature resolver
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
Re: Karaf 4.0 : new behaviour of the feature resolver
Posted by Guillaume Nodet <gn...@apache.org>.
2015-02-11 22:06 GMT+01:00 Fabian Lange <fa...@codecentric.de>:
> Hi Guillaume,
> your proposal is interesting but in the current case it would be
> confusing, because you would render it as a tree, right?
>
Well, not really a tree, more a list.
> the first two nodes of the tree say:
> the service is not there, and your bundle needs it.
>
The runtime state is only taken into account for bundles that are not part
of the resolution, i.e. the system bundle and any bundle that was not
installed using the feature service.
That's how you can verify at build time that your feature is valid. In
this case, the feature is not valid.
>
> Well yes, but I can install the bundle and the service is there and it
> works :-)
>
But if you would have used the feature verification goal in your build, it
would have failed before you could even try to install the feature ;-)
>
> So maybe the bundle install also needs stronger validation?
>
That's out of control of Karaf really.
The metadata is key to make sure an application can work correctly. The
resolution step ensures that everything will be available for the
application.
Having bad metadata for services is no different than not using versions on
packages and then crying because the resolver did install your bundles, but
at some point, you installed a conflicting bundle and it stopped working.
I think the correct way is to fix the metadata when it's wrong.
I can work on the fix I proposed earlier to ignore effective:="active"
requirements, but I'm not convinced it's a really good idea to lead users
into this way.
>
> Fabian
>
>
> On Wed, Feb 11, 2015 at 10:02 PM, Guillaume Nodet <gn...@apache.org>
> wrote:
> > 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 ...
>
Re: Karaf 4.0 : new behaviour of the feature resolver
Posted by Fabian Lange <fa...@codecentric.de>.
Hi Guillaume,
your proposal is interesting but in the current case it would be
confusing, because you would render it as a tree, right?
the first two nodes of the tree say:
the service is not there, and your bundle needs it.
Well yes, but I can install the bundle and the service is there and it works :-)
So maybe the bundle install also needs stronger validation?
Fabian
On Wed, Feb 11, 2015 at 10:02 PM, Guillaume Nodet <gn...@apache.org> wrote:
> 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 ...
Re: Karaf 4.0 : new behaviour of the feature resolver
Posted by Fabian Lange <fa...@codecentric.de>.
Hi,
sorry yeah, it was again a broken bundle.
I did not expect to find jetty and netty bundles to be broken ...
Have a nice weekend!
Fabian
On Fri, Feb 13, 2015 at 1:28 PM, Guillaume Nodet <gn...@apache.org> wrote:
> Well, no need to, I found the problem.
> Installing the bundle obviously works, but it does not start.
> The reason is that the error message is correct:
> [caused by: Unable to resolve io.netty.common/4.1.0.Beta4-SNAPSHOT: missing
> requirement [io.netty.common/4.1.0.Beta4-SNAPSHOT] osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.eclipse.jetty.alpn)(version>=1.0.0)(!(
> version>=2.0.0))(resolution=optional))"]]]]
>
> The resolution flag is a directive, not an attribute, so the bundle should
> have
> resolution:=optional
> instead of
> resolution=optional
>
> So everything's ok, it's just the bundle which is bad.
>
>
> 2015-02-13 13:17 GMT+01:00 Guillaume Nodet <gn...@apache.org>:
>
>> Could you raise a JIRA issue and attach the files needed to reproduce the
>> issue ?
>> I can have a quick look at it.
>>
>> 2015-02-13 12:48 GMT+01:00 Fabian Lange <fa...@codecentric.de>:
>>
>>> Hi all,
>>>
>>> i just stumbled on a most likely related issue.
>>>
>>> I have a my-feature which depends on
>>> mvn:io.netty/netty-common/4.1.0.Beta4-SNAPSHOT
>>>
>>> when I do feature:install my-feature
>>> it fails:
>>> [caused by: Unable to resolve io.netty.common/4.1.0.Beta4-SNAPSHOT:
>>> missing
>>> requirement [io.netty.common/4.1.0.Beta4-SNAPSHOT] osgi.wiring.package;
>>>
>>> filter:="(&(osgi.wiring.package=org.eclipse.jetty.alpn)(version>=1.0.0)(!(version>=2.0.0))(resolution=optional))"]]]]
>>>
>>> when I do bundle:install mvn:io.netty/netty-common/4.1.0.Beta4-SNAPSHOT
>>> it works just fine
>>>
>>> Note that the jetty.alpn is declared optional in the netty-common bundle.
>>>
>>> Fabian
>>>
>>>
>>>
>>> On Fri, Feb 13, 2015 at 8:49 AM, Guillaume Nodet <gn...@apache.org>
>>> wrote:
>>>
>>> > 2015-02-12 21:55 GMT+01:00 Guillaume Nodet <gn...@apache.org>:
>>> >
>>> > >
>>> > >
>>> > > 2015-02-12 19:56 GMT+01:00 Achim Nierbeck <bc...@googlemail.com>:
>>> > >
>>> > >> Hi,
>>> > >>
>>> > >> if it could be possible to add this feature back again, this clearly
>>> > would
>>> > >> help. (the -c option)
>>> > >>
>>> > >
>>> > > Well, it it's just about trying to install the bundles listed in a
>>> > feature
>>> > > and its dependencies, that could be done, but then you'll expect
>>> > everything
>>> > > to work, such as conditionals, configurations, etc... Now, features
>>> can
>>> > > also define capabilities and requirements, so while this is doable, we
>>> > need
>>> > > to clearly define which subset of things we would support in such a
>>> mode.
>>> > >
>>> > > Another better way would be to do it in a very different way. It may
>>> be
>>> > > possible to have a mode where the resolution would be done in a loop
>>> > while
>>> > > it succeeds. If it fails, we collect the missing requirement, add a
>>> > dummy
>>> > > capability to solve it, and run again, or something similar. We could
>>> > then
>>> > > print the missing requirements and install the bundles.
>>> > > There's already a simulatation mode which runs the resolution and
>>> prints
>>> > > the action that needs to be performed without actually modifying the
>>> > > framework, so that could be another mode. I don't foresee any
>>> technical
>>> > > impossibility here, so it may be worth a try if there's a consensus.
>>> > >
>>> >
>>> > Well, there's one problem though, and it's similar to adding a flag to
>>> not
>>> > take effective:="active" metadata into account. The next resolution
>>> will
>>> > fail the same way. One possibility could be to install the bundles into
>>> > "non managed" bundles, i.e. to not persist the fact that the feature was
>>> > required, so that the feature won't cause any problem during the next
>>> > resolution.
>>> >
>>> >
>>> > >
>>> > >
>>> > >> Another interesting fact here, the Require-Capability is only added
>>> for
>>> > >> bundles using DS by the maven-bundle-plugin.
>>> > >> Blueprint Bundles don't have it even though that could be generated
>>> > easily
>>> > >> from the reference-tag.
>>> > >>
>>> > >
>>> > > They are. You're either using an old maven plugin, or you have
>>> disabled
>>> > > the generation of the metadata.
>>> > >
>>> > >
>>> > >>
>>> > >> Regarding the feature validation goal, I doubt it would have shown
>>> that
>>> > >> the
>>> > >> pax-url-aether bundle was neglecting the providing capabilities
>>> manifest
>>> > >> entries. Though I need to verify that with a test-case.
>>> > >>
>>> > >
>>> > > No, you're right, it could not have figured the pax-url-aether bundle
>>> was
>>> > > wrong, because there's no way to know that a capability should have
>>> been
>>> > > provided. It's like if you forgot to export a package, no one could
>>> tell
>>> > > you.
>>> > > But it would have failed to validate the feature that was using it,
>>> i.e.
>>> > > the one you want to install and which currently fail.
>>> > >
>>> > >
>>> > >>
>>> > >> regards, Achim
>>> > >>
>>> > >>
>>> > >> 2015-02-12 0:39 GMT+01:00 Christian Schneider <
>>> chris@die-schneider.net
>>> > >:
>>> > >>
>>> > >> > Am 11.02.2015 um 22:02 schrieb Guillaume Nodet:
>>> > >> >
>>> > >> >> 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.
>>> > >> >>
>>> > >> >
>>> > >> > In most cases I like the verification. In some cases though
>>> especially
>>> > >> > when I build the deployment I sometimes want the bundles to be
>>> > installed
>>> > >> > even if they do not even resolve.
>>> > >> > The reason is that it is easier to debug what is wrong when the
>>> > bundles
>>> > >> > are in the system. So I would like to have an option to install
>>> even
>>> > if
>>> > >> the
>>> > >> > verification fails. Kind of like the option in karaf
>>> > >> > 2 and 3 where you leave the bundles installed in case of a failure.
>>> > >> >
>>> > >> > Doe that make sense?
>>> > >> >
>>> > >> > Christian
>>> > >> >
>>> > >> > --
>>> > >> > Christian Schneider
>>> > >> > http://www.liquid-reality.de
>>> > >> >
>>> > >> > Open Source Architect
>>> > >> > Talend Application Integration Division http://www.talend.com
>>> > >> >
>>> > >> >
>>> > >>
>>> > >>
>>> > >> --
>>> > >>
>>> > >> 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
>>> > >>
>>> > >
>>> > >
>>> >
>>>
>>
>>
Re: Karaf 4.0 : new behaviour of the feature resolver
Posted by Guillaume Nodet <gn...@apache.org>.
Well, no need to, I found the problem.
Installing the bundle obviously works, but it does not start.
The reason is that the error message is correct:
[caused by: Unable to resolve io.netty.common/4.1.0.Beta4-SNAPSHOT: missing
requirement [io.netty.common/4.1.0.Beta4-SNAPSHOT] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.eclipse.jetty.alpn)(version>=1.0.0)(!(
version>=2.0.0))(resolution=optional))"]]]]
The resolution flag is a directive, not an attribute, so the bundle should
have
resolution:=optional
instead of
resolution=optional
So everything's ok, it's just the bundle which is bad.
2015-02-13 13:17 GMT+01:00 Guillaume Nodet <gn...@apache.org>:
> Could you raise a JIRA issue and attach the files needed to reproduce the
> issue ?
> I can have a quick look at it.
>
> 2015-02-13 12:48 GMT+01:00 Fabian Lange <fa...@codecentric.de>:
>
>> Hi all,
>>
>> i just stumbled on a most likely related issue.
>>
>> I have a my-feature which depends on
>> mvn:io.netty/netty-common/4.1.0.Beta4-SNAPSHOT
>>
>> when I do feature:install my-feature
>> it fails:
>> [caused by: Unable to resolve io.netty.common/4.1.0.Beta4-SNAPSHOT:
>> missing
>> requirement [io.netty.common/4.1.0.Beta4-SNAPSHOT] osgi.wiring.package;
>>
>> filter:="(&(osgi.wiring.package=org.eclipse.jetty.alpn)(version>=1.0.0)(!(version>=2.0.0))(resolution=optional))"]]]]
>>
>> when I do bundle:install mvn:io.netty/netty-common/4.1.0.Beta4-SNAPSHOT
>> it works just fine
>>
>> Note that the jetty.alpn is declared optional in the netty-common bundle.
>>
>> Fabian
>>
>>
>>
>> On Fri, Feb 13, 2015 at 8:49 AM, Guillaume Nodet <gn...@apache.org>
>> wrote:
>>
>> > 2015-02-12 21:55 GMT+01:00 Guillaume Nodet <gn...@apache.org>:
>> >
>> > >
>> > >
>> > > 2015-02-12 19:56 GMT+01:00 Achim Nierbeck <bc...@googlemail.com>:
>> > >
>> > >> Hi,
>> > >>
>> > >> if it could be possible to add this feature back again, this clearly
>> > would
>> > >> help. (the -c option)
>> > >>
>> > >
>> > > Well, it it's just about trying to install the bundles listed in a
>> > feature
>> > > and its dependencies, that could be done, but then you'll expect
>> > everything
>> > > to work, such as conditionals, configurations, etc... Now, features
>> can
>> > > also define capabilities and requirements, so while this is doable, we
>> > need
>> > > to clearly define which subset of things we would support in such a
>> mode.
>> > >
>> > > Another better way would be to do it in a very different way. It may
>> be
>> > > possible to have a mode where the resolution would be done in a loop
>> > while
>> > > it succeeds. If it fails, we collect the missing requirement, add a
>> > dummy
>> > > capability to solve it, and run again, or something similar. We could
>> > then
>> > > print the missing requirements and install the bundles.
>> > > There's already a simulatation mode which runs the resolution and
>> prints
>> > > the action that needs to be performed without actually modifying the
>> > > framework, so that could be another mode. I don't foresee any
>> technical
>> > > impossibility here, so it may be worth a try if there's a consensus.
>> > >
>> >
>> > Well, there's one problem though, and it's similar to adding a flag to
>> not
>> > take effective:="active" metadata into account. The next resolution
>> will
>> > fail the same way. One possibility could be to install the bundles into
>> > "non managed" bundles, i.e. to not persist the fact that the feature was
>> > required, so that the feature won't cause any problem during the next
>> > resolution.
>> >
>> >
>> > >
>> > >
>> > >> Another interesting fact here, the Require-Capability is only added
>> for
>> > >> bundles using DS by the maven-bundle-plugin.
>> > >> Blueprint Bundles don't have it even though that could be generated
>> > easily
>> > >> from the reference-tag.
>> > >>
>> > >
>> > > They are. You're either using an old maven plugin, or you have
>> disabled
>> > > the generation of the metadata.
>> > >
>> > >
>> > >>
>> > >> Regarding the feature validation goal, I doubt it would have shown
>> that
>> > >> the
>> > >> pax-url-aether bundle was neglecting the providing capabilities
>> manifest
>> > >> entries. Though I need to verify that with a test-case.
>> > >>
>> > >
>> > > No, you're right, it could not have figured the pax-url-aether bundle
>> was
>> > > wrong, because there's no way to know that a capability should have
>> been
>> > > provided. It's like if you forgot to export a package, no one could
>> tell
>> > > you.
>> > > But it would have failed to validate the feature that was using it,
>> i.e.
>> > > the one you want to install and which currently fail.
>> > >
>> > >
>> > >>
>> > >> regards, Achim
>> > >>
>> > >>
>> > >> 2015-02-12 0:39 GMT+01:00 Christian Schneider <
>> chris@die-schneider.net
>> > >:
>> > >>
>> > >> > Am 11.02.2015 um 22:02 schrieb Guillaume Nodet:
>> > >> >
>> > >> >> 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.
>> > >> >>
>> > >> >
>> > >> > In most cases I like the verification. In some cases though
>> especially
>> > >> > when I build the deployment I sometimes want the bundles to be
>> > installed
>> > >> > even if they do not even resolve.
>> > >> > The reason is that it is easier to debug what is wrong when the
>> > bundles
>> > >> > are in the system. So I would like to have an option to install
>> even
>> > if
>> > >> the
>> > >> > verification fails. Kind of like the option in karaf
>> > >> > 2 and 3 where you leave the bundles installed in case of a failure.
>> > >> >
>> > >> > Doe that make sense?
>> > >> >
>> > >> > Christian
>> > >> >
>> > >> > --
>> > >> > Christian Schneider
>> > >> > http://www.liquid-reality.de
>> > >> >
>> > >> > Open Source Architect
>> > >> > Talend Application Integration Division http://www.talend.com
>> > >> >
>> > >> >
>> > >>
>> > >>
>> > >> --
>> > >>
>> > >> 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
>> > >>
>> > >
>> > >
>> >
>>
>
>
Re: Karaf 4.0 : new behaviour of the feature resolver
Posted by Guillaume Nodet <gn...@apache.org>.
Could you raise a JIRA issue and attach the files needed to reproduce the
issue ?
I can have a quick look at it.
2015-02-13 12:48 GMT+01:00 Fabian Lange <fa...@codecentric.de>:
> Hi all,
>
> i just stumbled on a most likely related issue.
>
> I have a my-feature which depends on
> mvn:io.netty/netty-common/4.1.0.Beta4-SNAPSHOT
>
> when I do feature:install my-feature
> it fails:
> [caused by: Unable to resolve io.netty.common/4.1.0.Beta4-SNAPSHOT: missing
> requirement [io.netty.common/4.1.0.Beta4-SNAPSHOT] osgi.wiring.package;
>
> filter:="(&(osgi.wiring.package=org.eclipse.jetty.alpn)(version>=1.0.0)(!(version>=2.0.0))(resolution=optional))"]]]]
>
> when I do bundle:install mvn:io.netty/netty-common/4.1.0.Beta4-SNAPSHOT
> it works just fine
>
> Note that the jetty.alpn is declared optional in the netty-common bundle.
>
> Fabian
>
>
>
> On Fri, Feb 13, 2015 at 8:49 AM, Guillaume Nodet <gn...@apache.org>
> wrote:
>
> > 2015-02-12 21:55 GMT+01:00 Guillaume Nodet <gn...@apache.org>:
> >
> > >
> > >
> > > 2015-02-12 19:56 GMT+01:00 Achim Nierbeck <bc...@googlemail.com>:
> > >
> > >> Hi,
> > >>
> > >> if it could be possible to add this feature back again, this clearly
> > would
> > >> help. (the -c option)
> > >>
> > >
> > > Well, it it's just about trying to install the bundles listed in a
> > feature
> > > and its dependencies, that could be done, but then you'll expect
> > everything
> > > to work, such as conditionals, configurations, etc... Now, features
> can
> > > also define capabilities and requirements, so while this is doable, we
> > need
> > > to clearly define which subset of things we would support in such a
> mode.
> > >
> > > Another better way would be to do it in a very different way. It may
> be
> > > possible to have a mode where the resolution would be done in a loop
> > while
> > > it succeeds. If it fails, we collect the missing requirement, add a
> > dummy
> > > capability to solve it, and run again, or something similar. We could
> > then
> > > print the missing requirements and install the bundles.
> > > There's already a simulatation mode which runs the resolution and
> prints
> > > the action that needs to be performed without actually modifying the
> > > framework, so that could be another mode. I don't foresee any
> technical
> > > impossibility here, so it may be worth a try if there's a consensus.
> > >
> >
> > Well, there's one problem though, and it's similar to adding a flag to
> not
> > take effective:="active" metadata into account. The next resolution will
> > fail the same way. One possibility could be to install the bundles into
> > "non managed" bundles, i.e. to not persist the fact that the feature was
> > required, so that the feature won't cause any problem during the next
> > resolution.
> >
> >
> > >
> > >
> > >> Another interesting fact here, the Require-Capability is only added
> for
> > >> bundles using DS by the maven-bundle-plugin.
> > >> Blueprint Bundles don't have it even though that could be generated
> > easily
> > >> from the reference-tag.
> > >>
> > >
> > > They are. You're either using an old maven plugin, or you have
> disabled
> > > the generation of the metadata.
> > >
> > >
> > >>
> > >> Regarding the feature validation goal, I doubt it would have shown
> that
> > >> the
> > >> pax-url-aether bundle was neglecting the providing capabilities
> manifest
> > >> entries. Though I need to verify that with a test-case.
> > >>
> > >
> > > No, you're right, it could not have figured the pax-url-aether bundle
> was
> > > wrong, because there's no way to know that a capability should have
> been
> > > provided. It's like if you forgot to export a package, no one could
> tell
> > > you.
> > > But it would have failed to validate the feature that was using it,
> i.e.
> > > the one you want to install and which currently fail.
> > >
> > >
> > >>
> > >> regards, Achim
> > >>
> > >>
> > >> 2015-02-12 0:39 GMT+01:00 Christian Schneider <
> chris@die-schneider.net
> > >:
> > >>
> > >> > Am 11.02.2015 um 22:02 schrieb Guillaume Nodet:
> > >> >
> > >> >> 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.
> > >> >>
> > >> >
> > >> > In most cases I like the verification. In some cases though
> especially
> > >> > when I build the deployment I sometimes want the bundles to be
> > installed
> > >> > even if they do not even resolve.
> > >> > The reason is that it is easier to debug what is wrong when the
> > bundles
> > >> > are in the system. So I would like to have an option to install even
> > if
> > >> the
> > >> > verification fails. Kind of like the option in karaf
> > >> > 2 and 3 where you leave the bundles installed in case of a failure.
> > >> >
> > >> > Doe that make sense?
> > >> >
> > >> > Christian
> > >> >
> > >> > --
> > >> > Christian Schneider
> > >> > http://www.liquid-reality.de
> > >> >
> > >> > Open Source Architect
> > >> > Talend Application Integration Division http://www.talend.com
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >>
> > >> 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
> > >>
> > >
> > >
> >
>
Re: Karaf 4.0 : new behaviour of the feature resolver
Posted by Fabian Lange <fa...@codecentric.de>.
Hi all,
i just stumbled on a most likely related issue.
I have a my-feature which depends on
mvn:io.netty/netty-common/4.1.0.Beta4-SNAPSHOT
when I do feature:install my-feature
it fails:
[caused by: Unable to resolve io.netty.common/4.1.0.Beta4-SNAPSHOT: missing
requirement [io.netty.common/4.1.0.Beta4-SNAPSHOT] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.eclipse.jetty.alpn)(version>=1.0.0)(!(version>=2.0.0))(resolution=optional))"]]]]
when I do bundle:install mvn:io.netty/netty-common/4.1.0.Beta4-SNAPSHOT
it works just fine
Note that the jetty.alpn is declared optional in the netty-common bundle.
Fabian
On Fri, Feb 13, 2015 at 8:49 AM, Guillaume Nodet <gn...@apache.org> wrote:
> 2015-02-12 21:55 GMT+01:00 Guillaume Nodet <gn...@apache.org>:
>
> >
> >
> > 2015-02-12 19:56 GMT+01:00 Achim Nierbeck <bc...@googlemail.com>:
> >
> >> Hi,
> >>
> >> if it could be possible to add this feature back again, this clearly
> would
> >> help. (the -c option)
> >>
> >
> > Well, it it's just about trying to install the bundles listed in a
> feature
> > and its dependencies, that could be done, but then you'll expect
> everything
> > to work, such as conditionals, configurations, etc... Now, features can
> > also define capabilities and requirements, so while this is doable, we
> need
> > to clearly define which subset of things we would support in such a mode.
> >
> > Another better way would be to do it in a very different way. It may be
> > possible to have a mode where the resolution would be done in a loop
> while
> > it succeeds. If it fails, we collect the missing requirement, add a
> dummy
> > capability to solve it, and run again, or something similar. We could
> then
> > print the missing requirements and install the bundles.
> > There's already a simulatation mode which runs the resolution and prints
> > the action that needs to be performed without actually modifying the
> > framework, so that could be another mode. I don't foresee any technical
> > impossibility here, so it may be worth a try if there's a consensus.
> >
>
> Well, there's one problem though, and it's similar to adding a flag to not
> take effective:="active" metadata into account. The next resolution will
> fail the same way. One possibility could be to install the bundles into
> "non managed" bundles, i.e. to not persist the fact that the feature was
> required, so that the feature won't cause any problem during the next
> resolution.
>
>
> >
> >
> >> Another interesting fact here, the Require-Capability is only added for
> >> bundles using DS by the maven-bundle-plugin.
> >> Blueprint Bundles don't have it even though that could be generated
> easily
> >> from the reference-tag.
> >>
> >
> > They are. You're either using an old maven plugin, or you have disabled
> > the generation of the metadata.
> >
> >
> >>
> >> Regarding the feature validation goal, I doubt it would have shown that
> >> the
> >> pax-url-aether bundle was neglecting the providing capabilities manifest
> >> entries. Though I need to verify that with a test-case.
> >>
> >
> > No, you're right, it could not have figured the pax-url-aether bundle was
> > wrong, because there's no way to know that a capability should have been
> > provided. It's like if you forgot to export a package, no one could tell
> > you.
> > But it would have failed to validate the feature that was using it, i.e.
> > the one you want to install and which currently fail.
> >
> >
> >>
> >> regards, Achim
> >>
> >>
> >> 2015-02-12 0:39 GMT+01:00 Christian Schneider <chris@die-schneider.net
> >:
> >>
> >> > Am 11.02.2015 um 22:02 schrieb Guillaume Nodet:
> >> >
> >> >> 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.
> >> >>
> >> >
> >> > In most cases I like the verification. In some cases though especially
> >> > when I build the deployment I sometimes want the bundles to be
> installed
> >> > even if they do not even resolve.
> >> > The reason is that it is easier to debug what is wrong when the
> bundles
> >> > are in the system. So I would like to have an option to install even
> if
> >> the
> >> > verification fails. Kind of like the option in karaf
> >> > 2 and 3 where you leave the bundles installed in case of a failure.
> >> >
> >> > Doe that make sense?
> >> >
> >> > Christian
> >> >
> >> > --
> >> > Christian Schneider
> >> > http://www.liquid-reality.de
> >> >
> >> > Open Source Architect
> >> > Talend Application Integration Division http://www.talend.com
> >> >
> >> >
> >>
> >>
> >> --
> >>
> >> 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
> >>
> >
> >
>
Re: Karaf 4.0 : new behaviour of the feature resolver
Posted by Guillaume Nodet <gn...@apache.org>.
2015-02-12 21:55 GMT+01:00 Guillaume Nodet <gn...@apache.org>:
>
>
> 2015-02-12 19:56 GMT+01:00 Achim Nierbeck <bc...@googlemail.com>:
>
>> Hi,
>>
>> if it could be possible to add this feature back again, this clearly would
>> help. (the -c option)
>>
>
> Well, it it's just about trying to install the bundles listed in a feature
> and its dependencies, that could be done, but then you'll expect everything
> to work, such as conditionals, configurations, etc... Now, features can
> also define capabilities and requirements, so while this is doable, we need
> to clearly define which subset of things we would support in such a mode.
>
> Another better way would be to do it in a very different way. It may be
> possible to have a mode where the resolution would be done in a loop while
> it succeeds. If it fails, we collect the missing requirement, add a dummy
> capability to solve it, and run again, or something similar. We could then
> print the missing requirements and install the bundles.
> There's already a simulatation mode which runs the resolution and prints
> the action that needs to be performed without actually modifying the
> framework, so that could be another mode. I don't foresee any technical
> impossibility here, so it may be worth a try if there's a consensus.
>
Well, there's one problem though, and it's similar to adding a flag to not
take effective:="active" metadata into account. The next resolution will
fail the same way. One possibility could be to install the bundles into
"non managed" bundles, i.e. to not persist the fact that the feature was
required, so that the feature won't cause any problem during the next
resolution.
>
>
>> Another interesting fact here, the Require-Capability is only added for
>> bundles using DS by the maven-bundle-plugin.
>> Blueprint Bundles don't have it even though that could be generated easily
>> from the reference-tag.
>>
>
> They are. You're either using an old maven plugin, or you have disabled
> the generation of the metadata.
>
>
>>
>> Regarding the feature validation goal, I doubt it would have shown that
>> the
>> pax-url-aether bundle was neglecting the providing capabilities manifest
>> entries. Though I need to verify that with a test-case.
>>
>
> No, you're right, it could not have figured the pax-url-aether bundle was
> wrong, because there's no way to know that a capability should have been
> provided. It's like if you forgot to export a package, no one could tell
> you.
> But it would have failed to validate the feature that was using it, i.e.
> the one you want to install and which currently fail.
>
>
>>
>> regards, Achim
>>
>>
>> 2015-02-12 0:39 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>>
>> > Am 11.02.2015 um 22:02 schrieb Guillaume Nodet:
>> >
>> >> 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.
>> >>
>> >
>> > In most cases I like the verification. In some cases though especially
>> > when I build the deployment I sometimes want the bundles to be installed
>> > even if they do not even resolve.
>> > The reason is that it is easier to debug what is wrong when the bundles
>> > are in the system. So I would like to have an option to install even if
>> the
>> > verification fails. Kind of like the option in karaf
>> > 2 and 3 where you leave the bundles installed in case of a failure.
>> >
>> > Doe that make sense?
>> >
>> > Christian
>> >
>> > --
>> > Christian Schneider
>> > http://www.liquid-reality.de
>> >
>> > Open Source Architect
>> > Talend Application Integration Division http://www.talend.com
>> >
>> >
>>
>>
>> --
>>
>> 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
>>
>
>
Re: Karaf 4.0 : new behaviour of the feature resolver
Posted by Guillaume Nodet <gn...@apache.org>.
2015-02-12 19:56 GMT+01:00 Achim Nierbeck <bc...@googlemail.com>:
> Hi,
>
> if it could be possible to add this feature back again, this clearly would
> help. (the -c option)
>
Well, it it's just about trying to install the bundles listed in a feature
and its dependencies, that could be done, but then you'll expect everything
to work, such as conditionals, configurations, etc... Now, features can
also define capabilities and requirements, so while this is doable, we need
to clearly define which subset of things we would support in such a mode.
Another better way would be to do it in a very different way. It may be
possible to have a mode where the resolution would be done in a loop while
it succeeds. If it fails, we collect the missing requirement, add a dummy
capability to solve it, and run again, or something similar. We could then
print the missing requirements and install the bundles.
There's already a simulatation mode which runs the resolution and prints
the action that needs to be performed without actually modifying the
framework, so that could be another mode. I don't foresee any technical
impossibility here, so it may be worth a try if there's a consensus.
> Another interesting fact here, the Require-Capability is only added for
> bundles using DS by the maven-bundle-plugin.
> Blueprint Bundles don't have it even though that could be generated easily
> from the reference-tag.
>
They are. You're either using an old maven plugin, or you have disabled
the generation of the metadata.
>
> Regarding the feature validation goal, I doubt it would have shown that the
> pax-url-aether bundle was neglecting the providing capabilities manifest
> entries. Though I need to verify that with a test-case.
>
No, you're right, it could not have figured the pax-url-aether bundle was
wrong, because there's no way to know that a capability should have been
provided. It's like if you forgot to export a package, no one could tell
you.
But it would have failed to validate the feature that was using it, i.e.
the one you want to install and which currently fail.
>
> regards, Achim
>
>
> 2015-02-12 0:39 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>
> > Am 11.02.2015 um 22:02 schrieb Guillaume Nodet:
> >
> >> 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.
> >>
> >
> > In most cases I like the verification. In some cases though especially
> > when I build the deployment I sometimes want the bundles to be installed
> > even if they do not even resolve.
> > The reason is that it is easier to debug what is wrong when the bundles
> > are in the system. So I would like to have an option to install even if
> the
> > verification fails. Kind of like the option in karaf
> > 2 and 3 where you leave the bundles installed in case of a failure.
> >
> > Doe that make sense?
> >
> > Christian
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > Talend Application Integration Division http://www.talend.com
> >
> >
>
>
> --
>
> 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
>
Re: Karaf 4.0 : new behaviour of the feature resolver
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
if it could be possible to add this feature back again, this clearly would
help. (the -c option)
Another interesting fact here, the Require-Capability is only added for
bundles using DS by the maven-bundle-plugin.
Blueprint Bundles don't have it even though that could be generated easily
from the reference-tag.
Regarding the feature validation goal, I doubt it would have shown that the
pax-url-aether bundle was neglecting the providing capabilities manifest
entries. Though I need to verify that with a test-case.
regards, Achim
2015-02-12 0:39 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
> Am 11.02.2015 um 22:02 schrieb Guillaume Nodet:
>
>> 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.
>>
>
> In most cases I like the verification. In some cases though especially
> when I build the deployment I sometimes want the bundles to be installed
> even if they do not even resolve.
> The reason is that it is easier to debug what is wrong when the bundles
> are in the system. So I would like to have an option to install even if the
> verification fails. Kind of like the option in karaf
> 2 and 3 where you leave the bundles installed in case of a failure.
>
> Doe that make sense?
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
--
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
Re: Karaf 4.0 : new behaviour of the feature resolver
Posted by Christian Schneider <ch...@die-schneider.net>.
Am 11.02.2015 um 22:02 schrieb Guillaume Nodet:
> 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.
In most cases I like the verification. In some cases though especially
when I build the deployment I sometimes want the bundles to be installed
even if they do not even resolve.
The reason is that it is easier to debug what is wrong when the bundles
are in the system. So I would like to have an option to install even if
the verification fails. Kind of like the option in karaf
2 and 3 where you leave the bundles installed in case of a failure.
Doe that make sense?
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Karaf 4.0 : new behaviour of the feature resolver
Posted by Guillaume Nodet <gn...@apache.org>.
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 <fa...@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 <gn...@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 <bc...@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
> > >
>
Re: Karaf 4.0 : new behaviour of the feature resolver
Posted by Fabian Lange <fa...@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 <gn...@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 <bc...@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
> >
Re: Karaf 4.0 : new behaviour of the feature resolver
Posted by Guillaume Nodet <gn...@apache.org>.
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 <bc...@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
>