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.sah...@brodos.de> > <alexander.sah...@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 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 >> <mailto: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 >> >> <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 >
