Re: Decanter log appender properties

[Jean-Baptiste Onofré]

Hi,

You are right, currently the custom properties are static in the 
ConfigAdmin configuration.


You can always update ConfigAdmin properties programmatically but it 
will restart the collector (so, not so good).


In the case of the log collector, I would recommend to use MDC: with MDC 
you can add any property that will be part of the collected event.


Anyway, let me think about a way to generally add dynamic custom properties.

Regards
JB

On 09/29/2016 06:49 PM, 414n wrote:

Greetings,I'm currently testing out Decanter as a monitoring solution for
Karaf and so far so good.What I'd like to do is to append custom properties
to the data sent over from the collectors to the appender, but I didn't find
a reliable way to do it.Looking at the  log collector code

, I saw that if there are component properties defined these get sent too
alongside the "static ones" like timestamp, loggername, message etc.I tried
injecting the custom properties I would like to send programmatically using
the ConfigAdmin service to no avail. Only by setting a static property
inside the feature.xml of my bundles I was able to see it on the appender
side:However, the property I'm trying to send are dynamic in nature and
cannot be put in static configuration files.The way I'm using the
ConfigAdmin service is this:Can anybody please tell me what I'm doing wrong?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Decanter-log-appender-properties-tp4048206.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: Questions about OSGi

[Sigmund Lee]

Hi David,

Thank you so much for clearing things up.

So there is no exception for any namespace, headers like Export-Package,
Import-Package, Require-Bundle, etc... exists only because they are far
more earlier imported than the more generic Provide-Capability &
Require-Capability headers, even though they are parts of
requirements/capabilities model?
It's definitely worth clarifying this on the OSGi specifications.


Regards,
Sig

Decanter log appender properties

[414n]

Greetings,I'm currently testing out Decanter as a monitoring solution for
Karaf and so far so good.What I'd like to do is to append custom properties
to the data sent over from the collectors to the appender, but I didn't find
a reliable way to do it.Looking at the  log collector code

 
, I saw that if there are component properties defined these get sent too
alongside the "static ones" like timestamp, loggername, message etc.I tried
injecting the custom properties I would like to send programmatically using
the ConfigAdmin service to no avail. Only by setting a static property
inside the feature.xml of my bundles I was able to see it on the appender
side:However, the property I'm trying to send are dynamic in nature and
cannot be put in static configuration files.The way I'm using the
ConfigAdmin service is this:Can anybody please tell me what I'm doing wrong?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Decanter-log-appender-properties-tp4048206.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Prerequisites amongst boot features

[Guillaume Nodet]

2016-09-29 16:39 GMT+02:00 Benson Margulies :

> On Thu, Sep 29, 2016 at 10:36 AM, Guillaume Nodet 
> wrote:
> >
> >
> > 2016-09-29 16:22 GMT+02:00 Benson Margulies :
> >>
> >> On Thu, Sep 29, 2016 at 10:12 AM, Guillaume Nodet 
> >> wrote:
> >> > Manually maintaining the feature set is not something you should do.
> >> > Please raise a JIRA and attach a test case if you can produce one (an
> >> > integration test for the plugin would be awesome) : that's not really
> >> > supported I think.
> >> > As a workaround, I would suggest you force the
> rosapi-worker-flinx-sdk
> >> > to
> >> > be in the startup stage.
> >>
> >> OK, can you tell me how to do that in the configuration of the
> >> karaf-maven-plugin?
> >
> >
> >> 
> >> rosapi-worker-flinx-sdk
> >> 
> >
> >
> >>
> >> >
> >> > You really need this dependency as a prerequisite, right ?  The only
> >> > real
> >> > use case is for URL handlers used inside feature definitions.
> Anything
> >> > related to the wiring (packages, services, etc...) does not need to
> be a
> >> > prerequisite.
> >>
> >> As I tried to explain, this results from a mistake. We have a few
> >> bundles with activators that try to obtain services from other
> >> bundles, without properly accounting for indefinite startup order. I
> >> have code changes in train to use DS properly to fix this; these
> >> bundles were written some time ago when we barely understood OSGi.
> >>
> >> My foray into prerequisites is entirely a matter of trying to work
> >> around until the DS changes are in place. I am making a small
> >> experiment with start-level now since the prerequisite approach seems
> >> a bit, well, fraught.
> >>
> >> I will try to find time to make you a test case, it does appear as if
> >> it takes a somewhat complex collection of features and dependencies to
> >> elicit this problem, so it might take me a while.
> >>
> >> I might be able to describe the situation in a way that sheds some
> >> light for you in the interim:
> >>
> >> Feature Q declares feature R as a prerequisite.
> >>
> >> Feature R declares Feature S as an ordinary dependency
> >> (S).
> >>
> >> Feature S includes a bundle that imports javax.servlet, but does not
> >> include a bundle that exports javax.servlet. Instead, it normally gets
> >> that package from pax-jetty, which is not declared as a feature
> >> dependency at all. It's just included in the assembly.
> >>
> >> Maybe I should ask this question: if _all_ I need to control is
> >> startup order, and not wiring order, is 'prerequisite' even what I'm
> >> supposed to do?
> >
> >
> > Definitely not.  I'm not even sure that would work during the boot
> because
> > the bundles part of the prerequisite feature may not even start if the
> start
> > level is too high.
> > So if you're problem is start order of the bundles, use the start level
> on
> > bundles.
> >
> > Fwiw, if feature S requires javax.servlet, it would be better to add that
> > bundle as a xxx or have a  > dependency="true">http.  There's very few valid reason why a
> > feature should not be transitively closed.
>
> I will close this thread for now (as far as I am concerned) by merely
> observing that when you use the maven plugin to build your features,
> there are many opportunities to fail to do this.  Thanks again for all
> the help.
>

Right, I don't really personally recommend to use the maven plugin to
generate the feature files, I agree there's too many things that can go
wrong.
I usually write the features manually and validate them using the maven
plugin.  Once they are validated, the maven plugin can usually build custom
distributions quite easily.


