You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Benson Margulies <be...@basistech.com> on 2016/08/31 12:31:45 UTC
What does effective:=active mean?
I just tried the experiment of moving our platform from 4.0.4 to
4.0.6, changing nothing but the karaf version. I received in return a
resolution error that I've never seen the like of before, complaining
that a particular service is missing with 'effective:=active'.
Since Karaf does not come to command level when this sort of thing
goes wrong, it is not obvious to me how to gain any insight into what
is wrong. The service reference itself is very strange;
'RosetteBundleWarmup' a DS reference like:
@Reference(target = "(component-name=name-matching)")
public void setWarmup(RosetteBundleWarmup warmup) {
this.componentWarmup = warmup;
}
and I don't see the component-name filter in the error message. It's
also new to me that DS @Reference is even visible to resolution at the
time that boot features are being resolved.
2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1 |
BootFeaturesInstaller | 6 - org.apache.karaf.features.core
- 4.0.6 | Error installing boot features
org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity;
osgi.identity=rosapi-all-sdks; type=karaf.feature;
version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
[caused by: Unable to resolve rosapi-all-sdks/1.2.6.SNAPSHOT: missing
requirement [rosapi-all-sdks/1.2.6.SNAPSHOT] osgi.identity;
osgi.identity=rosapi-worker-rni-rnt-sdk; type=karaf.feature [caused
by: Unable to resolve rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
missing requirement [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
osgi.identity; osgi.identity=com.basistech.ws.rosapi-worker-rni-rnt-sdk;
type=osgi.bundle;
version="[1.2.6.v20160831122227,1.2.6.v20160831122227]";
resolution:=mandatory [caused by: Unable to resolve
com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227:
missing requirement
[com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227]
osgi.service; filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
effective:=active]]]
Re: What does effective:=active mean?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Markus,
yes, correct, copy-paste mistake ;)
Regards
JB
On 08/31/2016 04:28 PM, Markus Rathgeb wrote:
> Hi,
>
>> <Provide-Capability>
>> osgi.service;effective:=active;objectClass=myService
>> </Provide-Capability>
>
> IIRC have never seen "effective:=active" in the Provide-Capability section.
> I only know about in the Require-Capability.
>
> Are you sure this is required?
> At least it works if it is missing for "provide".
>
> Best regard,
> Markus
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: What does effective:=active mean?
Posted by Markus Rathgeb <ma...@gmail.com>.
Hi,
> <Provide-Capability>
> osgi.service;effective:=active;objectClass=myService
> </Provide-Capability>
IIRC have never seen "effective:=active" in the Provide-Capability section.
I only know about in the Require-Capability.
Are you sure this is required?
At least it works if it is missing for "provide".
Best regard,
Markus
Re: What does effective:=active mean?
Posted by Guillaume Nodet <gn...@apache.org>.
Btw, if that's not sufficient, i.e. if some people have a need for
disabling only specific feature, please raise a JIRA and I can add the
flag on the repository / feature definition for 4.1.
Guillaume
2016-08-31 16:14 GMT+02:00 Guillaume Nodet <gn...@apache.org>:
> You can always disable service requirements globally by setting
> serviceRequirements = disable
> in the etc/org.apache.karaf.features.cfg config file.
>
>
> 2016-08-31 15:34 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>
>> Hi Benson,
>>
>> I agree: we had a long discussion with Guillaume about that in the past ;)
>>
>> As a workaround, you can use the feature capability definition (and it
>> can be done at runtime using feature:* commands). So your DS components
>> don't have to change.
>>
>> Regards
>> JB
>>
>>
>> On 08/31/2016 03:30 PM, Benson Margulies wrote:
>>
>>> Gentlemen,
>>>
>>> Thank you very much for the help. I want to offer a small argument for
>>> an option to turn all this off in a CFG file, before I get to work
>>> using the solutions you've offered.
>>>
>>> One of the virtues of DS is that you can mix-and-match: a DS component
>>> can transparently use non-DS services. This resolver feature disables
>>> that nice transparency by requiring any service used in a DS component
>>> to be accounted for in a Provide-Capability. So you might accept the
>>> proposition that this resolver enforcement is not so good for
>>> everyone.
>>>
>>> --benson
>>>
>>>
>>>
>>>
>>> On Wed, Aug 31, 2016 at 6:13 AM, Guillaume Nodet <gn...@apache.org>
>>> wrote:
>>>
>>>>
>>>>
>>>> 2016-08-31 15:00 GMT+02:00 Benson Margulies <be...@basistech.com>:
>>>>
>>>>>
>>>>> On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré <jb@nanthrax.net
>>>>> >
>>>>> wrote:
>>>>>
>>>>>> So, I will explain a new time (for the third time ;)).
>>>>>>
>>>>>
>>>>> JB,
>>>>>
>>>>> I apologize for not being awake when this came through before.
>>>>>
>>>>> I just want to make sure that I am completely following this. The
>>>>> resolver is requiring that some bundle mentions the service in a
>>>>> Provide-Capability -- NOT that the service is actually running?
>>>>>
>>>>
>>>>
>>>> The resolver looks at the bundle manifest. It runs before they are
>>>> installed
>>>> / started, so it can't really look at if they are running or not.
>>>>
>>>>
>>>>>
>>>>> The service in question is provided by an 'old' OSGi bundle that does
>>>>> not bother to do a Provide-Capability for it; it's not a service, just
>>>>> a service launched the old-fashioned way.
>>>>>
>>>>> Is there some thread you can point me to that offers suggestions for
>>>>> dealing with this? I would rather not have to go add
>>>>> Provide-Capability manifest entries for all my dynamically created
>>>>> OSGi services. Is there an option in a cfg file or a feature.xml that
>>>>> turns this back off?
>>>>>
>>>>
>>>>
>>>> This could be done for karaf 4.1 with a new xsd.
>>>>
>>>>
>>>>>
>>>>> Perhaps I can persuade BND not to list them as requirements.
>>>>>
>>>>
>>>>
>>>> Yeah, that's definitely the easiest way, you can easily remove the
>>>> Require-Capability header, or disable the service requirements,
>>>> depending on
>>>> how they are generated.
>>>>
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> benson
>>>>>
>>>>>
>>>>>
>>>>>> When you are using features XML with namespace 1.3 or 1.4, the feature
>>>>>> resolver uses the service enforcement. It means that it checks the
>>>>>> service
>>>>>> capability in the bundles. The service requirement is basically a
>>>>>> bundle
>>>>>> that needs a service "A" at runtime. So the resolver will check the
>>>>>> features
>>>>>> containing the bundle providing such capability (exposing the
>>>>>> service).
>>>>>> It's
>>>>>> what the effective:=active mean.
>>>>>>
>>>>>> The corresponding MANIFEST header is:
>>>>>>
>>>>>> <Provide-Capability>
>>>>>> osgi.service;effective:=active;objectClass=myService
>>>>>> </Provide-Capability>
>>>>>>
>>>>>> On the other hand, the requirement header looks like:
>>>>>>
>>>>>> <Require-Capability>
>>>>>> osgi.service;effective:=active;filter:="(objectClass=aService)"
>>>>>> </Require-Capability>
>>>>>>
>>>>>>
>>>>>> Unfortunately, in Karaf 4.0.3, 4.0.4, 4.0.5, the service enforcement
>>>>>> was
>>>>>> enabled for features xmlns 1.3.0 NOT for 1.4.0 (it was a bug). This
>>>>>> bug
>>>>>> has
>>>>>> been fixed in Karaf 4.0.6. That's why when you upgraded from 4.0.4 to
>>>>>> 4.0.6,
>>>>>> the feature resolver is now "active" for your features XML and check
>>>>>> the
>>>>>> service enforcement.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>
>>>>>> On 08/31/2016 02:31 PM, Benson Margulies wrote:
>>>>>>
>>>>>>>
>>>>>>> I just tried the experiment of moving our platform from 4.0.4 to
>>>>>>> 4.0.6, changing nothing but the karaf version. I received in return a
>>>>>>> resolution error that I've never seen the like of before, complaining
>>>>>>> that a particular service is missing with 'effective:=active'.
>>>>>>>
>>>>>>> Since Karaf does not come to command level when this sort of thing
>>>>>>> goes wrong, it is not obvious to me how to gain any insight into what
>>>>>>> is wrong. The service reference itself is very strange;
>>>>>>> 'RosetteBundleWarmup' a DS reference like:
>>>>>>>
>>>>>>> @Reference(target = "(component-name=name-matching)")
>>>>>>> public void setWarmup(RosetteBundleWarmup warmup) {
>>>>>>> this.componentWarmup = warmup;
>>>>>>> }
>>>>>>>
>>>>>>> and I don't see the component-name filter in the error message. It's
>>>>>>> also new to me that DS @Reference is even visible to resolution at
>>>>>>> the
>>>>>>> time that boot features are being resolved.
>>>>>>>
>>>>>>>
>>>>>>> 2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1 |
>>>>>>> BootFeaturesInstaller | 6 - org.apache.karaf.features.core
>>>>>>> - 4.0.6 | Error installing boot features
>>>>>>> org.osgi.service.resolver.ResolutionException: Unable to resolve
>>>>>>> root:
>>>>>>> missing requirement [root] osgi.identity;
>>>>>>> osgi.identity=rosapi-all-sdks; type=karaf.feature;
>>>>>>> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
>>>>>>>
>>>>>>>
>>>>>>> filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.featur
>>>>>>> e)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
>>>>>>> [caused by: Unable to resolve rosapi-all-sdks/1.2.6.SNAPSHOT:
>>>>>>> missing
>>>>>>> requirement [rosapi-all-sdks/1.2.6.SNAPSHOT] osgi.identity;
>>>>>>> osgi.identity=rosapi-worker-rni-rnt-sdk; type=karaf.feature [caused
>>>>>>> by: Unable to resolve rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
>>>>>>> missing requirement [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
>>>>>>> osgi.identity;
>>>>>>> osgi.identity=com.basistech.ws.rosapi-worker-rni-rnt-sdk;
>>>>>>> type=osgi.bundle;
>>>>>>> version="[1.2.6.v20160831122227,1.2.6.v20160831122227]";
>>>>>>> resolution:=mandatory [caused by: Unable to resolve
>>>>>>> com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227:
>>>>>>> missing requirement
>>>>>>> [com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227]
>>>>>>> osgi.service;
>>>>>>> filter:="(objectClass=com.basistech.rosette.osgi.RosetteBund
>>>>>>> leWarmup)";
>>>>>>> effective:=active]]]
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Jean-Baptiste Onofré
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Red Hat, Open Source Integration
>>>>
>>>> Email: gnodet@redhat.com
>>>> Web: http://fusesource.com
>>>> Blog: http://gnodet.blogspot.com/
>>>>
>>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: What does effective:=active mean?
Posted by Benson Margulies <be...@basistech.com>.
THANK YOU ALL!
On Wed, Aug 31, 2016 at 7:15 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Yes, it's what we agreed for 4.0.0.
>
> Regards
> JB
>
> On 08/31/2016 04:14 PM, Guillaume Nodet wrote:
>>
>> You can always disable service requirements globally by setting
>> serviceRequirements = disable
>> in the etc/org.apache.karaf.features.cfg config file.
>>
>>
>> 2016-08-31 15:34 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>>:
>>
>>
>> Hi Benson,
>>
>> I agree: we had a long discussion with Guillaume about that in the
>> past ;)
>>
>> As a workaround, you can use the feature capability definition (and
>> it can be done at runtime using feature:* commands). So your DS
>> components don't have to change.
>>
>> Regards
>> JB
>>
>>
>> On 08/31/2016 03:30 PM, Benson Margulies wrote:
>>
>> Gentlemen,
>>
>> Thank you very much for the help. I want to offer a small
>> argument for
>> an option to turn all this off in a CFG file, before I get to work
>> using the solutions you've offered.
>>
>> One of the virtues of DS is that you can mix-and-match: a DS
>> component
>> can transparently use non-DS services. This resolver feature
>> disables
>> that nice transparency by requiring any service used in a DS
>> component
>> to be accounted for in a Provide-Capability. So you might accept
>> the
>> proposition that this resolver enforcement is not so good for
>> everyone.
>>
>> --benson
>>
>>
>>
>>
>> On Wed, Aug 31, 2016 at 6:13 AM, Guillaume Nodet
>> <gnodet@apache.org <ma...@apache.org>> wrote:
>>
>>
>>
>> 2016-08-31 15:00 GMT+02:00 Benson Margulies
>> <benson@basistech.com <ma...@basistech.com>>:
>>
>>
>> On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré
>> <jb@nanthrax.net <ma...@nanthrax.net>>
>>
>> wrote:
>>
>> So, I will explain a new time (for the third time ;)).
>>
>>
>> JB,
>>
>> I apologize for not being awake when this came through
>> before.
>>
>> I just want to make sure that I am completely following
>> this. The
>> resolver is requiring that some bundle mentions the
>> service in a
>> Provide-Capability -- NOT that the service is actually
>> running?
>>
>>
>>
>> The resolver looks at the bundle manifest. It runs before
>> they are installed
>> / started, so it can't really look at if they are running or
>> not.
>>
>>
>>
>> The service in question is provided by an 'old' OSGi
>> bundle that does
>> not bother to do a Provide-Capability for it; it's not a
>> service, just
>> a service launched the old-fashioned way.
>>
>> Is there some thread you can point me to that offers
>> suggestions for
>> dealing with this? I would rather not have to go add
>> Provide-Capability manifest entries for all my
>> dynamically created
>> OSGi services. Is there an option in a cfg file or a
>> feature.xml that
>> turns this back off?
>>
>>
>>
>> This could be done for karaf 4.1 with a new xsd.
>>
>>
>>
>> Perhaps I can persuade BND not to list them as
>> requirements.
>>
>>
>>
>> Yeah, that's definitely the easiest way, you can easily
>> remove the
>> Require-Capability header, or disable the service
>> requirements, depending on
>> how they are generated.
>>
>>
>>
>>
>> Thanks,
>> benson
>>
>>
>>
>> When you are using features XML with namespace 1.3
>> or 1.4, the feature
>> resolver uses the service enforcement. It means that
>> it checks the
>> service
>> capability in the bundles. The service requirement
>> is basically a bundle
>> that needs a service "A" at runtime. So the resolver
>> will check the
>> features
>> containing the bundle providing such capability
>> (exposing the service).
>> It's
>> what the effective:=active mean.
>>
>> The corresponding MANIFEST header is:
>>
>> <Provide-Capability>
>> osgi.service;effective:=active;objectClass=myService
>> </Provide-Capability>
>>
>> On the other hand, the requirement header looks like:
>>
>> <Require-Capability>
>>
>> osgi.service;effective:=active;filter:="(objectClass=aService)"
>> </Require-Capability>
>>
>>
>> Unfortunately, in Karaf 4.0.3, 4.0.4, 4.0.5, the
>> service enforcement was
>> enabled for features xmlns 1.3.0 NOT for 1.4.0 (it
>> was a bug). This bug
>> has
>> been fixed in Karaf 4.0.6. That's why when you
>> upgraded from 4.0.4 to
>> 4.0.6,
>> the feature resolver is now "active" for your
>> features XML and check the
>> service enforcement.
>>
>> Regards
>> JB
>>
>>
>> On 08/31/2016 02:31 PM, Benson Margulies wrote:
>>
>>
>> I just tried the experiment of moving our
>> platform from 4.0.4 to
>> 4.0.6, changing nothing but the karaf version. I
>> received in return a
>> resolution error that I've never seen the like
>> of before, complaining
>> that a particular service is missing with
>> 'effective:=active'.
>>
>> Since Karaf does not come to command level when
>> this sort of thing
>> goes wrong, it is not obvious to me how to gain
>> any insight into what
>> is wrong. The service reference itself is very
>> strange;
>> 'RosetteBundleWarmup' a DS reference like:
>>
>> @Reference(target =
>> "(component-name=name-matching)")
>> public void setWarmup(RosetteBundleWarmup warmup)
>> {
>> this.componentWarmup = warmup;
>> }
>>
>> and I don't see the component-name filter in the
>> error message. It's
>> also new to me that DS @Reference is even
>> visible to resolution at the
>> time that boot features are being resolved.
>>
>>
>> 2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1
>> |
>> BootFeaturesInstaller | 6 -
>> org.apache.karaf.features.core
>> - 4.0.6 | Error installing boot features
>> org.osgi.service.resolver.ResolutionException:
>> Unable to resolve root:
>> missing requirement [root] osgi.identity;
>> osgi.identity=rosapi-all-sdks; type=karaf.feature;
>> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
>>
>>
>>
>> filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
>> [caused by: Unable to resolve
>> rosapi-all-sdks/1.2.6. <http://1.2.6.>SNAPSHOT:
>> missing
>> requirement [rosapi-all-sdks/1.2.6.
>> <http://1.2.6.>SNAPSHOT] osgi.identity;
>> osgi.identity=rosapi-worker-rni-rnt-sdk;
>> type=karaf.feature [caused
>> by: Unable to resolve
>> rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
>> missing requirement
>> [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
>> osgi.identity;
>> osgi.identity=com.basistech.ws
>>
>> <http://com.basistech.ws>.rosapi-worker-rni-rnt-sdk;
>> type=osgi.bundle;
>>
>> version="[1.2.6.v20160831122227,1.2.6.v20160831122227]";
>> resolution:=mandatory [caused by: Unable to
>> resolve
>> com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.
>> <http://1.2.6.>v20160831122227:
>> missing requirement
>> [com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.
>> <http://1.2.6.>v20160831122227]
>> osgi.service;
>>
>> filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
>> effective:=active]]]
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Red Hat, Open Source Integration
>>
>> Email: gnodet@redhat.com <ma...@redhat.com>
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Red Hat, Open Source Integration
>>
>> Email: gnodet@redhat.com <ma...@redhat.com>
>> Web: http://fusesource.com <http://fusesource.com/>
>> Blog: http://gnodet.blogspot.com/
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: What does effective:=active mean?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yes, it's what we agreed for 4.0.0.
Regards
JB
On 08/31/2016 04:14 PM, Guillaume Nodet wrote:
> You can always disable service requirements globally by setting
> serviceRequirements = disable
> in the etc/org.apache.karaf.features.cfg config file.
>
>
> 2016-08-31 15:34 GMT+02:00 Jean-Baptiste Onofr� <jb@nanthrax.net
> <ma...@nanthrax.net>>:
>
> Hi Benson,
>
> I agree: we had a long discussion with Guillaume about that in the
> past ;)
>
> As a workaround, you can use the feature capability definition (and
> it can be done at runtime using feature:* commands). So your DS
> components don't have to change.
>
> Regards
> JB
>
>
> On 08/31/2016 03:30 PM, Benson Margulies wrote:
>
> Gentlemen,
>
> Thank you very much for the help. I want to offer a small
> argument for
> an option to turn all this off in a CFG file, before I get to work
> using the solutions you've offered.
>
> One of the virtues of DS is that you can mix-and-match: a DS
> component
> can transparently use non-DS services. This resolver feature
> disables
> that nice transparency by requiring any service used in a DS
> component
> to be accounted for in a Provide-Capability. So you might accept the
> proposition that this resolver enforcement is not so good for
> everyone.
>
> --benson
>
>
>
>
> On Wed, Aug 31, 2016 at 6:13 AM, Guillaume Nodet
> <gnodet@apache.org <ma...@apache.org>> wrote:
>
>
>
> 2016-08-31 15:00 GMT+02:00 Benson Margulies
> <benson@basistech.com <ma...@basistech.com>>:
>
>
> On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofr�
> <jb@nanthrax.net <ma...@nanthrax.net>>
> wrote:
>
> So, I will explain a new time (for the third time ;)).
>
>
> JB,
>
> I apologize for not being awake when this came through
> before.
>
> I just want to make sure that I am completely following
> this. The
> resolver is requiring that some bundle mentions the
> service in a
> Provide-Capability -- NOT that the service is actually
> running?
>
>
>
> The resolver looks at the bundle manifest. It runs before
> they are installed
> / started, so it can't really look at if they are running or
> not.
>
>
>
> The service in question is provided by an 'old' OSGi
> bundle that does
> not bother to do a Provide-Capability for it; it's not a
> service, just
> a service launched the old-fashioned way.
>
> Is there some thread you can point me to that offers
> suggestions for
> dealing with this? I would rather not have to go add
> Provide-Capability manifest entries for all my
> dynamically created
> OSGi services. Is there an option in a cfg file or a
> feature.xml that
> turns this back off?
>
>
>
> This could be done for karaf 4.1 with a new xsd.
>
>
>
> Perhaps I can persuade BND not to list them as requirements.
>
>
>
> Yeah, that's definitely the easiest way, you can easily
> remove the
> Require-Capability header, or disable the service
> requirements, depending on
> how they are generated.
>
>
>
>
> Thanks,
> benson
>
>
>
> When you are using features XML with namespace 1.3
> or 1.4, the feature
> resolver uses the service enforcement. It means that
> it checks the
> service
> capability in the bundles. The service requirement
> is basically a bundle
> that needs a service "A" at runtime. So the resolver
> will check the
> features
> containing the bundle providing such capability
> (exposing the service).
> It's
> what the effective:=active mean.
>
> The corresponding MANIFEST header is:
>
> <Provide-Capability>
> osgi.service;effective:=active;objectClass=myService
> </Provide-Capability>
>
> On the other hand, the requirement header looks like:
>
> <Require-Capability>
> osgi.service;effective:=active;filter:="(objectClass=aService)"
> </Require-Capability>
>
>
> Unfortunately, in Karaf 4.0.3, 4.0.4, 4.0.5, the
> service enforcement was
> enabled for features xmlns 1.3.0 NOT for 1.4.0 (it
> was a bug). This bug
> has
> been fixed in Karaf 4.0.6. That's why when you
> upgraded from 4.0.4 to
> 4.0.6,
> the feature resolver is now "active" for your
> features XML and check the
> service enforcement.
>
> Regards
> JB
>
>
> On 08/31/2016 02:31 PM, Benson Margulies wrote:
>
>
> I just tried the experiment of moving our
> platform from 4.0.4 to
> 4.0.6, changing nothing but the karaf version. I
> received in return a
> resolution error that I've never seen the like
> of before, complaining
> that a particular service is missing with
> 'effective:=active'.
>
> Since Karaf does not come to command level when
> this sort of thing
> goes wrong, it is not obvious to me how to gain
> any insight into what
> is wrong. The service reference itself is very
> strange;
> 'RosetteBundleWarmup' a DS reference like:
>
> @Reference(target =
> "(component-name=name-matching)")
> public void setWarmup(RosetteBundleWarmup warmup) {
> this.componentWarmup = warmup;
> }
>
> and I don't see the component-name filter in the
> error message. It's
> also new to me that DS @Reference is even
> visible to resolution at the
> time that boot features are being resolved.
>
>
> 2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1 |
> BootFeaturesInstaller | 6 -
> org.apache.karaf.features.core
> - 4.0.6 | Error installing boot features
> org.osgi.service.resolver.ResolutionException:
> Unable to resolve root:
> missing requirement [root] osgi.identity;
> osgi.identity=rosapi-all-sdks; type=karaf.feature;
> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
>
>
> filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
> [caused by: Unable to resolve
> rosapi-all-sdks/1.2.6. <http://1.2.6.>SNAPSHOT:
> missing
> requirement [rosapi-all-sdks/1.2.6.
> <http://1.2.6.>SNAPSHOT] osgi.identity;
> osgi.identity=rosapi-worker-rni-rnt-sdk;
> type=karaf.feature [caused
> by: Unable to resolve
> rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
> missing requirement
> [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
> osgi.identity;
> osgi.identity=com.basistech.ws
> <http://com.basistech.ws>.rosapi-worker-rni-rnt-sdk;
> type=osgi.bundle;
> version="[1.2.6.v20160831122227,1.2.6.v20160831122227]";
> resolution:=mandatory [caused by: Unable to resolve
> com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6. <http://1.2.6.>v20160831122227:
> missing requirement
> [com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.
> <http://1.2.6.>v20160831122227]
> osgi.service;
> filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
> effective:=active]]]
>
>
> --
> Jean-Baptiste Onofr�
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com <ma...@redhat.com>
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
> --
> Jean-Baptiste Onofr�
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com <ma...@redhat.com>
> Web: http://fusesource.com <http://fusesource.com/>
> Blog: http://gnodet.blogspot.com/
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: What does effective:=active mean?
Posted by Guillaume Nodet <gn...@apache.org>.
You can always disable service requirements globally by setting
serviceRequirements = disable
in the etc/org.apache.karaf.features.cfg config file.
2016-08-31 15:34 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Hi Benson,
>
> I agree: we had a long discussion with Guillaume about that in the past ;)
>
> As a workaround, you can use the feature capability definition (and it can
> be done at runtime using feature:* commands). So your DS components don't
> have to change.
>
> Regards
> JB
>
>
> On 08/31/2016 03:30 PM, Benson Margulies wrote:
>
>> Gentlemen,
>>
>> Thank you very much for the help. I want to offer a small argument for
>> an option to turn all this off in a CFG file, before I get to work
>> using the solutions you've offered.
>>
>> One of the virtues of DS is that you can mix-and-match: a DS component
>> can transparently use non-DS services. This resolver feature disables
>> that nice transparency by requiring any service used in a DS component
>> to be accounted for in a Provide-Capability. So you might accept the
>> proposition that this resolver enforcement is not so good for
>> everyone.
>>
>> --benson
>>
>>
>>
>>
>> On Wed, Aug 31, 2016 at 6:13 AM, Guillaume Nodet <gn...@apache.org>
>> wrote:
>>
>>>
>>>
>>> 2016-08-31 15:00 GMT+02:00 Benson Margulies <be...@basistech.com>:
>>>
>>>>
>>>> On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>> wrote:
>>>>
>>>>> So, I will explain a new time (for the third time ;)).
>>>>>
>>>>
>>>> JB,
>>>>
>>>> I apologize for not being awake when this came through before.
>>>>
>>>> I just want to make sure that I am completely following this. The
>>>> resolver is requiring that some bundle mentions the service in a
>>>> Provide-Capability -- NOT that the service is actually running?
>>>>
>>>
>>>
>>> The resolver looks at the bundle manifest. It runs before they are
>>> installed
>>> / started, so it can't really look at if they are running or not.
>>>
>>>
>>>>
>>>> The service in question is provided by an 'old' OSGi bundle that does
>>>> not bother to do a Provide-Capability for it; it's not a service, just
>>>> a service launched the old-fashioned way.
>>>>
>>>> Is there some thread you can point me to that offers suggestions for
>>>> dealing with this? I would rather not have to go add
>>>> Provide-Capability manifest entries for all my dynamically created
>>>> OSGi services. Is there an option in a cfg file or a feature.xml that
>>>> turns this back off?
>>>>
>>>
>>>
>>> This could be done for karaf 4.1 with a new xsd.
>>>
>>>
>>>>
>>>> Perhaps I can persuade BND not to list them as requirements.
>>>>
>>>
>>>
>>> Yeah, that's definitely the easiest way, you can easily remove the
>>> Require-Capability header, or disable the service requirements,
>>> depending on
>>> how they are generated.
>>>
>>>
>>>
>>>>
>>>> Thanks,
>>>> benson
>>>>
>>>>
>>>>
>>>>> When you are using features XML with namespace 1.3 or 1.4, the feature
>>>>> resolver uses the service enforcement. It means that it checks the
>>>>> service
>>>>> capability in the bundles. The service requirement is basically a
>>>>> bundle
>>>>> that needs a service "A" at runtime. So the resolver will check the
>>>>> features
>>>>> containing the bundle providing such capability (exposing the service).
>>>>> It's
>>>>> what the effective:=active mean.
>>>>>
>>>>> The corresponding MANIFEST header is:
>>>>>
>>>>> <Provide-Capability>
>>>>> osgi.service;effective:=active;objectClass=myService
>>>>> </Provide-Capability>
>>>>>
>>>>> On the other hand, the requirement header looks like:
>>>>>
>>>>> <Require-Capability>
>>>>> osgi.service;effective:=active;filter:="(objectClass=aService)"
>>>>> </Require-Capability>
>>>>>
>>>>>
>>>>> Unfortunately, in Karaf 4.0.3, 4.0.4, 4.0.5, the service enforcement
>>>>> was
>>>>> enabled for features xmlns 1.3.0 NOT for 1.4.0 (it was a bug). This bug
>>>>> has
>>>>> been fixed in Karaf 4.0.6. That's why when you upgraded from 4.0.4 to
>>>>> 4.0.6,
>>>>> the feature resolver is now "active" for your features XML and check
>>>>> the
>>>>> service enforcement.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 08/31/2016 02:31 PM, Benson Margulies wrote:
>>>>>
>>>>>>
>>>>>> I just tried the experiment of moving our platform from 4.0.4 to
>>>>>> 4.0.6, changing nothing but the karaf version. I received in return a
>>>>>> resolution error that I've never seen the like of before, complaining
>>>>>> that a particular service is missing with 'effective:=active'.
>>>>>>
>>>>>> Since Karaf does not come to command level when this sort of thing
>>>>>> goes wrong, it is not obvious to me how to gain any insight into what
>>>>>> is wrong. The service reference itself is very strange;
>>>>>> 'RosetteBundleWarmup' a DS reference like:
>>>>>>
>>>>>> @Reference(target = "(component-name=name-matching)")
>>>>>> public void setWarmup(RosetteBundleWarmup warmup) {
>>>>>> this.componentWarmup = warmup;
>>>>>> }
>>>>>>
>>>>>> and I don't see the component-name filter in the error message. It's
>>>>>> also new to me that DS @Reference is even visible to resolution at the
>>>>>> time that boot features are being resolved.
>>>>>>
>>>>>>
>>>>>> 2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1 |
>>>>>> BootFeaturesInstaller | 6 - org.apache.karaf.features.core
>>>>>> - 4.0.6 | Error installing boot features
>>>>>> org.osgi.service.resolver.ResolutionException: Unable to resolve
>>>>>> root:
>>>>>> missing requirement [root] osgi.identity;
>>>>>> osgi.identity=rosapi-all-sdks; type=karaf.feature;
>>>>>> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
>>>>>>
>>>>>>
>>>>>> filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.featur
>>>>>> e)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
>>>>>> [caused by: Unable to resolve rosapi-all-sdks/1.2.6.SNAPSHOT: missing
>>>>>> requirement [rosapi-all-sdks/1.2.6.SNAPSHOT] osgi.identity;
>>>>>> osgi.identity=rosapi-worker-rni-rnt-sdk; type=karaf.feature [caused
>>>>>> by: Unable to resolve rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
>>>>>> missing requirement [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
>>>>>> osgi.identity;
>>>>>> osgi.identity=com.basistech.ws.rosapi-worker-rni-rnt-sdk;
>>>>>> type=osgi.bundle;
>>>>>> version="[1.2.6.v20160831122227,1.2.6.v20160831122227]";
>>>>>> resolution:=mandatory [caused by: Unable to resolve
>>>>>> com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227:
>>>>>> missing requirement
>>>>>> [com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227]
>>>>>> osgi.service;
>>>>>> filter:="(objectClass=com.basistech.rosette.osgi.RosetteBund
>>>>>> leWarmup)";
>>>>>> effective:=active]]]
>>>>>>
>>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Red Hat, Open Source Integration
>>>
>>> Email: gnodet@redhat.com
>>> Web: http://fusesource.com
>>> Blog: http://gnodet.blogspot.com/
>>>
>>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: What does effective:=active mean?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Benson,
I agree: we had a long discussion with Guillaume about that in the past ;)
As a workaround, you can use the feature capability definition (and it
can be done at runtime using feature:* commands). So your DS components
don't have to change.
Regards
JB
On 08/31/2016 03:30 PM, Benson Margulies wrote:
> Gentlemen,
>
> Thank you very much for the help. I want to offer a small argument for
> an option to turn all this off in a CFG file, before I get to work
> using the solutions you've offered.
>
> One of the virtues of DS is that you can mix-and-match: a DS component
> can transparently use non-DS services. This resolver feature disables
> that nice transparency by requiring any service used in a DS component
> to be accounted for in a Provide-Capability. So you might accept the
> proposition that this resolver enforcement is not so good for
> everyone.
>
> --benson
>
>
>
>
> On Wed, Aug 31, 2016 at 6:13 AM, Guillaume Nodet <gn...@apache.org> wrote:
>>
>>
>> 2016-08-31 15:00 GMT+02:00 Benson Margulies <be...@basistech.com>:
>>>
>>> On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofr� <jb...@nanthrax.net>
>>> wrote:
>>>> So, I will explain a new time (for the third time ;)).
>>>
>>> JB,
>>>
>>> I apologize for not being awake when this came through before.
>>>
>>> I just want to make sure that I am completely following this. The
>>> resolver is requiring that some bundle mentions the service in a
>>> Provide-Capability -- NOT that the service is actually running?
>>
>>
>> The resolver looks at the bundle manifest. It runs before they are installed
>> / started, so it can't really look at if they are running or not.
>>
>>>
>>>
>>> The service in question is provided by an 'old' OSGi bundle that does
>>> not bother to do a Provide-Capability for it; it's not a service, just
>>> a service launched the old-fashioned way.
>>>
>>> Is there some thread you can point me to that offers suggestions for
>>> dealing with this? I would rather not have to go add
>>> Provide-Capability manifest entries for all my dynamically created
>>> OSGi services. Is there an option in a cfg file or a feature.xml that
>>> turns this back off?
>>
>>
>> This could be done for karaf 4.1 with a new xsd.
>>
>>>
>>>
>>> Perhaps I can persuade BND not to list them as requirements.
>>
>>
>> Yeah, that's definitely the easiest way, you can easily remove the
>> Require-Capability header, or disable the service requirements, depending on
>> how they are generated.
>>
>>
>>>
>>>
>>> Thanks,
>>> benson
>>>
>>>
>>>>
>>>> When you are using features XML with namespace 1.3 or 1.4, the feature
>>>> resolver uses the service enforcement. It means that it checks the
>>>> service
>>>> capability in the bundles. The service requirement is basically a bundle
>>>> that needs a service "A" at runtime. So the resolver will check the
>>>> features
>>>> containing the bundle providing such capability (exposing the service).
>>>> It's
>>>> what the effective:=active mean.
>>>>
>>>> The corresponding MANIFEST header is:
>>>>
>>>> <Provide-Capability>
>>>> osgi.service;effective:=active;objectClass=myService
>>>> </Provide-Capability>
>>>>
>>>> On the other hand, the requirement header looks like:
>>>>
>>>> <Require-Capability>
>>>> osgi.service;effective:=active;filter:="(objectClass=aService)"
>>>> </Require-Capability>
>>>>
>>>>
>>>> Unfortunately, in Karaf 4.0.3, 4.0.4, 4.0.5, the service enforcement was
>>>> enabled for features xmlns 1.3.0 NOT for 1.4.0 (it was a bug). This bug
>>>> has
>>>> been fixed in Karaf 4.0.6. That's why when you upgraded from 4.0.4 to
>>>> 4.0.6,
>>>> the feature resolver is now "active" for your features XML and check the
>>>> service enforcement.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 08/31/2016 02:31 PM, Benson Margulies wrote:
>>>>>
>>>>> I just tried the experiment of moving our platform from 4.0.4 to
>>>>> 4.0.6, changing nothing but the karaf version. I received in return a
>>>>> resolution error that I've never seen the like of before, complaining
>>>>> that a particular service is missing with 'effective:=active'.
>>>>>
>>>>> Since Karaf does not come to command level when this sort of thing
>>>>> goes wrong, it is not obvious to me how to gain any insight into what
>>>>> is wrong. The service reference itself is very strange;
>>>>> 'RosetteBundleWarmup' a DS reference like:
>>>>>
>>>>> @Reference(target = "(component-name=name-matching)")
>>>>> public void setWarmup(RosetteBundleWarmup warmup) {
>>>>> this.componentWarmup = warmup;
>>>>> }
>>>>>
>>>>> and I don't see the component-name filter in the error message. It's
>>>>> also new to me that DS @Reference is even visible to resolution at the
>>>>> time that boot features are being resolved.
>>>>>
>>>>>
>>>>> 2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1 |
>>>>> BootFeaturesInstaller | 6 - org.apache.karaf.features.core
>>>>> - 4.0.6 | Error installing boot features
>>>>> org.osgi.service.resolver.ResolutionException: Unable to resolve root:
>>>>> missing requirement [root] osgi.identity;
>>>>> osgi.identity=rosapi-all-sdks; type=karaf.feature;
>>>>> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
>>>>>
>>>>>
>>>>> filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
>>>>> [caused by: Unable to resolve rosapi-all-sdks/1.2.6.SNAPSHOT: missing
>>>>> requirement [rosapi-all-sdks/1.2.6.SNAPSHOT] osgi.identity;
>>>>> osgi.identity=rosapi-worker-rni-rnt-sdk; type=karaf.feature [caused
>>>>> by: Unable to resolve rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
>>>>> missing requirement [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
>>>>> osgi.identity;
>>>>> osgi.identity=com.basistech.ws.rosapi-worker-rni-rnt-sdk;
>>>>> type=osgi.bundle;
>>>>> version="[1.2.6.v20160831122227,1.2.6.v20160831122227]";
>>>>> resolution:=mandatory [caused by: Unable to resolve
>>>>> com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227:
>>>>> missing requirement
>>>>> [com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227]
>>>>> osgi.service;
>>>>> filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
>>>>> effective:=active]]]
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofr�
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Red Hat, Open Source Integration
>>
>> Email: gnodet@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: What does effective:=active mean?
Posted by Benson Margulies <be...@basistech.com>.
Gentlemen,
Thank you very much for the help. I want to offer a small argument for
an option to turn all this off in a CFG file, before I get to work
using the solutions you've offered.
One of the virtues of DS is that you can mix-and-match: a DS component
can transparently use non-DS services. This resolver feature disables
that nice transparency by requiring any service used in a DS component
to be accounted for in a Provide-Capability. So you might accept the
proposition that this resolver enforcement is not so good for
everyone.
--benson
On Wed, Aug 31, 2016 at 6:13 AM, Guillaume Nodet <gn...@apache.org> wrote:
>
>
> 2016-08-31 15:00 GMT+02:00 Benson Margulies <be...@basistech.com>:
>>
>> On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>> > So, I will explain a new time (for the third time ;)).
>>
>> JB,
>>
>> I apologize for not being awake when this came through before.
>>
>> I just want to make sure that I am completely following this. The
>> resolver is requiring that some bundle mentions the service in a
>> Provide-Capability -- NOT that the service is actually running?
>
>
> The resolver looks at the bundle manifest. It runs before they are installed
> / started, so it can't really look at if they are running or not.
>
>>
>>
>> The service in question is provided by an 'old' OSGi bundle that does
>> not bother to do a Provide-Capability for it; it's not a service, just
>> a service launched the old-fashioned way.
>>
>> Is there some thread you can point me to that offers suggestions for
>> dealing with this? I would rather not have to go add
>> Provide-Capability manifest entries for all my dynamically created
>> OSGi services. Is there an option in a cfg file or a feature.xml that
>> turns this back off?
>
>
> This could be done for karaf 4.1 with a new xsd.
>
>>
>>
>> Perhaps I can persuade BND not to list them as requirements.
>
>
> Yeah, that's definitely the easiest way, you can easily remove the
> Require-Capability header, or disable the service requirements, depending on
> how they are generated.
>
>
>>
>>
>> Thanks,
>> benson
>>
>>
>> >
>> > When you are using features XML with namespace 1.3 or 1.4, the feature
>> > resolver uses the service enforcement. It means that it checks the
>> > service
>> > capability in the bundles. The service requirement is basically a bundle
>> > that needs a service "A" at runtime. So the resolver will check the
>> > features
>> > containing the bundle providing such capability (exposing the service).
>> > It's
>> > what the effective:=active mean.
>> >
>> > The corresponding MANIFEST header is:
>> >
>> > <Provide-Capability>
>> > osgi.service;effective:=active;objectClass=myService
>> > </Provide-Capability>
>> >
>> > On the other hand, the requirement header looks like:
>> >
>> > <Require-Capability>
>> > osgi.service;effective:=active;filter:="(objectClass=aService)"
>> > </Require-Capability>
>> >
>> >
>> > Unfortunately, in Karaf 4.0.3, 4.0.4, 4.0.5, the service enforcement was
>> > enabled for features xmlns 1.3.0 NOT for 1.4.0 (it was a bug). This bug
>> > has
>> > been fixed in Karaf 4.0.6. That's why when you upgraded from 4.0.4 to
>> > 4.0.6,
>> > the feature resolver is now "active" for your features XML and check the
>> > service enforcement.
>> >
>> > Regards
>> > JB
>> >
>> >
>> > On 08/31/2016 02:31 PM, Benson Margulies wrote:
>> >>
>> >> I just tried the experiment of moving our platform from 4.0.4 to
>> >> 4.0.6, changing nothing but the karaf version. I received in return a
>> >> resolution error that I've never seen the like of before, complaining
>> >> that a particular service is missing with 'effective:=active'.
>> >>
>> >> Since Karaf does not come to command level when this sort of thing
>> >> goes wrong, it is not obvious to me how to gain any insight into what
>> >> is wrong. The service reference itself is very strange;
>> >> 'RosetteBundleWarmup' a DS reference like:
>> >>
>> >> @Reference(target = "(component-name=name-matching)")
>> >> public void setWarmup(RosetteBundleWarmup warmup) {
>> >> this.componentWarmup = warmup;
>> >> }
>> >>
>> >> and I don't see the component-name filter in the error message. It's
>> >> also new to me that DS @Reference is even visible to resolution at the
>> >> time that boot features are being resolved.
>> >>
>> >>
>> >> 2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1 |
>> >> BootFeaturesInstaller | 6 - org.apache.karaf.features.core
>> >> - 4.0.6 | Error installing boot features
>> >> org.osgi.service.resolver.ResolutionException: Unable to resolve root:
>> >> missing requirement [root] osgi.identity;
>> >> osgi.identity=rosapi-all-sdks; type=karaf.feature;
>> >> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
>> >>
>> >>
>> >> filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
>> >> [caused by: Unable to resolve rosapi-all-sdks/1.2.6.SNAPSHOT: missing
>> >> requirement [rosapi-all-sdks/1.2.6.SNAPSHOT] osgi.identity;
>> >> osgi.identity=rosapi-worker-rni-rnt-sdk; type=karaf.feature [caused
>> >> by: Unable to resolve rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
>> >> missing requirement [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
>> >> osgi.identity;
>> >> osgi.identity=com.basistech.ws.rosapi-worker-rni-rnt-sdk;
>> >> type=osgi.bundle;
>> >> version="[1.2.6.v20160831122227,1.2.6.v20160831122227]";
>> >> resolution:=mandatory [caused by: Unable to resolve
>> >> com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227:
>> >> missing requirement
>> >> [com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227]
>> >> osgi.service;
>> >> filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
>> >> effective:=active]]]
>> >>
>> >
>> > --
>> > Jean-Baptiste Onofré
>> > jbonofre@apache.org
>> > http://blog.nanthrax.net
>> > Talend - http://www.talend.com
>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
Re: What does effective:=active mean?
Posted by Guillaume Nodet <gn...@apache.org>.
2016-08-31 15:00 GMT+02:00 Benson Margulies <be...@basistech.com>:
> On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> > So, I will explain a new time (for the third time ;)).
>
> JB,
>
> I apologize for not being awake when this came through before.
>
> I just want to make sure that I am completely following this. The
> resolver is requiring that some bundle mentions the service in a
> Provide-Capability -- NOT that the service is actually running?
>
The resolver looks at the bundle manifest. It runs before they are
installed / started, so it can't really look at if they are running or not.
>
> The service in question is provided by an 'old' OSGi bundle that does
> not bother to do a Provide-Capability for it; it's not a service, just
> a service launched the old-fashioned way.
>
> Is there some thread you can point me to that offers suggestions for
> dealing with this? I would rather not have to go add
> Provide-Capability manifest entries for all my dynamically created
> OSGi services. Is there an option in a cfg file or a feature.xml that
> turns this back off?
>
This could be done for karaf 4.1 with a new xsd.
>
> Perhaps I can persuade BND not to list them as requirements.
>
Yeah, that's definitely the easiest way, you can easily remove the
Require-Capability header, or disable the service requirements, depending
on how they are generated.
>
> Thanks,
> benson
>
>
> >
> > When you are using features XML with namespace 1.3 or 1.4, the feature
> > resolver uses the service enforcement. It means that it checks the
> service
> > capability in the bundles. The service requirement is basically a bundle
> > that needs a service "A" at runtime. So the resolver will check the
> features
> > containing the bundle providing such capability (exposing the service).
> It's
> > what the effective:=active mean.
> >
> > The corresponding MANIFEST header is:
> >
> > <Provide-Capability>
> > osgi.service;effective:=active;objectClass=myService
> > </Provide-Capability>
> >
> > On the other hand, the requirement header looks like:
> >
> > <Require-Capability>
> > osgi.service;effective:=active;filter:="(objectClass=aService)"
> > </Require-Capability>
> >
> >
> > Unfortunately, in Karaf 4.0.3, 4.0.4, 4.0.5, the service enforcement was
> > enabled for features xmlns 1.3.0 NOT for 1.4.0 (it was a bug). This bug
> has
> > been fixed in Karaf 4.0.6. That's why when you upgraded from 4.0.4 to
> 4.0.6,
> > the feature resolver is now "active" for your features XML and check the
> > service enforcement.
> >
> > Regards
> > JB
> >
> >
> > On 08/31/2016 02:31 PM, Benson Margulies wrote:
> >>
> >> I just tried the experiment of moving our platform from 4.0.4 to
> >> 4.0.6, changing nothing but the karaf version. I received in return a
> >> resolution error that I've never seen the like of before, complaining
> >> that a particular service is missing with 'effective:=active'.
> >>
> >> Since Karaf does not come to command level when this sort of thing
> >> goes wrong, it is not obvious to me how to gain any insight into what
> >> is wrong. The service reference itself is very strange;
> >> 'RosetteBundleWarmup' a DS reference like:
> >>
> >> @Reference(target = "(component-name=name-matching)")
> >> public void setWarmup(RosetteBundleWarmup warmup) {
> >> this.componentWarmup = warmup;
> >> }
> >>
> >> and I don't see the component-name filter in the error message. It's
> >> also new to me that DS @Reference is even visible to resolution at the
> >> time that boot features are being resolved.
> >>
> >>
> >> 2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1 |
> >> BootFeaturesInstaller | 6 - org.apache.karaf.features.core
> >> - 4.0.6 | Error installing boot features
> >> org.osgi.service.resolver.ResolutionException: Unable to resolve root:
> >> missing requirement [root] osgi.identity;
> >> osgi.identity=rosapi-all-sdks; type=karaf.feature;
> >> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
> >>
> >> filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.
> feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
> >> [caused by: Unable to resolve rosapi-all-sdks/1.2.6.SNAPSHOT: missing
> >> requirement [rosapi-all-sdks/1.2.6.SNAPSHOT] osgi.identity;
> >> osgi.identity=rosapi-worker-rni-rnt-sdk; type=karaf.feature [caused
> >> by: Unable to resolve rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
> >> missing requirement [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
> >> osgi.identity; osgi.identity=com.basistech.
> ws.rosapi-worker-rni-rnt-sdk;
> >> type=osgi.bundle;
> >> version="[1.2.6.v20160831122227,1.2.6.v20160831122227]";
> >> resolution:=mandatory [caused by: Unable to resolve
> >> com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227:
> >> missing requirement
> >> [com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227]
> >> osgi.service;
> >> filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
> >> effective:=active]]]
> >>
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: What does effective:=active mean?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Benson,
See my comments inline:
On 08/31/2016 03:00 PM, Benson Margulies wrote:
> On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofr� <jb...@nanthrax.net> wrote:
>> So, I will explain a new time (for the third time ;)).
>
> JB,
>
> I apologize for not being awake when this came through before.
No worries, it was a joke ;)
>
> I just want to make sure that I am completely following this. The
> resolver is requiring that some bundle mentions the service in a
> Provide-Capability -- NOT that the service is actually running?
Correct.
>
> The service in question is provided by an 'old' OSGi bundle that does
> not bother to do a Provide-Capability for it; it's not a service, just
> a service launched the old-fashioned way.
>
> Is there some thread you can point me to that offers suggestions for
> dealing with this? I would rather not have to go add
> Provide-Capability manifest entries for all my dynamically created
> OSGi services. Is there an option in a cfg file or a feature.xml that
> turns this back off?
An alternative to the bundle itself is to set the capability at feature
level. The features XML can provide the capability (if the bundles don't):
<feature name="foo" version="1.0">
...
<capability>
osgi.service;effective:=active;objectClass=myService
</capability>
</feature>
Regards
JB
>
> Perhaps I can persuade BND not to list them as requirements.
>
> Thanks,
> benson
>
>
>>
>> When you are using features XML with namespace 1.3 or 1.4, the feature
>> resolver uses the service enforcement. It means that it checks the service
>> capability in the bundles. The service requirement is basically a bundle
>> that needs a service "A" at runtime. So the resolver will check the features
>> containing the bundle providing such capability (exposing the service). It's
>> what the effective:=active mean.
>>
>> The corresponding MANIFEST header is:
>>
>> <Provide-Capability>
>> osgi.service;effective:=active;objectClass=myService
>> </Provide-Capability>
>>
>> On the other hand, the requirement header looks like:
>>
>> <Require-Capability>
>> osgi.service;effective:=active;filter:="(objectClass=aService)"
>> </Require-Capability>
>>
>>
>> Unfortunately, in Karaf 4.0.3, 4.0.4, 4.0.5, the service enforcement was
>> enabled for features xmlns 1.3.0 NOT for 1.4.0 (it was a bug). This bug has
>> been fixed in Karaf 4.0.6. That's why when you upgraded from 4.0.4 to 4.0.6,
>> the feature resolver is now "active" for your features XML and check the
>> service enforcement.
>>
>> Regards
>> JB
>>
>>
>> On 08/31/2016 02:31 PM, Benson Margulies wrote:
>>>
>>> I just tried the experiment of moving our platform from 4.0.4 to
>>> 4.0.6, changing nothing but the karaf version. I received in return a
>>> resolution error that I've never seen the like of before, complaining
>>> that a particular service is missing with 'effective:=active'.
>>>
>>> Since Karaf does not come to command level when this sort of thing
>>> goes wrong, it is not obvious to me how to gain any insight into what
>>> is wrong. The service reference itself is very strange;
>>> 'RosetteBundleWarmup' a DS reference like:
>>>
>>> @Reference(target = "(component-name=name-matching)")
>>> public void setWarmup(RosetteBundleWarmup warmup) {
>>> this.componentWarmup = warmup;
>>> }
>>>
>>> and I don't see the component-name filter in the error message. It's
>>> also new to me that DS @Reference is even visible to resolution at the
>>> time that boot features are being resolved.
>>>
>>>
>>> 2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1 |
>>> BootFeaturesInstaller | 6 - org.apache.karaf.features.core
>>> - 4.0.6 | Error installing boot features
>>> org.osgi.service.resolver.ResolutionException: Unable to resolve root:
>>> missing requirement [root] osgi.identity;
>>> osgi.identity=rosapi-all-sdks; type=karaf.feature;
>>> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
>>>
>>> filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
>>> [caused by: Unable to resolve rosapi-all-sdks/1.2.6.SNAPSHOT: missing
>>> requirement [rosapi-all-sdks/1.2.6.SNAPSHOT] osgi.identity;
>>> osgi.identity=rosapi-worker-rni-rnt-sdk; type=karaf.feature [caused
>>> by: Unable to resolve rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
>>> missing requirement [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
>>> osgi.identity; osgi.identity=com.basistech.ws.rosapi-worker-rni-rnt-sdk;
>>> type=osgi.bundle;
>>> version="[1.2.6.v20160831122227,1.2.6.v20160831122227]";
>>> resolution:=mandatory [caused by: Unable to resolve
>>> com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227:
>>> missing requirement
>>> [com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227]
>>> osgi.service;
>>> filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
>>> effective:=active]]]
>>>
>>
>> --
>> Jean-Baptiste Onofr�
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: What does effective:=active mean?
Posted by Benson Margulies <be...@basistech.com>.
On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> So, I will explain a new time (for the third time ;)).
JB,
I apologize for not being awake when this came through before.
I just want to make sure that I am completely following this. The
resolver is requiring that some bundle mentions the service in a
Provide-Capability -- NOT that the service is actually running?
The service in question is provided by an 'old' OSGi bundle that does
not bother to do a Provide-Capability for it; it's not a service, just
a service launched the old-fashioned way.
Is there some thread you can point me to that offers suggestions for
dealing with this? I would rather not have to go add
Provide-Capability manifest entries for all my dynamically created
OSGi services. Is there an option in a cfg file or a feature.xml that
turns this back off?
Perhaps I can persuade BND not to list them as requirements.
Thanks,
benson
>
> When you are using features XML with namespace 1.3 or 1.4, the feature
> resolver uses the service enforcement. It means that it checks the service
> capability in the bundles. The service requirement is basically a bundle
> that needs a service "A" at runtime. So the resolver will check the features
> containing the bundle providing such capability (exposing the service). It's
> what the effective:=active mean.
>
> The corresponding MANIFEST header is:
>
> <Provide-Capability>
> osgi.service;effective:=active;objectClass=myService
> </Provide-Capability>
>
> On the other hand, the requirement header looks like:
>
> <Require-Capability>
> osgi.service;effective:=active;filter:="(objectClass=aService)"
> </Require-Capability>
>
>
> Unfortunately, in Karaf 4.0.3, 4.0.4, 4.0.5, the service enforcement was
> enabled for features xmlns 1.3.0 NOT for 1.4.0 (it was a bug). This bug has
> been fixed in Karaf 4.0.6. That's why when you upgraded from 4.0.4 to 4.0.6,
> the feature resolver is now "active" for your features XML and check the
> service enforcement.
>
> Regards
> JB
>
>
> On 08/31/2016 02:31 PM, Benson Margulies wrote:
>>
>> I just tried the experiment of moving our platform from 4.0.4 to
>> 4.0.6, changing nothing but the karaf version. I received in return a
>> resolution error that I've never seen the like of before, complaining
>> that a particular service is missing with 'effective:=active'.
>>
>> Since Karaf does not come to command level when this sort of thing
>> goes wrong, it is not obvious to me how to gain any insight into what
>> is wrong. The service reference itself is very strange;
>> 'RosetteBundleWarmup' a DS reference like:
>>
>> @Reference(target = "(component-name=name-matching)")
>> public void setWarmup(RosetteBundleWarmup warmup) {
>> this.componentWarmup = warmup;
>> }
>>
>> and I don't see the component-name filter in the error message. It's
>> also new to me that DS @Reference is even visible to resolution at the
>> time that boot features are being resolved.
>>
>>
>> 2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1 |
>> BootFeaturesInstaller | 6 - org.apache.karaf.features.core
>> - 4.0.6 | Error installing boot features
>> org.osgi.service.resolver.ResolutionException: Unable to resolve root:
>> missing requirement [root] osgi.identity;
>> osgi.identity=rosapi-all-sdks; type=karaf.feature;
>> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
>>
>> filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
>> [caused by: Unable to resolve rosapi-all-sdks/1.2.6.SNAPSHOT: missing
>> requirement [rosapi-all-sdks/1.2.6.SNAPSHOT] osgi.identity;
>> osgi.identity=rosapi-worker-rni-rnt-sdk; type=karaf.feature [caused
>> by: Unable to resolve rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
>> missing requirement [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
>> osgi.identity; osgi.identity=com.basistech.ws.rosapi-worker-rni-rnt-sdk;
>> type=osgi.bundle;
>> version="[1.2.6.v20160831122227,1.2.6.v20160831122227]";
>> resolution:=mandatory [caused by: Unable to resolve
>> com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227:
>> missing requirement
>> [com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227]
>> osgi.service;
>> filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
>> effective:=active]]]
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: What does effective:=active mean?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
So, I will explain a new time (for the third time ;)).
When you are using features XML with namespace 1.3 or 1.4, the feature
resolver uses the service enforcement. It means that it checks the
service capability in the bundles. The service requirement is basically
a bundle that needs a service "A" at runtime. So the resolver will check
the features containing the bundle providing such capability (exposing
the service). It's what the effective:=active mean.
The corresponding MANIFEST header is:
<Provide-Capability>
osgi.service;effective:=active;objectClass=myService
</Provide-Capability>
On the other hand, the requirement header looks like:
<Require-Capability>
osgi.service;effective:=active;filter:="(objectClass=aService)"
</Require-Capability>
Unfortunately, in Karaf 4.0.3, 4.0.4, 4.0.5, the service enforcement was
enabled for features xmlns 1.3.0 NOT for 1.4.0 (it was a bug). This bug
has been fixed in Karaf 4.0.6. That's why when you upgraded from 4.0.4
to 4.0.6, the feature resolver is now "active" for your features XML and
check the service enforcement.
Regards
JB
On 08/31/2016 02:31 PM, Benson Margulies wrote:
> I just tried the experiment of moving our platform from 4.0.4 to
> 4.0.6, changing nothing but the karaf version. I received in return a
> resolution error that I've never seen the like of before, complaining
> that a particular service is missing with 'effective:=active'.
>
> Since Karaf does not come to command level when this sort of thing
> goes wrong, it is not obvious to me how to gain any insight into what
> is wrong. The service reference itself is very strange;
> 'RosetteBundleWarmup' a DS reference like:
>
> @Reference(target = "(component-name=name-matching)")
> public void setWarmup(RosetteBundleWarmup warmup) {
> this.componentWarmup = warmup;
> }
>
> and I don't see the component-name filter in the error message. It's
> also new to me that DS @Reference is even visible to resolution at the
> time that boot features are being resolved.
>
>
> 2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1 |
> BootFeaturesInstaller | 6 - org.apache.karaf.features.core
> - 4.0.6 | Error installing boot features
> org.osgi.service.resolver.ResolutionException: Unable to resolve root:
> missing requirement [root] osgi.identity;
> osgi.identity=rosapi-all-sdks; type=karaf.feature;
> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
> filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
> [caused by: Unable to resolve rosapi-all-sdks/1.2.6.SNAPSHOT: missing
> requirement [rosapi-all-sdks/1.2.6.SNAPSHOT] osgi.identity;
> osgi.identity=rosapi-worker-rni-rnt-sdk; type=karaf.feature [caused
> by: Unable to resolve rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
> missing requirement [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
> osgi.identity; osgi.identity=com.basistech.ws.rosapi-worker-rni-rnt-sdk;
> type=osgi.bundle;
> version="[1.2.6.v20160831122227,1.2.6.v20160831122227]";
> resolution:=mandatory [caused by: Unable to resolve
> com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227:
> missing requirement
> [com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227]
> osgi.service; filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
> effective:=active]]]
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com