Using an Activator minimises your module's dependencies, but at the expense of getting any help in this sort of situation. It's also really easy to make mistakes when doing it, and hard to get useful integration with things like configuration admin. I would always recommend that an application use a container (usually Declarative Services) to register and/or consume OSGi services.
Regards, Tim Sent from my iPhone > On 29 Mar 2016, at 17:39, asookazian2 <asookaz...@gmail.com> wrote: > > Hi Timothy, thx for your response. It turns out the Blueprint config.xml > with the service registration (which was working previously) was removed and > replaced with an Activator class which had the service registration line > commented out. This change was done by another developer and not > communicated to me but anyways root cause is found. > > Any recommendations on using BP config.xml vs. Activator class (e.g. you can > debug the Activator class)? thx. > > > Timothy Ward wrote >> The error that you've provided indicates a missing service dependency for >> a service exposing the com.foo.bar.myClass interface. >> >> You should investigate why this service is not present, or if it is, why >> bundle B has not wired to the same class space for package com.foo.bar as >> the service provider. >> >> Regards >> >> Tim Ward >> >> OSGi IoT EG Chair >> >>> On 28 Mar 2016, at 23:36, asookazian2 < > >> asookazian@ > >> > wrote: >>> >>> Karaf 3.0.3 >>> >>> bundle B is in GracePeriod (and ultimately Failure) with dependency on >>> bundle A (which is active and has lower start-level than bundle B). >>> >>> eventually bundle:diag 123 (for bundle B) gives: >>> >>> Status: Failure >>> Blueprint >>> 3/28/16 3:24 PM >>> Exception: >>> null >>> java.util.concurrent.TimeoutException >>> at >>> org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:336) >>> at >>> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) >>> at >>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) >>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >>> at >>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) >>> at >>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:745) >>> >>> Missing dependencies: >>> (objectClass=com.foo.bar.myClass) >>> >>> When I run package:exports | grep com.foo.bar I see only the one expected >>> bundle which is exported same package (I've triple-checked the >>> manifest.mf >>> files for both bundles in data/cache/xyz). i.e. there is no >>> split-package >>> problem in this scenario afaik. >>> >>> Any idea how/why this happens and how to resolve? thx. >>> >>> >>> >>> -- >>> View this message in context: >>> http://karaf.922171.n3.nabble.com/exported-package-in-bundle-A-is-not-able-to-be-imported-in-bundle-B-tp4046019.html >>> Sent from the Karaf - User mailing list archive at Nabble.com. > > > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/exported-package-in-bundle-A-is-not-able-to-be-imported-in-bundle-B-tp4046019p4046042.html > Sent from the Karaf - User mailing list archive at Nabble.com.