>
> >
> >>
> >>
> >> Thanks,
> >>
> >> benson
> >>
> >>
> >>
> >>
> >>
> >> >
> >> >
> >> > 2016-09-29 16:08 GMT+02:00 Benson Margulies :
> >> >>
> >> >> On Thu, Sep 29, 2016 at 10:05 AM, Jean-Baptiste Onofré
> >> >> 
> >> >> wrote:
> >> >> > Actually, you are using multi-stage: stage1 is (wrap) and stage2 is
> >> >> > all
> >> >> > the
> >> >> > rest.
> >> >> >
> >> >> > I would recommend to group all dependency features in stage1 and
> the
> >> >> > rest in
> >> >> > stage2.
> >> >>
> >> >> How can I do that while still using the karaf-maven-plugin to write
> >> >> this file for me? Do I have to give up and manually maintain that
> >> >> property?
> >> >>
> >> >> Would the syntax be (a,b,c,d),e,g,f?
> >> >>
> >> >> thanks,
> >> >> benson
> >> >>
> >> >>
> >> >>
> >> >> >
> >> >> > Regards
> >> >> > JB
> >> >> >
> >> >> >
> >> >> > On 09/29/2016 03:54 PM, Benson Margulies wrote:
> >> >> >>
> >> >> >> Hi JB,
> >> >> >>
> >> >> >> I let the maven plugin write org.apache.karaf.features.cfg, so I
> >> >> >> don't
> >> >> >> know, to be honest, if I'm using multi-stage.
> >> >> >>
> >> >> >> _Without_ the failing prerequisites, I have the following content
> of
> >> >> >> org.apache.karaf.features.cfg. I'm using 

Re: Prerequisites amongst boot features

[Benson Margulies]

On Thu, Sep 29, 2016 at 10:36 AM, Guillaume Nodet  wrote:
>
>
> 2016-09-29 16:22 GMT+02:00 Benson Margulies :
>>
>> On Thu, Sep 29, 2016 at 10:12 AM, Guillaume Nodet 
>> wrote:
>> > Manually maintaining the feature set is not something you should do.
>> > Please raise a JIRA and attach a test case if you can produce one (an
>> > integration test for the plugin would be awesome) : that's not really
>> > supported I think.
>> > As a workaround, I would suggest you force the  rosapi-worker-flinx-sdk
>> > to
>> > be in the startup stage.
>>
>> OK, can you tell me how to do that in the configuration of the
>> karaf-maven-plugin?
>
>
>> 
>> rosapi-worker-flinx-sdk
>> 
>
>
>>
>> >
>> > You really need this dependency as a prerequisite, right ?  The only
>> > real
>> > use case is for URL handlers used inside feature definitions.  Anything
>> > related to the wiring (packages, services, etc...) does not need to be a
>> > prerequisite.
>>
>> As I tried to explain, this results from a mistake. We have a few
>> bundles with activators that try to obtain services from other
>> bundles, without properly accounting for indefinite startup order. I
>> have code changes in train to use DS properly to fix this; these
>> bundles were written some time ago when we barely understood OSGi.
>>
>> My foray into prerequisites is entirely a matter of trying to work
>> around until the DS changes are in place. I am making a small
>> experiment with start-level now since the prerequisite approach seems
>> a bit, well, fraught.
>>
>> I will try to find time to make you a test case, it does appear as if
>> it takes a somewhat complex collection of features and dependencies to
>> elicit this problem, so it might take me a while.
>>
>> I might be able to describe the situation in a way that sheds some
>> light for you in the interim:
>>
>> Feature Q declares feature R as a prerequisite.
>>
>> Feature R declares Feature S as an ordinary dependency
>> (S).
>>
>> Feature S includes a bundle that imports javax.servlet, but does not
>> include a bundle that exports javax.servlet. Instead, it normally gets
>> that package from pax-jetty, which is not declared as a feature
>> dependency at all. It's just included in the assembly.
>>
>> Maybe I should ask this question: if _all_ I need to control is
>> startup order, and not wiring order, is 'prerequisite' even what I'm
>> supposed to do?
>
>
> Definitely not.  I'm not even sure that would work during the boot because
> the bundles part of the prerequisite feature may not even start if the start
> level is too high.
> So if you're problem is start order of the bundles, use the start level on
> bundles.
>
> Fwiw, if feature S requires javax.servlet, it would be better to add that
> bundle as a xxx or have a  dependency="true">http.  There's very few valid reason why a
> feature should not be transitively closed.

I will close this thread for now (as far as I am concerned) by merely
observing that when you use the maven plugin to build your features,
there are many opportunities to fail to do this.  Thanks again for all
the help.


>
>>
>>
>> Thanks,
>>
>> benson
>>
>>
>>
>>
>>
>> >
>> >
>> > 2016-09-29 16:08 GMT+02:00 Benson Margulies :
>> >>
>> >> On Thu, Sep 29, 2016 at 10:05 AM, Jean-Baptiste Onofré
>> >> 
>> >> wrote:
>> >> > Actually, you are using multi-stage: stage1 is (wrap) and stage2 is
>> >> > all
>> >> > the
>> >> > rest.
>> >> >
>> >> > I would recommend to group all dependency features in stage1 and the
>> >> > rest in
>> >> > stage2.
>> >>
>> >> How can I do that while still using the karaf-maven-plugin to write
>> >> this file for me? Do I have to give up and manually maintain that
>> >> property?
>> >>
>> >> Would the syntax be (a,b,c,d),e,g,f?
>> >>
>> >> thanks,
>> >> benson
>> >>
>> >>
>> >>
>> >> >
>> >> > Regards
>> >> > JB
>> >> >
>> >> >
>> >> > On 09/29/2016 03:54 PM, Benson Margulies wrote:
>> >> >>
>> >> >> Hi JB,
>> >> >>
>> >> >> I let the maven plugin write org.apache.karaf.features.cfg, so I
>> >> >> don't
>> >> >> know, to be honest, if I'm using multi-stage.
>> >> >>
>> >> >> _Without_ the failing prerequisites, I have the following content of
>> >> >> org.apache.karaf.features.cfg. I'm using the property editor feature
>> >> >> to turn off capability enforcement.
>> >> >>
>> >> >>
>> >> >> rosapi-all-sdks is just a bag of  declarations for other
>> >> >> features. Things break when I try to make one of them a prerequisite
>> >> >> of another. My problem is really to prevent the activation of a few
>> >> >> bundles until another bundle is safely under control, and I am
>> >> >> hoping
>> >> >> for a workaround in the interim until we can really fix this with DS
>> >> >> in a few weeks.
>> >> >>
>> >> >>
>> >> >> #Modified by org.apache.karaf.tools.utils.KarafPropertiesFile
>> >> >> #Thu Sep 29 09:49:19 EDT 2016
>> >> >> featuresBootAsynchronous=false
>> >> >> 

