You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by bdemchak <id...@gmail.com> on 2015/08/21 02:39:20 UTC
Testing understanding of stopping a bundle
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.
Re: Testing understanding of stopping a bundle
Posted by bdemchak <id...@gmail.com>.
Thanks, David --
I think I'll have to read up this more before I can see how this makes
sense. I get the locking idea, and can see where it would and would not
apply.
... for now, going away to read manuals.
Thanks!
--
View this message in context: http://karaf.922171.n3.nabble.com/Testing-understanding-of-stopping-a-bundle-tp4041991p4042021.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Testing understanding of stopping a bundle
Posted by David Jencks <da...@yahoo.com>.
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 <id...@gmail.com> 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.
Re: Testing understanding of stopping a bundle
Posted by bdemchak <id...@gmail.com>.
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.
Re: Testing understanding of stopping a bundle
Posted by David Jencks <da...@yahoo.com>.
(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 <id...@gmail.com> 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.