karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <ben...@basistech.com>
Subject Re: What does effective:=active mean?
Date Wed, 31 Aug 2016 14:35:15 GMT
THANK YOU ALL!

On Wed, Aug 31, 2016 at 7:15 AM, Jean-Baptiste Onofré <jb@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é <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