Re: Prerequisites amongst boot features

[Guillaume Nodet]

2016-09-29 16:22 GMT+02:00 Benson Margulies :

> On Thu, Sep 29, 2016 at 10:12 AM, Guillaume Nodet 
> wrote:
> > Manually maintaining the feature set is not something you should do.
> > Please raise a JIRA and attach a test case if you can produce one (an
> > integration test for the plugin would be awesome) : that's not really
> > supported I think.
> > As a workaround, I would suggest you force the  rosapi-worker-flinx-sdk
> to
> > be in the startup stage.
>
> OK, can you tell me how to do that in the configuration of the
> karaf-maven-plugin?
>


> rosapi-worker-flinx-sdk
> 
>
>

> >
> > You really need this dependency as a prerequisite, right ?  The only real
> > use case is for URL handlers used inside feature definitions.  Anything
> > related to the wiring (packages, services, etc...) does not need to be a
> > prerequisite.
>
> As I tried to explain, this results from a mistake. We have a few
> bundles with activators that try to obtain services from other
> bundles, without properly accounting for indefinite startup order. I
> have code changes in train to use DS properly to fix this; these
> bundles were written some time ago when we barely understood OSGi.
>
> My foray into prerequisites is entirely a matter of trying to work
> around until the DS changes are in place. I am making a small
> experiment with start-level now since the prerequisite approach seems
> a bit, well, fraught.
>
> I will try to find time to make you a test case, it does appear as if
> it takes a somewhat complex collection of features and dependencies to
> elicit this problem, so it might take me a while.
>
> I might be able to describe the situation in a way that sheds some
> light for you in the interim:
>
> Feature Q declares feature R as a prerequisite.
>
> Feature R declares Feature S as an ordinary dependency
> (S).
>
> Feature S includes a bundle that imports javax.servlet, but does not
> include a bundle that exports javax.servlet. Instead, it normally gets
> that package from pax-jetty, which is not declared as a feature
> dependency at all. It's just included in the assembly.
>
> Maybe I should ask this question: if _all_ I need to control is
> startup order, and not wiring order, is 'prerequisite' even what I'm
> supposed to do?
>

Definitely not.  I'm not even sure that would work during the boot because
the bundles part of the prerequisite feature may not even start if the
start level is too high.
So if you're problem is start order of the bundles, use the start level on
bundles.

Fwiw, if feature S requires javax.servlet, it would be better to add that
bundle as a xxx or have a http.  There's very few valid reason why a
feature should not be transitively closed.


>
> Thanks,
>
> benson
>
>
>
>
>
> >
> >
> > 2016-09-29 16:08 GMT+02:00 Benson Margulies :
> >>
> >> On Thu, Sep 29, 2016 at 10:05 AM, Jean-Baptiste Onofré  >
> >> wrote:
> >> > Actually, you are using multi-stage: stage1 is (wrap) and stage2 is
> all
> >> > the
> >> > rest.
> >> >
> >> > I would recommend to group all dependency features in stage1 and the
> >> > rest in
> >> > stage2.
> >>
> >> How can I do that while still using the karaf-maven-plugin to write
> >> this file for me? Do I have to give up and manually maintain that
> >> property?
> >>
> >> Would the syntax be (a,b,c,d),e,g,f?
> >>
> >> thanks,
> >> benson
> >>
> >>
> >>
> >> >
> >> > Regards
> >> > JB
> >> >
> >> >
> >> > On 09/29/2016 03:54 PM, Benson Margulies wrote:
> >> >>
> >> >> Hi JB,
> >> >>
> >> >> I let the maven plugin write org.apache.karaf.features.cfg, so I
> don't
> >> >> know, to be honest, if I'm using multi-stage.
> >> >>
> >> >> _Without_ the failing prerequisites, I have the following content of
> >> >> org.apache.karaf.features.cfg. I'm using the property editor feature
> >> >> to turn off capability enforcement.
> >> >>
> >> >>
> >> >> rosapi-all-sdks is just a bag of  declarations for other
> >> >> features. Things break when I try to make one of them a prerequisite
> >> >> of another. My problem is really to prevent the activation of a few
> >> >> bundles until another bundle is safely under control, and I am hoping
> >> >> for a workaround in the interim until we can really fix this with DS
> >> >> in a few weeks.
> >> >>
> >> >>
> >> >> #Modified by org.apache.karaf.tools.utils.KarafPropertiesFile
> >> >> #Thu Sep 29 09:49:19 EDT 2016
> >> >> featuresBootAsynchronous=false
> >> >> serviceRequirements=disable
> >> >> featuresBoot = \
> >> >> (wrap), \
> >> >> log, \
> >> >> rosapi-front-end-anvils-transport, \
> >> >> bean-validation-support, \
> >> >> rosapi-worker-common, \
> >> >> ssh, \
> >> >> rosapi-front-end-logstash-request-tracker, \
> >> >> rosapi-front-end-service, \
> >> >> aries-blueprint, \
> >> >> feature, \
> >> >> jaas, \
> >> >> diagnostic, \
> >> >> rosapi-worker-download-text-extraction-component, \
> 

Re: Prerequisites amongst boot features

[Benson Margulies]

