Re: Karaf 4.0.5 prerequisite feature not installed with correct version

[Guillaume Nodet]

Well, in the case of the feature:install command, this is true, i.e. if a
single version specified will install this specific version.

2016-09-01 4:00 GMT+02:00 oski_bear :

> FYI your  documentation  manual/latest/provisioning>
> does not reflect this. Here's a direct quote:
>
> "
> The feature with the highest version available in the range will be
> installed.
>
> If a single version is specified, this version will be chosen.
>
> If nothing is specified, the highest available will be installed.
> "
>
> At the very least this is misleading.
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Karaf-4-0-5-prerequisite-feature-not-installed-with-correct-version-
> tp4047753p4047797.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Karaf 4.0.6

[AndyPhillips404]

JB,
Any update on this?  Let me know if you would like me to help here.   

Thanks!
Andy P



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-4-0-6-tp4047757p4047796.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Application using Karaf - problems with packages not being exported by default configuration

[thully]

I created a few issues relating to this: KARAF-4689 for the custom.properties
option for additional packages, and KARAF-4688 for adding
netscape.javascript to the JRE 1.8+ exports. Also, KARAF-3596 was opened
previously (by someone else) regarding only part of Xerces being exposed in
bootdelegation - it seems some patches were proposed but hasn't seen a
response in over a year.

For now, I think we'll just copy the config.properties entries to
custom.properties...



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Application-using-Karaf-problems-with-packages-not-being-exported-by-default-configuration-tp4047592p4047795.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Problems with Karaf 4.0.5 vs. Karaf 4.0.4

[Jean-Baptiste Onofré]

I updated the Jira to include in Karaf 4.0.7.

Let me try to reproduce and investigate.

Regards
JB

On 08/31/2016 05:12 PM, kotoole wrote:

Any update on this? https://issues.apache.org/jira/browse/KARAF-4608

I was hopeful that https://issues.apache.org/jira/browse/ARIES-1540 would
fix the problem, but it does not appear so. Karaf 4.0.6 still exhibits the
same problem.

This is a showstopper issue for us.



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Problems-with-Karaf-4-0-5-vs-Karaf-4-0-4-tp4047129p4047788.html
Sent from the Karaf - User mailing list archive at Nabble.com.



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

Re: Problems with Karaf 4.0.5 vs. Karaf 4.0.4

[kotoole]

Any update on this? https://issues.apache.org/jira/browse/KARAF-4608

I was hopeful that https://issues.apache.org/jira/browse/ARIES-1540 would
fix the problem, but it does not appear so. Karaf 4.0.6 still exhibits the
same problem.

This is a showstopper issue for us. 



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Problems-with-Karaf-4-0-5-vs-Karaf-4-0-4-tp4047129p4047788.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: What does effective:=active mean?

[Jean-Baptiste Onofré]

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 you sure this is required?
At least it works if it is missing for "provide".

Best regard,
Markus



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

Re: What does effective:=active mean?

[Benson Margulies]

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 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 ;)
>>
>> 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
>> > wrote:
>>
>>
>>
>> 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 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:
>>
>> 
>> osgi.service;effective:=active;objectClass=myService
>> 
>>
>> On the other hand, the requirement header looks like:
>>
>>  

Re: What does effective:=active mean?

[Markus Rathgeb]

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

Re: What does effective:=active mean?

[Jean-Baptiste Onofré]

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é >:

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
> wrote:



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 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:


osgi.service;effective:=active;objectClass=myService


On the other hand, the requirement header looks like:



osgi.service;effective:=active;filter:="(objectClass=aService)"



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
   

Re: What does effective:=active mean?

[Guillaume Nodet]

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 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 ;)
>>
>> 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 
>>> wrote:
>>>


 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 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:
>>
>> 
>> osgi.service;effective:=active;objectClass=myService
>> 
>>
>> On the other hand, the requirement header looks like:
>>
>> 
>> osgi.service;effective:=active;filter:="(objectClass=aService)"
>> 
>>
>>
>> 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 

Re: What does effective:=active mean?

[Guillaume Nodet]

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 ;)
>
> 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 
>> wrote:
>>
>>>
>>>
>>> 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 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:
>
> 
> osgi.service;effective:=active;objectClass=myService
> 
>
> On the other hand, the requirement header looks like:
>
> 
> osgi.service;effective:=active;filter:="(objectClass=aService)"
> 
>
>
> 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 

Re: Inject system property value via blueprint

[Jean-Baptiste Onofré]

Hi,

you have to use the ext xmlns for that.

Just add the following in your blueprint:

 placeholder-prefix="$[" placeholder-suffix="]" />


