This is a suggested approach for dealing with it, I believe it is
mentioned somewhere in the OSGi specification.
Still, this doesn't solve all problems. Yes, it allows you to stop the
consumer from invoking methods on the real service object, but it
doesn't help you completely with garbage collection since the consumer
is still holding onto a reference to an object implementing the service
interface and if that is exported by the bundle going away, then it
still cannot be garbage collected.
-> richard
Tilo Gau wrote:
Hello,
I read an articel a few month ago which address this problem. The author advised to use a wrapper object, which holds the real service reference. On unregister the service reference is set to null and the unpolite bundle remains with an useless wrapper object.
Best regards,
Tilo Gau
________________________________
Von: [email protected] im Auftrag von Luca Ferrari
Gesendet: Fr 12.12.2008 09:20
An: OSGi Developer Mail List
Betreff: [osgi-dev] about service references
Hi all,
I'm almost new to OSGi, so apologize me if I'm doing trivial questions. Now,
I'd like to know how OSGi reacts to a bundle that is not polite and does not
use facilities like a service tracker to catch a removed service. In the case
a bundle A holds a reference to a service in the bundle B, and the latter is
uninstalled, what happens? Moreover, the service hold by A is a concrete
reference to the implementation in B or there's a wrapper layer that catches
A-to-B requests and passes them to the B implementation, so hiding the B
implementation?
Thanks,
Luca
_______________________________________________
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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
