Re: Antw: Re: Require-Capability with effective:=active not ignored

[Timothy Ward]

Both the maven-bundle-plugin and the bnd-maven-plugin will precess the standard 
DS annotations for you.

Regards,

Tim

> On 16 Aug 2017, at 14:30, alexander.sah...@brodos.de wrote:
> 
> Hello Tim.
> 
> How am I to use DS with @Component annotaition when having 
> blueprint-maven-plugin in place!
> Is it possible anyways?
> 
> Regards,
> Alexander.
> 
> 
> 
> Hi Tim.
> 
> Well, maybe I made myself not completely clear. Of course it is possible to 
> mix DS and blueprint even in the same bundle when you use services for 
> communication but as you say, it's normally not a good idea.
> > Mixing blueprint and DS in the same bundle isn’t
> > normally a good idea, but even that works fine if you use services to
> > communicate.
> 
> However I find it very confusing to use annotations from three different 
> ecosystems (blueprint, pax-cdi and scr/DS).
> 
> Currently, I in fact use sort of busy-waiting in the BundleActivator (with 
> rxJava/retryWhen) failing after appox. 1 minute until the resource comes up. 
> But I will definitely give it a try with DS as is is for sure the cleaner 
> approach.
> 
> Thanks for the advice!
> 
> Regards,
> Alexander.
> 
> >>> Timothy Ward > schrieb 
> >>> am Mittwoch, 16. August 2017 um
> 
> 12:27 in Nachricht <50cd1d90-699f-405d-b1cb-e02f36d05...@paremus.com 
> >:
> 
> > Hi Alexander,
> >
> >> Using DS is currently not an option as the whole project uses blueprint and
> > the mix of DS and blueprint is not recommended as far as I know.
> >
> > By whom and why? OSGi services are OSGi services, it doesn’t matter which
> > framework you use to register or consume them. I regularly use mixtures of
> > frameworks without issue. Mixing blueprint and DS in the same bundle isn’t
> > normally a good idea, but even that works fine if you use services to
> > communicate.
> >
> >> Thanks anyways. I worked around by having the activator waiting until a
> > given object is registered in jndi.
> >
> > How exactly are you waiting, and is this a real
> > org.osgi.framework.BundleActivator? That’s a pretty low level type and 
> > offers
> > you pretty much no help, you would probably get a lot of benefit by *not*
> > using a BundleActivator and using DS or blueprint instead. Also you *must
> > not* block in your activator start method as this risks deadlocking the
> > system.
> >
> > Regards,
> >
> > Tim
> >
> >> On 16 Aug 2017, at 11:08,  >> >
> 
> > > wrote:
> 
> >>
> >> Hello Tim.
> >>
> >> Thanks for the quick response and the clarification. In fact it's exactly
> > like you described. My intention is to postpone the STARTING/ACTIVE state
> > until a certain requirement is fulfilled.
> >>
> >> Using DS is currently not an option as the whole project uses blueprint and
> > the mix of DS and blueprint is not recommended as far as I know.
> >>
> >> Thanks anyways. I worked around by having the activator waiting until a
> > given object is registered in jndi.
> >>
> >> Regards,
> >> Alexander
> >>
> >>
> >>
> >> Hi Alexander,
> >>
> >> An active time capability is ignored by the OSGi framework. This means that
> > it will not prevent your OSGi bundle moving from the INSTALLED state to the
> > RESOLVED state.
> >>
> >> What you’re seeing is that the resolver can also be run elsewhere, for
> > example to find or validate a set of bundles to be installed. This is 
> > usually
> > called a “provisioning operation”, and is what Karaf is trying to do here.
> > When the resolver is used by these tools they are free to decide which
> > requirements should be effective, and in this case Karaf is requiring that
> > your active time capability is matched by something (after all it’s not
> > optional!).
> >>
> >>> What I try to achieve is that a certain bundle activation is postponed 
> >>> until
> > a given requirement is met. Is is possible anyways?
> >>
> >> What do you mean by bundle activation? If you mean that you want your 
> >> bundle
> > to remain in the INSTALLED state then you need to use a resolve-time
> > effective requirement for this. If you mean that you want your bundle not to
> > move to the STARTING/ACTIVE state then requirements/capabilites cannot help
> > with this. Instead you should react to the registration of OSGi services. A
> > tool like Declarative Services will make this easy, and allow your 
> > components
> > to dynamically respond to the presence (or lack of) an OSGi service.
> >>
> >> Regards,
> >>
> >> Tim
> >>
> >>> On 16 Aug 2017, at 07:43, alexander.sah...@brodos.de 
> >>> 
> 
> > > 
> > wrote:
> 
> >>>
> >>> Hi there.
> >>>
> >>> According to
> > http://osgi-dev.mail.osgi.narkive.com/GfJqfPGZ/require-capability-osgi-servic
> >  
> > 

