Hi Markus,
yes, correct, copy-paste mistake ;)
Regards
JB
On 08/31/2016 04:28 PM, Markus Rathgeb wrote:
Hi,
osgi.service;effective:=active;objectClass=myService
IIRC have never seen "effective:=active" in the Provide-Capability section.
I only know about in the Require-Capability.
Are y
THANK YOU ALL!
On Wed, Aug 31, 2016 at 7:15 AM, Jean-Baptiste Onofré 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
Hi,
>
> osgi.service;effective:=active;objectClass=myService
>
IIRC have never seen "effective:=active" in the Provide-Capability section.
I only know about in the Require-Capability.
Are you sure this is required?
At least it works if it is missing for "provide".
Best regard,
Markus
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é m
Btw, if that's not sufficient, i.e. if some people have a need for
disabling only specific feature, please raise a JIRA and I can add the
flag on the repository / feature definition for 4.1.
Guillaume
2016-08-31 16:14 GMT+02:00 Guillaume Nodet :
> You can always disable service requirements glo
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é :
> Hi Benson,
>
> I agree: we had a long discussion with Guillaume about that in the past ;)
>
>
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, Benso
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. Th
2016-08-31 15:00 GMT+02:00 Benson Margulies :
> On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré
> 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 fo
Hi Benson,
See my comments inline:
On 08/31/2016 03:00 PM, Benson Margulies wrote:
On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré wrote:
So, I will explain a new time (for the third time ;)).
JB,
I apologize for not being awake when this came through before.
No worries, it was a j
On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré 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 menti
So, I will explain a new time (for the third time ;)).
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
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 c
13 matches
Mail list logo