Then, you can use system properties with $[foo].

Regards
JB

On 08/31/2016 03:46 PM, ellirael wrote:

I saw an example how to inject property values which are defined in config
file.
It is some thing like this:












How to do the same with the system property printed by system:property
command output?
Or how to gain access to those system properties values?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Inject-system-property-value-via-blueprint-tp4047779.html
Sent from the Karaf - User mailing list archive at Nabble.com.



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

Re: What does effective:=active mean?

[Jean-Baptiste Onofré]

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  wrote:



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 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:


osgi.service;effective:=active;objectClass=myService


On the other hand, the requirement header looks like:


osgi.service;effective:=active;filter:="(objectClass=aService)"



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 

Re: What does effective:=active mean?

[Benson Margulies]

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  wrote:
>
>
> 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 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:
>> >
>> > 
>> > osgi.service;effective:=active;objectClass=myService
>> > 
>> >
>> > On the other hand, the requirement header looks like:
>> >
>> > 
>> > osgi.service;effective:=active;filter:="(objectClass=aService)"
>> > 
>> >
>> >
>> > 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;
>> >> 

Re: What does effective:=active mean?

[Jean-Baptiste Onofré]

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 joke ;)



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?


Correct.



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?


An alternative to the bundle itself is to set the capability at feature 
level. The features XML can provide the capability (if the bundles don't):



  ...
  
osgi.service;effective:=active;objectClass=myService
  


Regards
JB



Perhaps I can persuade BND not to list them as requirements.

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:


osgi.service;effective:=active;objectClass=myService


On the other hand, the requirement header looks like:


osgi.service;effective:=active;filter:="(objectClass=aService)"



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.v2016083117,1.2.6.v2016083117]";
resolution:=mandatory [caused by: Unable to resolve
com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v2016083117:
missing requirement
[com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v2016083117]
osgi.service;
filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
effective:=active]]]



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


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

Re: What does effective:=active mean?

[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 following this. The
resolver is requiring that some bundle mentions the service in a
Provide-Capability -- NOT that the service is actually running?

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?

Perhaps I can persuade BND not to list them as requirements.

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:
>
> 
> osgi.service;effective:=active;objectClass=myService
> 
>
> On the other hand, the requirement header looks like:
>
> 
> osgi.service;effective:=active;filter:="(objectClass=aService)"
> 
>
>
> 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.v2016083117,1.2.6.v2016083117]";
>> resolution:=mandatory [caused by: Unable to resolve
>> com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v2016083117:
>> missing requirement
>> [com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v2016083117]
>> osgi.service;
>> filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
>> effective:=active]]]
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: What does effective:=active mean?

[Jean-Baptiste Onofré]

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 "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:


osgi.service;effective:=active;objectClass=myService


On the other hand, the requirement header looks like:


osgi.service;effective:=active;filter:="(objectClass=aService)"



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.v2016083117,1.2.6.v2016083117]";
resolution:=mandatory [caused by: Unable to resolve
com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v2016083117:
missing requirement
[com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v2016083117]
osgi.service; 
filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
effective:=active]]]



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

What does effective:=active mean?

[Benson Margulies]

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.v2016083117,1.2.6.v2016083117]";
resolution:=mandatory [caused by: Unable to resolve
com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v2016083117:
missing requirement
[com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v2016083117]
osgi.service; 
filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
effective:=active]]]

Re: Application using Karaf - problems with packages not being exported by default configuration

[Guillaume Nodet]

Yeah, maybe the properties in etc/config.properties should include an
additional property that would be taken from etc/custom.properties so that
it would be much easier to add stuff.
Please raise a JIRA if you think that would suit your needs.

2016-08-31 0:48 GMT+02:00 thully :

> I figured out why that was happening - it turns out we had packages listed
> in
> org.osgi.framework.system.packages.extra in custom.properties that were
> overriding the defaults in config.properties. As such, Xerces was never
> being exported, and org.apache.xerces.util isn't in boot delegation so we
> can't get access to it that way. Once I moved the custom additions to
> org.osgi.framework.system.packages.extra from custom.properties to
> config.properties, the bundle worked.
>
> With that said, what would be the best practice as far as adding system
> packages to a custom Karaf distribution and preserving the defaults? It
> seems someone added these to our custom.properties a long time ago, and I
> suspect they didn't realize it would prevent the defaults from being
> exported (we can into the same issue with sun.* packages and bootdelegation
> a while back).
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Application-using-Karaf-problems-with-packages-not-
> being-exported-by-default-configuration-tp4047592p4047767.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/