Re: Antw: Re: Require-Capability with effective:=active not ignored

[alexander.sahler]

Hello Tim.

How am I to use DS with @Component annotaition when having
blueprint-maven-plugin in place!
Is it possible anyways?

Regards,
Alexander.


>>> 
Hi Tim.

Well, maybe I made myself not completely clear. Of course it is
possible to mix DS and blueprint even in the same bundle when you use
services for communication but as you say, it's normally not a good
idea.
> Mixing blueprint and DS in the same bundle isn’t 
> normally a good idea, but even that works fine if you use services to

> communicate.

However I find it very confusing to use annotations from three
different ecosystems (blueprint, pax-cdi and scr/DS). 

Currently, I in fact use sort of busy-waiting in the BundleActivator
(with rxJava/retryWhen) failing after appox. 1 minute until the resource
comes up. But I will definitely give it a try with DS as is is for sure
the cleaner approach.

Thanks for the advice!

Regards,
Alexander.

>>> Timothy Ward  schrieb am Mittwoch, 16. August
2017 um

12:27 in Nachricht <50cd1d90-699f-405d-b1cb-e02f36d05...@paremus.com>:

> Hi Alexander,
> 
>> Using DS is currently not an option as the whole project uses
blueprint and 
> the mix of DS and blueprint is not recommended as far as I know.
> 
> By whom and why? OSGi services are OSGi services, it doesn’t matter
which 
> framework you use to register or consume them. I regularly use
mixtures of 
> frameworks without issue. Mixing blueprint and DS in the same bundle
isn’t 
> normally a good idea, but even that works fine if you use services to

> communicate.
> 
>> Thanks anyways. I worked around by having the activator waiting
until a 
> given object is registered in jndi.
> 
> How exactly are you waiting, and is this a real 
> org.osgi.framework.BundleActivator? That’s a pretty low level type
and offers 
> you pretty much no help, you would probably get a lot of benefit by
*not* 
> using a BundleActivator and using DS or blueprint instead. Also you
*must 
> not* block in your activator start method as this risks deadlocking
the 
> system.
> 
> Regards,
> 
> Tim
> 
>> On 16 Aug 2017, at 11:08,  

>  wrote:

>> 
>> Hello Tim.
>> 
>> Thanks for the quick response and the clarification. In fact it's
exactly 
> like you described. My intention is to postpone the STARTING/ACTIVE
state 
> until a certain requirement is fulfilled.
>> 
>> Using DS is currently not an option as the whole project uses
blueprint and 
> the mix of DS and blueprint is not recommended as far as I know.
>> 
>> Thanks anyways. I worked around by having the activator waiting
until a 
> given object is registered in jndi.
>> 
>> Regards,
>> Alexander
>> 
>> 
>> 
>> Hi Alexander,
>> 
>> An active time capability is ignored by the OSGi framework. This
means that 
> it will not prevent your OSGi bundle moving from the INSTALLED state
to the 
> RESOLVED state. 
>> 
>> What you’re seeing is that the resolver can also be run elsewhere,
for 
> example to find or validate a set of bundles to be installed. This is
usually 
> called a “provisioning operation”, and is what Karaf is trying to do
here. 
> When the resolver is used by these tools they are free to decide
which 
> requirements should be effective, and in this case Karaf is requiring
that 
> your active time capability is matched by something (after all it’s
not 
> optional!).
>> 
>>> What I try to achieve is that a certain bundle activation is
postponed until 
> a given requirement is met. Is is possible anyways?
>> 
>> What do you mean by bundle activation? If you mean that you want
your bundle 
> to remain in the INSTALLED state then you need to use a resolve-time