On Thu, Sep 29, 2016 at 10:12 AM, Guillaume Nodet  wrote:
> Manually maintaining the feature set is not something you should do.
> Please raise a JIRA and attach a test case if you can produce one (an
> integration test for the plugin would be awesome) : that's not really
> supported I think.
> As a workaround, I would suggest you force the  rosapi-worker-flinx-sdk to
> be in the startup stage.

OK, can you tell me how to do that in the configuration of the
karaf-maven-plugin?

>
> You really need this dependency as a prerequisite, right ?  The only real
> use case is for URL handlers used inside feature definitions.  Anything
> related to the wiring (packages, services, etc...) does not need to be a
> prerequisite.

As I tried to explain, this results from a mistake. We have a few
bundles with activators that try to obtain services from other
bundles, without properly accounting for indefinite startup order. I
have code changes in train to use DS properly to fix this; these
bundles were written some time ago when we barely understood OSGi.

My foray into prerequisites is entirely a matter of trying to work
around until the DS changes are in place. I am making a small
experiment with start-level now since the prerequisite approach seems
a bit, well, fraught.

I will try to find time to make you a test case, it does appear as if
it takes a somewhat complex collection of features and dependencies to
elicit this problem, so it might take me a while.

I might be able to describe the situation in a way that sheds some
light for you in the interim:

Feature Q declares feature R as a prerequisite.

Feature R declares Feature S as an ordinary dependency (S).

Feature S includes a bundle that imports javax.servlet, but does not
include a bundle that exports javax.servlet. Instead, it normally gets
that package from pax-jetty, which is not declared as a feature
dependency at all. It's just included in the assembly.

Maybe I should ask this question: if _all_ I need to control is
startup order, and not wiring order, is 'prerequisite' even what I'm
supposed to do?

Thanks,

benson





>
>
> 2016-09-29 16:08 GMT+02:00 Benson Margulies :
>>
>> On Thu, Sep 29, 2016 at 10:05 AM, Jean-Baptiste Onofré 
>> wrote:
>> > Actually, you are using multi-stage: stage1 is (wrap) and stage2 is all
>> > the
>> > rest.
>> >
>> > I would recommend to group all dependency features in stage1 and the
>> > rest in
>> > stage2.
>>
>> How can I do that while still using the karaf-maven-plugin to write
>> this file for me? Do I have to give up and manually maintain that
>> property?
>>
>> Would the syntax be (a,b,c,d),e,g,f?
>>
>> thanks,
>> benson
>>
>>
>>
>> >
>> > Regards
>> > JB
>> >
>> >
>> > On 09/29/2016 03:54 PM, Benson Margulies wrote:
>> >>
>> >> Hi JB,
>> >>
>> >> I let the maven plugin write org.apache.karaf.features.cfg, so I don't
>> >> know, to be honest, if I'm using multi-stage.
>> >>
>> >> _Without_ the failing prerequisites, I have the following content of
>> >> org.apache.karaf.features.cfg. I'm using the property editor feature
>> >> to turn off capability enforcement.
>> >>
>> >>
>> >> rosapi-all-sdks is just a bag of  declarations for other
>> >> features. Things break when I try to make one of them a prerequisite
>> >> of another. My problem is really to prevent the activation of a few
>> >> bundles until another bundle is safely under control, and I am hoping
>> >> for a workaround in the interim until we can really fix this with DS
>> >> in a few weeks.
>> >>
>> >>
>> >> #Modified by org.apache.karaf.tools.utils.KarafPropertiesFile
>> >> #Thu Sep 29 09:49:19 EDT 2016
>> >> featuresBootAsynchronous=false
>> >> serviceRequirements=disable
>> >> featuresBoot = \
>> >> (wrap), \
>> >> log, \
>> >> rosapi-front-end-anvils-transport, \
>> >> bean-validation-support, \
>> >> rosapi-worker-common, \
>> >> ssh, \
>> >> rosapi-front-end-logstash-request-tracker, \
>> >> rosapi-front-end-service, \
>> >> aries-blueprint, \
>> >> feature, \
>> >> jaas, \
>> >> diagnostic, \
>> >> rosapi-worker-download-text-extraction-component, \
>> >> rosapi-front-end-null-request-tracker, \
>> >> bundle, \
>> >> rosapi-all-sdks, \
>> >> rosapi-front-end-local-usage-tracker, \
>> >> package, \
>> >> scr, \
>> >> rosapi-common, \
>> >> cxf-jaxrs, \
>> >> rosette-api, \
>> >> rosapi-front-end-embedded-transport, \
>> >> system, \
>> >> shell, \
>> >> shell-compat, \
>> >> config
>> >> featuresRepositories = \
>> >> mvn:com.basistech.ws/rosapi-features/1.5.0-SNAPSHOT/xml/features, \
>> >> mvn:org.apache.karaf.features/standard/4.0.6/xml/features, \
>> >> mvn:org.apache.cxf.karaf/apache-cxf/3.1.4/xml/features, \
>> >> mvn:org.apache.karaf.features/framework/4.0.6/xml/features
>> >>
>> >>
>> >> On Thu, Sep 29, 2016 at 9:47 AM, Jean-Baptiste Onofré 

Re: Prerequisites amongst boot features

[Benson Margulies]

On Thu, Sep 29, 2016 at 10:05 AM, Jean-Baptiste Onofré  
wrote:
> Actually, you are using multi-stage: stage1 is (wrap) and stage2 is all the
> rest.
>
> I would recommend to group all dependency features in stage1 and the rest in
> stage2.

How can I do that while still using the karaf-maven-plugin to write
this file for me? Do I have to give up and manually maintain that
property?

Would the syntax be (a,b,c,d),e,g,f?

thanks,
benson



