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