> effective requirement for this. If you mean that you want your bundle
not to 
> move to the STARTING/ACTIVE state then requirements/capabilites
cannot help 
> with this. Instead you should react to the registration of OSGi
serv
ices. A 
> tool like Declarative Services will make this easy, and allow your
components 
> to dynamically respond to the presence (or lack of) an OSGi service.
>> 
>> Regards,
>> 
>> Tim
>> 
>>> On 16 Aug 2017, at 07:43, alexander.sah...@brodos.de 

>  wrote:

>>> 
>>> Hi there.
>>> 
>>> According to 
>
http://osgi-dev.mail.osgi.narkive.com/GfJqfPGZ/require-capability-osgi-servic


> e-filter-effective-active-and-blueprint 
>
 ce-filter-effective-active-and-blueprint> (and the OSGi spec), a R-C
header 
> with effective:=active should be ignored by OSGi framework. But when
I create 
> a R-C header like
>>> 
>>> Require-Capability: 
>
osgi.service;effective:=active;objectClass="javax.sql.DataSource";filter:="(o
> sgi.jndi.service.name=bam)"
>>> 
>>> to indicate a dependency to a DataSource, the resolver tells me:
>>> 
>>> org.osgi.service.resolver.ResolutionException: Unable to resolve
root: 
> missing requirement [root] osgi.identity; 

Re: Antw: Re: Require-Capability with effective:=active not ignored

[alexander.sahler]

Hi Tim.

Well, maybe I made myself not completely clear. Of course it is
possible to mix DS and blueprint even in the same bundle when you use
services for communication but as you say, it's normally not a good
idea.
> Mixing blueprint and DS in the same bundle isn’t 
> normally a good idea, but even that works fine if you use services to

> communicate.

However I find it very confusing to use annotations from three
different ecosystems (blueprint, pax-cdi and scr/DS). 

Currently, I in fact use sort of busy-waiting in the BundleActivator
(with rxJava/retryWhen) failing after appox. 1 minute until the resource
comes up. But I will definitely give it a try with DS as is is for sure
the cleaner approach.

Thanks for the advice!

Regards,
Alexander.

>>> Timothy Ward  schrieb am Mittwoch, 16. August
2017 um

12:27 in Nachricht <50cd1d90-699f-405d-b1cb-e02f36d05...@paremus.com>:

> Hi Alexander,
> 
>> Using DS is currently not an option as the whole project uses
blueprint and 
> the mix of DS and blueprint is not recommended as far as I know.
> 
> By whom and why? OSGi services are OSGi services, it doesn’t matter
which 
> framework you use to register or consume them. I regularly use
mixtures of 
> frameworks without issue. Mixing blueprint and DS in the same bundle
isn’t 
> normally a good idea, but even that works fine if you use services to

> communicate.
> 
>> Thanks anyways. I worked around by having the activator waiting
until a 
> given object is registered in jndi.
> 
> How exactly are you waiting, and is this a real 
> org.osgi.framework.BundleActivator? That’s a pretty low level type
and offers 
> you pretty much no help, you would probably get a lot of benefit by
*not* 
> using a BundleActivator and using DS or blueprint instead. Also you
*must 
> not* block in your activator start method as this risks deadlocking
the 
> system.
> 
> Regards,
> 
> Tim
> 
>> On 16 Aug 2017, at 11:08,  

>  wrote:

>> 
>> Hello Tim.
>> 
>> Thanks for the quick response and the clarification. In fact it's
exactly 
> like you described. My intention is to postpone the STARTING/ACTIVE
state 
> until a certain requirement is fulfilled.
>> 
>> Using DS is currently not an option as the whole project uses
blueprint and 
> the mix of DS and blueprint is not recommended as far as I know.
>> 
>> Thanks anyways. I worked around by having the activator waiting
until a 
> given object is registered in jndi.
>> 
>> Regards,
>> Alexander
>> 
>> 
>> 
>> Hi Alexander,
>> 
>> An active time capability is ignored by the OSGi framework. This
means that 
> it will not prevent your OSGi bundle moving from the INSTALLED state
to the 
> RESOLVED state. 
>> 
>> What you’re seeing is that the resolver can also be run elsewhere,
for 
> example to find or validate a set of bundles to be installed. This is
usually 
> called a “provisioning operation”, and is what Karaf is trying to do
here. 
> When the resolver is used by these tools they are free to decide
which 
> requirements should be effective, and in this case Karaf is requiring
that 
> your active time capability is matched by something (after all it’s
not 
> optional!).
>> 
>>> What I try to achieve is that a certain bundle activation is
postponed until 
> a given requirement is met. Is is possible anyways?
>> 
>> What do you mean by bundle activation? If you mean that you want
your bundle 
> to remain in the INSTALLED state then you need to use a resolve-time

> effective requirement for this. If you mean that you want your bundle
not to 
> move to the STARTING/ACTIVE state then requirements/capabilites
cannot help 
> with this. Instead you should react to the registration of OSGi
services. A 
> tool like Declarative Services will make this easy, and allow your
components 
> to dynamically respond to the presence (or lack of) an OSGi service.
>>
 
>> Regards,
>> 
>> Tim
>> 
>>> On 16 Aug 2017, at 07:43, alexander.sah...@brodos.de 

>  wrote:

>>> 
>>> Hi there.
>>> 
>>> According to 
>
http://osgi-dev.mail.osgi.narkive.com/GfJqfPGZ/require-capability-osgi-servic


> e-filter-effective-active-and-blueprint 
>
 ce-filter-effective-active-and-blueprint> (and the OSGi spec), a R-C
header 
> with effective:=active should be ignored by OSGi framework. But when
I create 
> a R-C header like
>>> 
>>> Require-Capability: 
>
osgi.service;effective:=active;objectClass="javax.sql.DataSource";filter:="(o
> sgi.jndi.service.name=bam)"
>>> 
>>> to indicate a dependency to a DataSource, the resolver tells me:
>>> 
>>> org.osgi.service.resolver.ResolutionException: Unable to resolve
root: 
> missing requirement [root] osgi.identity; osgi.identity=isaac-app; 
> type=karaf.feature; version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]"; 
>
filter:="(&(osgi.identity=isaac-app)(type=karaf.feature)(version>=2.1.2.SNAPSH
> 

Re: Antw: Re: Require-Capability with effective:=active not ignored

[Timothy Ward]

Hi Alexander,

> Using DS is currently not an option as the whole project uses blueprint and 
> the mix of DS and blueprint is not recommended as far as I know.

By whom and why? OSGi services are OSGi services, it doesn’t matter which 
framework you use to register or consume them. I regularly use mixtures of 
frameworks without issue. Mixing blueprint and DS in the same bundle isn’t 
normally a good idea, but even that works fine if you use services to 
communicate.

> Thanks anyways. I worked around by having the activator waiting until a given 
> object is registered in jndi.

How exactly are you waiting, and is this a real 
org.osgi.framework.BundleActivator? That’s a pretty low level type and offers 
you pretty much no help, you would probably get a lot of benefit by *not* using 
a BundleActivator and using DS or blueprint instead. Also you *must not* block 
in your activator start method as this risks deadlocking the system.

Regards,

Tim