>
> Regards
> JB
>
>
> On 09/29/2016 03:54 PM, Benson Margulies wrote:
>>
>> Hi JB,
>>
>> I let the maven plugin write org.apache.karaf.features.cfg, so I don't
>> know, to be honest, if I'm using multi-stage.
>>
>> _Without_ the failing prerequisites, I have the following content of
>> org.apache.karaf.features.cfg. I'm using the property editor feature
>> to turn off capability enforcement.
>>
>>
>> rosapi-all-sdks is just a bag of  declarations for other
>> features. Things break when I try to make one of them a prerequisite
>> of another. My problem is really to prevent the activation of a few
>> bundles until another bundle is safely under control, and I am hoping
>> for a workaround in the interim until we can really fix this with DS
>> in a few weeks.
>>
>>
>> #Modified by org.apache.karaf.tools.utils.KarafPropertiesFile
>> #Thu Sep 29 09:49:19 EDT 2016
>> featuresBootAsynchronous=false
>> serviceRequirements=disable
>> featuresBoot = \
>> (wrap), \
>> log, \
>> rosapi-front-end-anvils-transport, \
>> bean-validation-support, \
>> rosapi-worker-common, \
>> ssh, \
>> rosapi-front-end-logstash-request-tracker, \
>> rosapi-front-end-service, \
>> aries-blueprint, \
>> feature, \
>> jaas, \
>> diagnostic, \
>> rosapi-worker-download-text-extraction-component, \
>> rosapi-front-end-null-request-tracker, \
>> bundle, \
>> rosapi-all-sdks, \
>> rosapi-front-end-local-usage-tracker, \
>> package, \
>> scr, \
>> rosapi-common, \
>> cxf-jaxrs, \
>> rosette-api, \
>> rosapi-front-end-embedded-transport, \
>> system, \
>> shell, \
>> shell-compat, \
>> config
>> featuresRepositories = \
>> mvn:com.basistech.ws/rosapi-features/1.5.0-SNAPSHOT/xml/features, \
>> mvn:org.apache.karaf.features/standard/4.0.6/xml/features, \
>> mvn:org.apache.cxf.karaf/apache-cxf/3.1.4/xml/features, \
>> mvn:org.apache.karaf.features/framework/4.0.6/xml/features
>>
>>
>> On Thu, Sep 29, 2016 at 9:47 AM, Jean-Baptiste Onofré 
>> wrote:
>>>
>>> Hi Benson,
>>>
>>> do you use multi-stage in featuresBoot ?
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 09/29/2016 03:33 PM, Benson Margulies wrote:


 Folks,

 I build an assembly in which all the feature are boot features,
 because they are all going to be used.

 When I try to make one of them a prerequisite of another, I get a
 wiring error, because, apparently, the dependency tree at the package
 level is not being respected in wiring the bundles.

 All of this is a temporary stopgap until some components get correct
 DS @Reference dependencies, which some of them lack.

 Questions: Am I making an error using boot features? I realize that
 this report lacks specificity. I could try to build up a model on
 github.

 TIA,
 benson

>>>
>>> --
>>> 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: Prerequisites amongst boot features

[Jean-Baptiste Onofré]

Actually, you are using multi-stage: stage1 is (wrap) and stage2 is all 
the rest.


I would recommend to group all dependency features in stage1 and the 
rest in stage2.


Regards
JB

On 09/29/2016 03:54 PM, Benson Margulies wrote:

Hi JB,

I let the maven plugin write org.apache.karaf.features.cfg, so I don't
know, to be honest, if I'm using multi-stage.

_Without_ the failing prerequisites, I have the following content of
org.apache.karaf.features.cfg. I'm using the property editor feature
to turn off capability enforcement.


rosapi-all-sdks is just a bag of  declarations for other
features. Things break when I try to make one of them a prerequisite
of another. My problem is really to prevent the activation of a few
bundles until another bundle is safely under control, and I am hoping
for a workaround in the interim until we can really fix this with DS
in a few weeks.


#Modified by org.apache.karaf.tools.utils.KarafPropertiesFile
#Thu Sep 29 09:49:19 EDT 2016
featuresBootAsynchronous=false
serviceRequirements=disable
featuresBoot = \
(wrap), \
log, \
rosapi-front-end-anvils-transport, \
bean-validation-support, \
rosapi-worker-common, \
ssh, \
rosapi-front-end-logstash-request-tracker, \
rosapi-front-end-service, \
aries-blueprint, \
feature, \
jaas, \
diagnostic, \
rosapi-worker-download-text-extraction-component, \
rosapi-front-end-null-request-tracker, \
bundle, \
rosapi-all-sdks, \
rosapi-front-end-local-usage-tracker, \
package, \
scr, \
rosapi-common, \
cxf-jaxrs, \
rosette-api, \
rosapi-front-end-embedded-transport, \
system, \
shell, \
shell-compat, \
config
featuresRepositories = \
mvn:com.basistech.ws/rosapi-features/1.5.0-SNAPSHOT/xml/features, \
mvn:org.apache.karaf.features/standard/4.0.6/xml/features, \
mvn:org.apache.cxf.karaf/apache-cxf/3.1.4/xml/features, \
mvn:org.apache.karaf.features/framework/4.0.6/xml/features


On Thu, Sep 29, 2016 at 9:47 AM, Jean-Baptiste Onofré  wrote:

Hi Benson,

do you use multi-stage in featuresBoot ?

Regards
JB


On 09/29/2016 03:33 PM, Benson Margulies wrote:


Folks,

I build an assembly in which all the feature are boot features,
because they are all going to be used.

When I try to make one of them a prerequisite of another, I get a
wiring error, because, apparently, the dependency tree at the package
level is not being respected in wiring the bundles.

All of this is a temporary stopgap until some components get correct
DS @Reference dependencies, which some of them lack.

Questions: Am I making an error using boot features? I realize that
this report lacks specificity. I could try to build up a model on
github.

TIA,
benson



--
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: Prerequisites amongst boot features

[Benson Margulies]

On Thu, Sep 29, 2016 at 10:04 AM, Benson Margulies  wrote:
> rosapi-worker-flinx-sdk


to be clear, rosapi-worker-flinx-sdk is the name of the feature that I
listed as a prerequisite of another feature.

And the featuresBoot when this failure is happening is:

