(1) yes. However its usually better practice to do something to respond to the bundle stopping to close down the service carefully. For instance, if you use declarative services, your component supplying the service will get its deactivate method called before the bundle stops.
(2) no. However, before unregistering the service the framework will publish a service event indicating that the service is about to be removed and further use of the service object is inadvisable. Dealing with service events dynamically is not easy. You should use ServiceTracker if you like to write code and you should use Declarative Services or equivalent if you want to just worry about the logic in your service. I’m a DS partisan; other people like Felix Dependency Manager and Felix IPOJO. I would stay away from blueprint. There may be other component frameworks but I don’t know what they are. david jencks > On Aug 20, 2015, at 8:39 PM, bdemchak <[email protected]> wrote: > > Hi, all -- > > Two simple newbie questions that are a little hard to pin down from the OSGi > documentation I can find ... thanks in advance for answering! > > 1) If I have a bundle B offering service S, if I stop B then S becomes > unregistered automatically. Pretty sure that's right ... true? > > 2) Suppose there is a client C that has done getServiceReference followed by > getService but NOT ungetService ... if someone then tries to stop B, they > should get an exception?? True?? > > I believe this because otherwise the validity guarantee provided by > getService doesn't seem to hold value. > > Simple questions ... can someone affirm these or explain how I'm wrong?? > > Thanks! > > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Testing-understanding-of-stopping-a-bundle-tp4041991.html > Sent from the Karaf - User mailing list archive at Nabble.com.
