THANK YOU ALL!
On Wed, Aug 31, 2016 at 7:15 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > 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