featuresBoot = \
log, \
rosapi-front-end-anvils-transport, \
bean-validation-support, \
rosapi-worker-common, \
ssh, \
rosapi-front-end-logstash-request-tracker, \
rosapi-front-end-service, \
aries-blueprint, \
feature, \
jaas, \
diagnostic, \
rosapi-worker-download-text-extraction-component, \
rosapi-front-end-null-request-tracker, \
bundle, \
rosapi-all-sdks, \
rosapi-front-end-local-usage-tracker, \
package, \
scr, \
rosapi-common, \
cxf-jaxrs, \
rosette-api, \
rosapi-front-end-embedded-transport, \
system, \
shell, \
shell-compat, \
config, \
wrap

Re: Prerequisites amongst boot features

[Benson Margulies]

And it hangs. It never reaches command level, and it never exits.

If I force a javax.servlet bundle into the situation, I start getting
similar complaints about the package that contains the DS annotations.


➜ rosapi1.5-master git:(dummy) ✗ assemblies/full-test/target/assembly/bin/karaf
2016-09-29 10:03:04,585 | ERROR | pool-6-thread-1  |
org.apache.karaf.features.internal.service.BootFeaturesInstaller |
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-worker-flinx-sdk; type=karaf.feature; version=0;
filter:="(&(osgi.identity=rosapi-worker-flinx-sdk)(type=karaf.feature)(version>=0.0.0))"
[caused by: Unable to resolve rosapi-worker-flinx-sdk/1.5.0.SNAPSHOT:
missing requirement [rosapi-worker-flinx-sdk/1.5.0.SNAPSHOT]
osgi.identity; osgi.identity=rosapi-common; type=karaf.feature [caused
by: Unable to resolve rosapi-common/1.5.0.SNAPSHOT: missing
requirement [rosapi-common/1.5.0.SNAPSHOT] osgi.identity;
osgi.identity=io.dropwizard.metrics.servlets; type=osgi.bundle;
version="[3.1.2,3.1.2]"; resolution:=mandatory [caused by: Unable to
resolve io.dropwizard.metrics.servlets/3.1.2: missing requirement
[io.dropwizard.metrics.servlets/3.1.2] osgi.wiring.package;
filter:="(&(osgi.wiring.package=javax.servlet)(version>=2.5.0)(!(version>=4.0.0)))"]]]
at 
org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:235)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:158)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:259)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[6:org.apache.karaf.features.core:4.0.6]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]

On Thu, Sep 29, 2016 at 9:56 AM, Guillaume Nodet  wrote:
> Would you mind pasting the stack trace of the error you have please ?
>
>
> 2016-09-29 15:54 GMT+02:00 Benson Margulies :
>>
>> Hi JB,
>>
>> I let the maven plugin write org.apache.karaf.features.cfg, so I don't
>> know, to be honest, if I'm using multi-stage.
>>
>> _Without_ the failing prerequisites, I have the following content of
>> org.apache.karaf.features.cfg. I'm using the property editor feature
>> to turn off capability enforcement.
>>
>>
>> rosapi-all-sdks is just a bag of  declarations for other
>> features. Things break when I try to make one of them a prerequisite
>> of another. My problem is really to prevent the activation of a few
>> bundles until another bundle is safely under control, and I am hoping
>> for a workaround in the interim until we can really fix this with DS
>> in a few weeks.
>>
>>
>> #Modified by org.apache.karaf.tools.utils.KarafPropertiesFile
>> #Thu Sep 29 09:49:19 EDT 2016
>> featuresBootAsynchronous=false
>> serviceRequirements=disable
>> featuresBoot = \
>> (wrap), \
>> log, \
>> rosapi-front-end-anvils-transport, \
>> bean-validation-support, \
>> rosapi-worker-common, \
>> ssh, \
>> rosapi-front-end-logstash-request-tracker, \
>> rosapi-front-end-service, \
>> aries-blueprint, \
>> feature, \
>> jaas, \
>> diagnostic, \
>> rosapi-worker-download-text-extraction-component, \
>> rosapi-front-end-null-request-tracker, \
>> bundle, \
>> rosapi-all-sdks, \
>> rosapi-front-end-local-usage-tracker, \
>> package, \
>> scr, \
>> rosapi-common, \
>> cxf-jaxrs, \
>> rosette-api, \
>> rosapi-front-end-embedded-transport, \
>> system, \
>> shell, \
>> shell-compat, \
>> config
>> featuresRepositories = \
>> mvn:com.basistech.ws/rosapi-features/1.5.0-SNAPSHOT/xml/features, \
>> mvn:org.apache.karaf.features/standard/4.0.6/xml/features, \
>> mvn:org.apache.cxf.karaf/apache-cxf/3.1.4/xml/features, \
>> 

Re: Prerequisites amongst boot features

[Guillaume Nodet]

Would you mind pasting the stack trace of the error you have please ?


2016-09-29 15:54 GMT+02:00 Benson Margulies :

