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 <gno...@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é <j...@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 <gno...@apache.org>
>>> wrote:
>>>
>>>>
>>>>
>>>> 2016-08-31 15:00 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>>>>
>>>>>
>>>>> On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré <j...@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é
>>>>>> jbono...@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Red Hat, Open Source Integration
>>>>
>>>> Email: gno...@redhat.com
>>>> Web: http://fusesource.com
>>>> Blog: http://gnodet.blogspot.com/
>>>>
>>>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