> On 16 Aug 2017, at 11:08,  
>  wrote:
> 
> Hello Tim.
> 
> Thanks for the quick response and the clarification. In fact it's exactly 
> like you described. My intention is to postpone the STARTING/ACTIVE state 
> until a certain requirement is fulfilled.
> 
> Using DS is currently not an option as the whole project uses blueprint and 
> the mix of DS and blueprint is not recommended as far as I know.
> 
> Thanks anyways. I worked around by having the activator waiting until a given 
> object is registered in jndi.
> 
> Regards,
> Alexander
> 
> 
> 
> Hi Alexander,
> 
> An active time capability is ignored by the OSGi framework. This means that 
> it will not prevent your OSGi bundle moving from the INSTALLED state to the 
> RESOLVED state. 
> 
> What you’re seeing is that the resolver can also be run elsewhere, for 
> example to find or validate a set of bundles to be installed. This is usually 
> called a “provisioning operation”, and is what Karaf is trying to do here. 
> When the resolver is used by these tools they are free to decide which 
> requirements should be effective, and in this case Karaf is requiring that 
> your active time capability is matched by something (after all it’s not 
> optional!).
> 
>> What I try to achieve is that a certain bundle activation is postponed until 
>> a given requirement is met. Is is possible anyways?
> 
> What do you mean by bundle activation? If you mean that you want your bundle 
> to remain in the INSTALLED state then you need to use a resolve-time 
> effective requirement for this. If you mean that you want your bundle not to 
> move to the STARTING/ACTIVE state then requirements/capabilites cannot help 
> with this. Instead you should react to the registration of OSGi services. A 
> tool like Declarative Services will make this easy, and allow your components 
> to dynamically respond to the presence (or lack of) an OSGi service.
> 
> Regards,
> 
> Tim
> 
>> On 16 Aug 2017, at 07:43, alexander.sah...@brodos.de 
>>  wrote:
>> 
>> Hi there.
>> 
>> According to 
>> http://osgi-dev.mail.osgi.narkive.com/GfJqfPGZ/require-capability-osgi-service-filter-effective-active-and-blueprint
>>  
>> 
>>  (and the OSGi spec), a R-C header with effective:=active should be ignored 
>> by OSGi framework. But when I create a R-C header like
>> 
>> Require-Capability: 
>> osgi.service;effective:=active;objectClass="javax.sql.DataSource";filter:="(osgi.jndi.service.name=bam)"
>> 
>> to indicate a dependency to a DataSource, the resolver tells me:
>> 
>> org.osgi.service.resolver.ResolutionException: Unable to resolve root: 
>> missing requirement [root] osgi.identity; osgi.identity=isaac-app; 
>> type=karaf.feature; version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]"; 
>> filter:="(&(osgi.identity=isaac-app)(type=karaf.feature)(version>=2.1.2.SNAPSHOT)(version<=2.1.2.SNAPSHOT))"
>>  [caused by: Unable to resolve isaac-app/2.1.2.SNAPSHOT: missing requirement 
>> [isaac-app/2.1.2.SNAPSHOT] osgi.identity; osgi.identity=isaac-service; 
>> type=karaf.feature [caused by: Unable to resolve 
>> isaac-service/2.1.2.SNAPSHOT: missing requirement 
>> [isaac-service/2.1.2.SNAPSHOT] osgi.identity; 
>> osgi.identity=com.brodos.isaac.service; type=osgi.bundle; 
>> version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]"; resolution:=mandatory [caused by: 
>> Unable to resolve com.brodos.isaac.service/2.1.2.SNAPSHOT: missing 
>> requirement [com.brodos.isaac.service/2.1.2.SNAPSHOT] osgi.service; 
>> objectClass=javax.sql.DataSource; effective:=active; 
>> filter:="(osgi.jndi.service.name=bam)"]]]
>> 
>> Shouldn't it be ignored by OSGi framework?
>> 
>> What I try to achieve is that a certain bundle activation is postponed until 
>> a given requirement is met. Is is possible anyways?
>> 
>> Best regards,
>> Alexander
> 

Antw: Re: Require-Capability with effective:=active not ignored

[alexander.sahler]

Hello Tim.

Thanks for the quick response and the clarification. In fact it's
exactly like you described. My intention is to postpone the
STARTING/ACTIVE state until a certain requirement is fulfilled. 

Using DS is currently not an option as the whole project uses blueprint
and the mix of DS and blueprint is not recommended as far as I know.

Thanks anyways. I worked around by having the activator waiting until a
given object is registered in jndi.

Regards,
Alexander


>>> 
Hi Alexander,