> Hi JB,
>
> I let the maven plugin write org.apache.karaf.features.cfg, so I don't
> know, to be honest, if I'm using multi-stage.
>
> _Without_ the failing prerequisites, I have the following content of
> org.apache.karaf.features.cfg. I'm using the property editor feature
> to turn off capability enforcement.
>
>
> rosapi-all-sdks is just a bag of  declarations for other
> features. Things break when I try to make one of them a prerequisite
> of another. My problem is really to prevent the activation of a few
> bundles until another bundle is safely under control, and I am hoping
> for a workaround in the interim until we can really fix this with DS
> in a few weeks.
>
>
> #Modified by org.apache.karaf.tools.utils.KarafPropertiesFile
> #Thu Sep 29 09:49:19 EDT 2016
> featuresBootAsynchronous=false
> serviceRequirements=disable
> featuresBoot = \
> (wrap), \
> log, \
> rosapi-front-end-anvils-transport, \
> bean-validation-support, \
> rosapi-worker-common, \
> ssh, \
> rosapi-front-end-logstash-request-tracker, \
> rosapi-front-end-service, \
> aries-blueprint, \
> feature, \
> jaas, \
> diagnostic, \
> rosapi-worker-download-text-extraction-component, \
> rosapi-front-end-null-request-tracker, \
> bundle, \
> rosapi-all-sdks, \
> rosapi-front-end-local-usage-tracker, \
> package, \
> scr, \
> rosapi-common, \
> cxf-jaxrs, \
> rosette-api, \
> rosapi-front-end-embedded-transport, \
> system, \
> shell, \
> shell-compat, \
> config
> featuresRepositories = \
> mvn:com.basistech.ws/rosapi-features/1.5.0-SNAPSHOT/xml/features, \
> mvn:org.apache.karaf.features/standard/4.0.6/xml/features, \
> mvn:org.apache.cxf.karaf/apache-cxf/3.1.4/xml/features, \
> mvn:org.apache.karaf.features/framework/4.0.6/xml/features
>
>
> On Thu, Sep 29, 2016 at 9:47 AM, Jean-Baptiste Onofré 
> wrote:
> > Hi Benson,
> >
> > do you use multi-stage in featuresBoot ?
> >
> > Regards
> > JB
> >
> >
> > On 09/29/2016 03:33 PM, Benson Margulies wrote:
> >>
> >> Folks,
> >>
> >> I build an assembly in which all the feature are boot features,
> >> because they are all going to be used.
> >>
> >> When I try to make one of them a prerequisite of another, I get a
> >> wiring error, because, apparently, the dependency tree at the package
> >> level is not being respected in wiring the bundles.
> >>
> >> All of this is a temporary stopgap until some components get correct
> >> DS @Reference dependencies, which some of them lack.
> >>
> >> Questions: Am I making an error using boot features? I realize that
> >> this report lacks specificity. I could try to build up a model on
> >> github.
> >>
> >> TIA,
> >> benson
> >>
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

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

Re: Prerequisites amongst boot features

[Benson Margulies]

Hi JB,

I let the maven plugin write org.apache.karaf.features.cfg, so I don't
know, to be honest, if I'm using multi-stage.

_Without_ the failing prerequisites, I have the following content of
org.apache.karaf.features.cfg. I'm using the property editor feature
to turn off capability enforcement.


rosapi-all-sdks is just a bag of  declarations for other
features. Things break when I try to make one of them a prerequisite
of another. My problem is really to prevent the activation of a few
bundles until another bundle is safely under control, and I am hoping
for a workaround in the interim until we can really fix this with DS
in a few weeks.


#Modified by org.apache.karaf.tools.utils.KarafPropertiesFile
#Thu Sep 29 09:49:19 EDT 2016
featuresBootAsynchronous=false
serviceRequirements=disable
featuresBoot = \
(wrap), \
log, \
rosapi-front-end-anvils-transport, \
bean-validation-support, \
rosapi-worker-common, \
ssh, \
rosapi-front-end-logstash-request-tracker, \
rosapi-front-end-service, \
aries-blueprint, \
feature, \
jaas, \
diagnostic, \
rosapi-worker-download-text-extraction-component, \
rosapi-front-end-null-request-tracker, \
bundle, \
rosapi-all-sdks, \
rosapi-front-end-local-usage-tracker, \
package, \
scr, \
rosapi-common, \
cxf-jaxrs, \
rosette-api, \
rosapi-front-end-embedded-transport, \
system, \
shell, \
shell-compat, \
config
featuresRepositories = \
mvn:com.basistech.ws/rosapi-features/1.5.0-SNAPSHOT/xml/features, \
mvn:org.apache.karaf.features/standard/4.0.6/xml/features, \
mvn:org.apache.cxf.karaf/apache-cxf/3.1.4/xml/features, \
mvn:org.apache.karaf.features/framework/4.0.6/xml/features


On Thu, Sep 29, 2016 at 9:47 AM, Jean-Baptiste Onofré  wrote:
> Hi Benson,
>
> do you use multi-stage in featuresBoot ?
>
> Regards
> JB
>
>
> On 09/29/2016 03:33 PM, Benson Margulies wrote:
>>
>> Folks,
>>
>> I build an assembly in which all the feature are boot features,
>> because they are all going to be used.
>>
>> When I try to make one of them a prerequisite of another, I get a
>> wiring error, because, apparently, the dependency tree at the package
>> level is not being respected in wiring the bundles.
>>
>> All of this is a temporary stopgap until some components get correct
>> DS @Reference dependencies, which some of them lack.
>>
>> Questions: Am I making an error using boot features? I realize that
>> this report lacks specificity. I could try to build up a model on
>> github.
>>
>> TIA,
>> benson
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Prerequisites amongst boot features

[Jean-Baptiste Onofré]

Hi Benson,

do you use multi-stage in featuresBoot ?

Regards
JB

On 09/29/2016 03:33 PM, Benson Margulies wrote:

Folks,

I build an assembly in which all the feature are boot features,
because they are all going to be used.

When I try to make one of them a prerequisite of another, I get a
wiring error, because, apparently, the dependency tree at the package
level is not being respected in wiring the bundles.

All of this is a temporary stopgap until some components get correct
DS @Reference dependencies, which some of them lack.

Questions: Am I making an error using boot features? I realize that
this report lacks specificity. I could try to build up a model on
github.

TIA,
benson



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

Prerequisites amongst boot features

[Benson Margulies]

Folks,

I build an assembly in which all the feature are boot features,
because they are all going to be used.

When I try to make one of them a prerequisite of another, I get a
wiring error, because, apparently, the dependency tree at the package
level is not being respected in wiring the bundles.

All of this is a temporary stopgap until some components get correct
DS @Reference dependencies, which some of them lack.

Questions: Am I making an error using boot features? I realize that
this report lacks specificity. I could try to build up a model on
github.

TIA,
benson

Re: missing requirement [org.apache.karaf.features.core/4.0.5] osgi.wiring.package; filter:="(osgi.wiring.package=org.eclipse.equinox.region.management)

[Daniel McGreal]

If I install the feature, exactly as Allan C has it in the first message on 
this topic, I get no such error, even with the 1.0.0 namespace.

Any ideas how I can proceed to debug this? Can I get any logs from the feature 
resolution process to find out why the Eclipse bundle comes into the frame?

Any help on this greatly appreciated.
Best, Dan.



