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/ <http://opennaas.org/> [2] BundleListener Java interface, http://www.osgi.org/javadoc/r4v43/core/index.html?org/osgi/framework/BundleListener.html <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 <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 <http://karaf.apache.org/manual/latest/commands/bundle-headers.html> Regards, <http://dana.i2cat.net> <http://www.i2cat.net/en> Julio C. Barrera Juez <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