An active time capability is ignored by the OSGi framework. This means
that it will not prevent your OSGi bundle moving from the INSTALLED
state to the RESOLVED state. 

What you’re seeing is that the resolver can also be run elsewhere, for
example to find or validate a set of bundles to be installed. This is
usually called a “provisioning operation”, and is what Karaf is trying
to do here. When the resolver is used by these tools they are free to
decide which requirements should be effective, and in this case Karaf is
requiring that your active time capability is matched by something
(after all it’s not optional!).



What I try to achieve is that a certain bundle activation is postponed
until a given requirement is met. Is is possible anyways?

What do you mean by bundle activation? If you mean that you want your
bundle to remain in the INSTALLED state then you need to use a
resolve-time effective requirement for this. If you mean that you want
your bundle not to move to the STARTING/ACTIVE state then
requirements/capabilites cannot help with this. Instead you should react
to the registration of OSGi services. A tool like Declarative Services
will make this easy, and allow your components to dynamically respond to
the presence (or lack of) an OSGi service.

Regards,

Tim



On 16 Aug 2017, at 07:43, alexander.sah...@brodos.de wrote:

Hi there.

According to
http://osgi-dev.mail.osgi.narkive.com/GfJqfPGZ/require-capability-osgi-service-filter-effective-active-and-blueprint
(and the OSGi spec), a R-C header with effective:=active should be
ignored by OSGi framework. But when I create a R-C header like

Require-Capability:
osgi.service;effective:=active;objectClass="javax.sql.DataSource";filter:="(osgi.jndi.service.name=bam)"

to indicate a dependency to a DataSource, the resolver tells me:

org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity; osgi.identity=isaac-app;
type=karaf.feature; version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]";
filter:="(&(osgi.identity=isaac-app)(type=karaf.feature)(version>=2.1.2.SNAPSHOT)(version<=2.1.2.SNAPSHOT))"
[caused by: Unable to resolve isaac-app/2.1.2.SNAPSHOT: missing
requirement [isaac-app/2.1.2.SNAPSHOT] osgi.identity;
osgi.identity=isaac-service; type=karaf.feature [caused by: Unable to
resolve isaac-service/2.1.2.SNAPSHOT: missing requirement
[isaac-service/2.1.2.SNAPSHOT] osgi.identity;
osgi.identity=com.brodos.isaac.service; type=osgi.bundle;
version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]"; resolution:=mandatory [caused
by: Unable to resolve com.brodos.isaac.service/2.1.2.SNAPSHOT: missing
requirement [com.brodos.isaac.service/2.1.2.SNAPSHOT] osgi.service;
objectClass=javax.sql.DataSource; effective:=active;
filter:="(osgi.jndi.service.name=bam)"]]]

Shouldn't it be ignored by OSGi framework?

What I try to achieve is that a certain bundle activation is postponed
until a given requirement is met. Is is possible anyways?

Best regards,
Alexander

Re: Require-Capability with effective:=active not ignored

[Timothy Ward]

Hi Alexander,

An active time capability is ignored by the OSGi framework. This means that it 
will not prevent your OSGi bundle moving from the INSTALLED state to the 
RESOLVED state. 

What you’re seeing is that the resolver can also be run elsewhere, for example 
to find or validate a set of bundles to be installed. This is usually called a 
“provisioning operation”, and is what Karaf is trying to do here. When the 
resolver is used by these tools they are free to decide which requirements 
should be effective, and in this case Karaf is requiring that your active time 
capability is matched by something (after all it’s not optional!).

> What I try to achieve is that a certain bundle activation is postponed until 
> a given requirement is met. Is is possible anyways?

What do you mean by bundle activation? If you mean that you want your bundle to 
remain in the INSTALLED state then you need to use a resolve-time effective 
requirement for this. If you mean that you want your bundle not to move to the 
STARTING/ACTIVE state then requirements/capabilites cannot help with this. 
Instead you should react to the registration of OSGi services. A tool like 
Declarative Services will make this easy, and allow your components to 
dynamically respond to the presence (or lack of) an OSGi service.

Regards,

Tim

