karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: What does effective:=active mean?
Date Wed, 31 Aug 2016 14:15:57 GMT
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é <jb@nanthrax.net
> <mailto:jb@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
>         <gnodet@apache.org <mailto:gnodet@apache.org>> wrote:
>
>
>
>             2016-08-31 15:00 GMT+02:00 Benson Margulies
>             <benson@basistech.com <mailto:benson@basistech.com>>:
>
>
>                 On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré
>                 <jb@nanthrax.net <mailto:jb@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é
>                     jbonofre@apache.org <mailto:jbonofre@apache.org>
>                     http://blog.nanthrax.net
>                     Talend - http://www.talend.com
>
>
>
>
>
>             --
>             ------------------------
>             Guillaume Nodet
>             ------------------------
>             Red Hat, Open Source Integration
>
>             Email: gnodet@redhat.com <mailto:gnodet@redhat.com>
>             Web: http://fusesource.com
>             Blog: http://gnodet.blogspot.com/
>
>
>     --
>     Jean-Baptiste Onofré
>     jbonofre@apache.org <mailto:jbonofre@apache.org>
>     http://blog.nanthrax.net
>     Talend - http://www.talend.com
>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com <mailto:gnodet@redhat.com>
> Web: http://fusesource.com <http://fusesource.com/>
> Blog: http://gnodet.blogspot.com/
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message