karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <alexander.sah...@brodos.de>
Subject Re: Antw: Re: Require-Capability with effective:=active not ignored
Date Wed, 16 Aug 2017 13:30:43 GMT
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 <tim.ward@paremus.com> schrieb am Mittwoch, 16. August
2017 um

12:27 in Nachricht <50CD1D90-699F-405D-B1CB-E02F36D05F3C@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, <alexander.sahler@brodos.de> 

> <alexander.sahler@brodos.de> 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.sahler@brodos.de 

> <mailto:alexander.sahler@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 
>
<http://osgi-dev.mail.osgi.narkive.com/GfJqfPGZ/require-capability-osgi-servi


> 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
> OT)(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
>> 

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message