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/
