>>>>> Tim Ward <[email protected]>: >> 1. Not run for a too long time (e.g. not block, waiting for an HTTP response)
> Basic answer: > Yes, you should avoid blocking in callbacks generally. The thread is > not your own and by blocking you could halt the entire Service > Component Runtime, potentially halting (or even deadlocking) the > system. If you need to do something long-running then create your own > thread to do it. Ok. > Advanced answer: > If you have a long-running asynchronous startup then the default > “lazy” behaviour of DS can be problematic. Your component will be > registered as a service before it is activated, then activated when it > is first retrieved. This activation will complete when your @Activate > method exits, even though your asynchronous startup is still > running. You will therefore either need to block incoming calls until > the asynchronous startup finishes (including dealing with failures), > or throw exceptions until you are ready (yuck!). I've been bitten by the lazy behaviour earlier so all of my DS components are @Component(immediate=true) > A better option in these cases can be to *not* let DS register your > component as a service, but instead to programatically register your > service object after it has completed activation. In this case writing > a DS component that is a lifecycle manager and collector of > dependencies, but not the actual service object, can be very helpful. Do I need to get hold of the BundleContext and call registerService() old style? Or is there some new and elegant way of doing this? >> 2. Not fail (i.e. never throw an exception) > You should definitely fail if the component is broken. Throwing an > exception from a constructor or @Activate method will cause the > component to be unregistered from the service registry and marked as > failed in the service component runtime. You should not “silently > fail” and leave a broken service object. Ah, OK! Good to know. I may have to rewrite some components...:-) What happens when an exception is thrown in a separate thread started to avoid blocking? Will that fail the component? Or is it just exceptions thrown from the exception or the @Activate method that will fail the component. >> 3. Other? > Make sure to correctly define the optionality and cardinality of your > dependencies, including dependencies that you have on > configuration. Only let the container start your component when it is > actually able to do its job. Ok. > I hope this helps, Very helpful, and very clarifying! Thanks! :-)
