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