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/
