Thank you both for the quick answers! Regarding the FrameworkWiring.refreshBundles() method, I tested it and it works as expected, refreshing all the wires. I used this idiom to refresh the entire OSGi platform:
FrameworkUtil.getBundle(MycurrentClass.class).getBundleContext().getBundle(0).adapt(FrameworkWiring.class).refreshBundles(null); Basically I get BundleContext from current Bundle to obtain system Bundle (Bundle with index 0) and the I refresh all the Bundles. It seems to be an expensive task, but in my test it was done many times without a big penalty (my system has ~200 bundles). Is it correct? Do you think it would be better using another technique? Regarding Andreas approach, I understand what you say, but I prefer to auto-discover Bundle contents, not using OSGi services. In this case, bundles don't offer services, they offer simply Java dependencies. Anyway, thank you for your contribution. Regards, <http://dana.i2cat.net> <http://www.i2cat.net/en> Julio C. Barrera Juez [image: View my profile on LinkedIn] <http://es.linkedin.com/in/jcbarrera/en> Office phone: (+34) 93 357 99 27 (ext. 527) Office mobile phone: (+34) 625 66 77 26 Distributed Applications and Networks Area (DANA) i2CAT Foundation, Barcelona On 13 June 2014 08:53, Andreas Klotz <[email protected]> wrote: > Hi Julio, > > > > related to your second question using Services should be a solution. In > our OSGi-applications we use exclusively Services for > inter-bundle-communication and we use the declarative approaches for > defining Service dependencies (Declarative Services or (preferred) > Blueprint). > > > > So in your case BundleA should provide a Service which is consumed by > BundleB. So if BundleB is stopped, its provided Services will be > automatically unregistered and the ServiceTracker of BundleB (managed by > Blueprint or DS) will detect the deregistration and the consuming Service > can react to it. > > > > Best regards, Andreas > > > > *Von:* [email protected] [mailto: > [email protected]] *Im Auftrag von *Julio Carlos Barrera Juez > *Gesendet:* Donnerstag, 12. Juni 2014 18:05 > *An:* [email protected] > *Betreff:* [osgi-dev] Bundle dependency chain > > > > Hello. > > > > This is my first mail to this mailing list. I'm working with OSGi for 2 > years and I could say I understand and use main concepts in my company > projects. We work in the development of OpenNaaS project [1], an open > source platform for provisioning network resources. It is based on Apache > Karaf and it is composed by a set of several bundles. > > > > In our new version, we want to actively discover and resolve incoming and > outgoing bundles in the system. For that purpose we use BundleListener > interface [2] to receive BundleEvents [3]. Concretely, we listen > for BundleEvent.STARTED and BundleEvent.STOPPED events. This pattern is OK > for us and seems to fit our requirements. > > > > Now, imagine a Bundle called BundleA and another called BundleB. BundleA > exports a package named packageA, and BundleB imports it. It is, BundleB > depends on BundleA. We (wrongly) assumed that when BundleA eventually > leaved the platform, BundleB would have one unresolved import and would > become stopped too, but this is not the real case. BundleB was still ACTIVE > with an unresolved import. > > > > Apache Karaf (2.5.x or even 3.x) realizes of that fact, marking this > import in red colour in Karaf shell when invoking bundle:headers command > [4], but we don't know the exact process that make Karaf aware of that > unresolved import. > > > > My questionas are: > > > > - Why BundleB is still ACTIVE, even when some of his imports and > unresolved? > > - How could we detect a Bundle with unresolved imports to mark it as > "non-usable" Bundle? > > > > Thank you. > > > > > > [1] OpenNaaS project, http://opennaas.org/ > > [2] BundleListener Java interface, > http://www.osgi.org/javadoc/r4v43/core/index.html?org/osgi/framework/BundleListener.html > > [3] BundleEvent Java class, > http://www.osgi.org/javadoc/r4v43/core/index.html?org/osgi/framework/BundleEvent.html > > [4] bundle:headers Apache Karaf command, > http://karaf.apache.org/manual/latest/commands/bundle-headers.html > > > > > > Regards, > > <http://dana.i2cat.net> <http://www.i2cat.net/en> > > Julio C. Barrera Juez [image: View my profile on LinkedIn] > <http://es.linkedin.com/in/jcbarrera/en> > > Office phone: (+34) 93 357 99 27 (ext. 527) > > Office mobile phone: (+34) 625 66 77 26 > Distributed Applications and Networks Area (DANA) > i2CAT Foundation, Barcelona > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