> On 28 Sep 2016, at 17:18, Daniel McGreal  wrote:
> 
> I see that org.apache.karaf.features.core is exporting and importing 
> org.eclipse.equinox.region.management.
> I don’t really know where to go from here.
> 
>> On 28 Sep 2016, at 16:50, Daniel McGreal  wrote:
>> 
>> Hi, I’m getting this now, but I already had 1.3.0.
>> Did you change anything else?
>> Anyone else know what’s going on?
>> 
>> Ta, Dan.
>> 
>> 
>>> On 1 Jul 2016, at 04:52, Allan C.  wrote:
>>> 
>>> Please ignore this.
>>> 
>>> It's working after I've updated the xml namespace from 1.0.0 to 1.3.0.
>>> 
>>> Regards,
>>> Allan C.
>>> 
>>> 
>>> On Fri, Jul 1, 2016 at 8:15 AM, Allan C.  wrote:
 Hi,
 
 I am trying to get my feature installed but encountered this exception:
 
 08:10:49,424 | ERROR | ShellUtil:149 | 44 | Exception caught while 
 executing
 command
 org.osgi.service.resolver.ResolutionException: Unable to resolve
 org.apache.karaf.features.core/4.0.5: missing requirement
 [org.apache.karaf.features.core/4.0.5] osgi.wiring.package;
 filter:="(osgi.wiring.package=org.eclipse.equinox.region.management)"
  at
 org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)[org.apache.felix.framework-5.4.0.jar:]
  at
 org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:404)[org.apache.felix.framework-5.4.0.jar:]
  at
 org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:179)[org.apache.felix.framework-5.4.0.jar:]
  at
 org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[9:org.apache.karaf.features.core:4.0.5]
  at
 org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[9:org.apache.karaf.features.core:4.0.5]
  at
 org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1152)[9:org.apache.karaf.features.core:4.0.5]
  at
 org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1048)[9:org.apache.karaf.features.core:4.0.5]
  at
 java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_101]
  at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_101]
  at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_101]
  at java.lang.Thread.run(Thread.java:745)[:1.7.0_101]
 
 This is my features.xml.
 
 >>> xmlns="http://karaf.apache.org/xmlns/features/v1.0.0;>
 mvn:org.apache.karaf.features/framework/4.0.5/xml/features
 mvn:org.apache.karaf.features/standard/4.0.5/xml/features
 mvn:org.apache.karaf.features/enterprise/4.0.5/xml/features
 mvn:org.ops4j.pax.jdbc/pax-jdbc-features/0.8.0/xml/features
 mvn:org.apache.camel.karaf/apache-camel/2.15.1/xml/features
 mvn:org.apache.cxf.karaf/apache-cxf/3.0.4/xml/features
 
 
 transaction
 jpa
 jndi
 hibernate
 
 camel-core
 camel-blueprint
 camel-bindy
 camel-jpa
 camel-cxf
 camel-spring
 camel-jetty
 
 pax-jdbc-mysql
 pax-jdbc-pool-dbcp2
 pax-jdbc-config
 
 mvn:net.sf.ehcache/ehcache/2.9.1
 mvn:org.apache.shiro/shiro-core/1.2.3
 mvn:org.apache.shiro/shiro-ehcache/1.2.3
 mvn:com.fasterxml.jackson.core/jackson-core/2.4.3
 mvn:com.fasterxml.jackson.core/jackson-annotations/2.4.3
 mvn:com.fasterxml.jackson.core/jackson-databind/2.4.3
 mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-json-provider/2.4.3
 mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-base/2.4.3
 mvn:javax.ws.rs/javax.ws.rs-api/2.0.1
 mvn:org.apache.geronimo.specs/geronimo-jpa_2.0_spec/1.1
 wrap:mvn:org.hibernate.javax.persistence/hibernate-jpa-2.0-api/1.0.1.Final
 
 
 
 Does anyone know which bundle or feature I am missing?
 
 Regards,
 Allan C.
>> 
> 

Re: Questions about OSGi

[David Bosschaert]

Hi Sigmund,

On 29 September 2016 at 11:08, Sigmund Lee  wrote:

> Hi all,
>
> I'm on my way reading OSGi core spec 6.0 right now. here are some
> questions confused me:
>
> 1. What's the relationship between a bundle's Bundle-Version manifest
> header and attribute version of Export-Package manifest header of this
> bundle?
>

There is no relation. A bundle might have version 5.2.1 and export package
org.foo.bar version 1.0.2 and package org.foo.bar.blah in version 2.0.0.
Everything is independently versioned. Exported packages are normally
versioned using semantic versioning that strictly indicate the
compatibility with previous versions. Bundle versions can be more loosely
versioned, e.g. marketing versions can be used there, but some people use
semantic versioning for bundle versions too.


> 2. Why need add Provide-Capability for some namespace(for example, provide
> capability for namespace osgi.extender) to bundle's MANIFEST.MF, but do not
> need add Provide-Capability for namespace orgi.wiring.package when we are
> using Export-Package on this bundle? is that because namespaces under
> osgi.wiring.* is special so we do not need to provide them explicitly when
> using capability of them, or something else?
>

The reason for this is mostly historical. The Provide-Capability header was
introduced quite a while after the Export-Package and Bundle-Version were
introduced. At some point additional 'capabilities' were needed to be
provided by the bundles. Rather than creating a new header for each of
them, the generic Provide-Capability header was introduced, but it's not
used for capabilities that were already provided using existing headers.


> 3. to be continued...
>

... suspense music ...

Hope this helps,

David

Questions about OSGi

[Sigmund Lee]

Hi all,

I'm on my way reading OSGi core spec 6.0 right now. here are some questions
confused me:

1. What's the relationship between a bundle's Bundle-Version manifest
header and attribute version of Export-Package manifest header of this
bundle?
2. Why need add Provide-Capability for some namespace(for example, provide
capability for namespace osgi.extender) to bundle's MANIFEST.MF, but do not
need add Provide-Capability for namespace orgi.wiring.package when we are
using Export-Package on this bundle? is that because namespaces under
osgi.wiring.* is special so we do not need to provide them explicitly when
using capability of them, or something else?
3. to be continued...


Thanks.

Regards.