It's really hard to even start dealing with these issues if you try to just use service references.
One thing to keep in mind is that the ungetService event happens while the service is still available. So theoretically you can use a read-write lock with worker threads getting the read lock and the ungot method getting the write lock to make sure the service is OK while you are using it. However I’ve never seen anyone do this. Instead everyone uses some version of, only use a service briefly and hope it works. If you are using a ServiceTracker, this strategy is implemented by getting the service from the tracker on each use and never caching it anywhere. If you are using DS, the unbind method will be called in response to the ungot service event, so you can put the service or service reference in a (typically volatile or atomic) field and it will be reset before the service is unavailable. Note that for a static or mandatory reference the deactivate method will be called before the unbind method. This pretty much shifts the problem to the caller of your DS component, who would get notified it is leaving. hope this helps david jencks > On Aug 21, 2015, at 1:54 PM, bdemchak <[email protected]> wrote: > > Thanks, David ... I appreciate the quick reply. > > Followup on #2: I'm confused, then. I understand that our client code could > get the notification that the service will be unavailable, as you say. That > means, though, that the client code will need to check for service > availability before each and every usage, and then pray that the service > remains available between the check and the actual service call. Is that > right? > > Similarly, if the client code performs a getService, what is the function of > the ungetService if the service could actually deactivate regardless of the > getService having been performed? > > I think I'm missing something here. > > Thanks for the help! > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Testing-understanding-of-stopping-a-bundle-tp4041991p4042019.html > Sent from the Karaf - User mailing list archive at Nabble.com.
