OSGI: What is the best approach to wait for a declarative service component to start?

Question

I have the following problem:

1: An OSGI bundle A (equinox) is activated, and the activator parses an XML file
2: in the XML file, a declarative service is requested, which is present in another bundle (B)
3: bundle B is not activated yet, so the activator of bundle A needs to wait

I know how to approach this purely in DS, but the parsing needs to be carried out in the activator. Also I do not want to fool around with start levels and the likes. Ideally, I would want to be able to register the service provided by bundle B when needed.

Is there an elegant way to achieve this?

Thanks,

Kees

AFAIK you can register as BundleListener and see when it is activated — Niels Bech Nielsen, Mar 12 '14 at 14:01
Hi Niels, I know about the activator problem, but currently I am stuck to this problem because of a third party library (and classloading issues). — keesp, Mar 12 '14 at 14:13
Oh yes, this solution would not be better than using the servicelistener — keesp, Mar 12 '14 at 14:22
Depending on the exact issue, it may even be best to skip the whole service dependency and put it all in one bundle. — Arie van Wijngaarden, Mar 12 '14 at 14:43
Can you explain more about the external dependency and the classloading problem you mention? I think this is your real problem and maybe we can suggest something once we understand this. — Christian Schneider, Mar 13 '14 at 05:37

score 2 · Accepted Answer · answered Mar 12 '14 at 14:39

OSGi services are dynamic by nature and therefore you should never depend on the availability of a service. You need to use some kind of service tracking via a ServiceTracker or better, go for the pure DS solution which does all the hard work for you.

Since you indicate that you must parse the XML file, I guess you decided to use some kind of external configuration with services to use. I would suggest to re-consider this type of architecture. You need to write a lot of code while often the same goals can be reached by using a combination of the configuration admin and declarative services/blueprint.

Well, a change in design was indeed the best solution. I now parse the XML file twice, once (quickly) to determine which services need to be loaded, after which I listen for registered services. If all the services I need are available, I parse the XML file more thoroughly in order to install the services.A bit more work, but a cleaner approach. Thanks — keesp, Mar 18 '14 at 14:56

OSGI: What is the best approach to wait for a declarative service component to start?

1 Answers1