> On 16 Aug 2017, at 07:43, alexander.sah...@brodos.de wrote:
> 
> Hi there.
> 
> According to 
> http://osgi-dev.mail.osgi.narkive.com/GfJqfPGZ/require-capability-osgi-service-filter-effective-active-and-blueprint
>  
> 
>  (and the OSGi spec), a R-C header with effective:=active should be ignored 
> by OSGi framework. But when I create a R-C header like
> 
> Require-Capability: 
> osgi.service;effective:=active;objectClass="javax.sql.DataSource";filter:="(osgi.jndi.service.name=bam)"
> 
> to indicate a dependency to a DataSource, the resolver tells me:
> 
> org.osgi.service.resolver.ResolutionException: Unable to resolve root: 
> missing requirement [root] osgi.identity; osgi.identity=isaac-app; 
> type=karaf.feature; version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]"; 
> filter:="(&(osgi.identity=isaac-app)(type=karaf.feature)(version>=2.1.2.SNAPSHOT)(version<=2.1.2.SNAPSHOT))"
>  [caused by: Unable to resolve isaac-app/2.1.2.SNAPSHOT: missing requirement 
> [isaac-app/2.1.2.SNAPSHOT] osgi.identity; osgi.identity=isaac-service; 
> type=karaf.feature [caused by: Unable to resolve 
> isaac-service/2.1.2.SNAPSHOT: missing requirement 
> [isaac-service/2.1.2.SNAPSHOT] osgi.identity; 
> osgi.identity=com.brodos.isaac.service; type=osgi.bundle; 
> version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]"; resolution:=mandatory [caused by: 
> Unable to resolve com.brodos.isaac.service/2.1.2.SNAPSHOT: missing 
> requirement [com.brodos.isaac.service/2.1.2.SNAPSHOT] osgi.service; 
> objectClass=javax.sql.DataSource; effective:=active; 
> filter:="(osgi.jndi.service.name=bam)"]]]
> 
> Shouldn't it be ignored by OSGi framework?
> 
> What I try to achieve is that a certain bundle activation is postponed until 
> a given requirement is met. Is is possible anyways?
> 
> Best regards,
> Alexander

Require-Capability with effective:=active not ignored

[alexander.sahler]

Hi there.

According to 
http://osgi-dev.mail.osgi.narkive.com/GfJqfPGZ/require-capability-osgi-service-filter-effective-active-and-blueprint
 (and the OSGi spec), a R-C header with effective:=active should be ignored by 
OSGi framework. But when I create a R-C header like

Require-Capability: 
osgi.service;effective:=active;objectClass="javax.sql.DataSource";filter:="(osgi.jndi.service.name=bam)"

to indicate a dependency to a DataSource, the resolver tells me:

org.osgi.service.resolver.ResolutionException: Unable to resolve root: missing 
requirement [root] osgi.identity; osgi.identity=isaac-app; type=karaf.feature; 
version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]"; 
filter:="(&(osgi.identity=isaac-app)(type=karaf.feature)(version>=2.1.2.SNAPSHOT)(version<=2.1.2.SNAPSHOT))"
 [caused by: Unable to resolve isaac-app/2.1.2.SNAPSHOT: missing requirement 
[isaac-app/2.1.2.SNAPSHOT] osgi.identity; osgi.identity=isaac-service; 
type=karaf.feature [caused by: Unable to resolve isaac-service/2.1.2.SNAPSHOT: 
missing requirement [isaac-service/2.1.2.SNAPSHOT] osgi.identity; 
osgi.identity=com.brodos.isaac.service; type=osgi.bundle; 
version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]"; resolution:=mandatory [caused by: 
Unable to resolve com.brodos.isaac.service/2.1.2.SNAPSHOT: missing requirement 
[com.brodos.isaac.service/2.1.2.SNAPSHOT] osgi.service; 
objectClass=javax.sql.DataSource; effective:=active; 
filter:="(osgi.jndi.service.name=bam)"]]]

Shouldn't it be ignored by OSGi framework?

What I try to achieve is that a certain bundle activation is postponed until a 
given requirement is met. Is is possible anyways?

Best regards,
Alexander