karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: What does effective:=active mean?
Date Wed, 31 Aug 2016 13:08:25 GMT
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

Mime
View raw message