Hi,

I had a couple of times when based on the presence of a service I wanted to
catch other services as well. For example when I have a PersistenceProvider
available I want to start tracking the DataSourceFactory service and create
an entity manager when it is available. I am not sure if I should create a
ServiceTracker object for every persistenceUnit or I should have one
service tracker and handling the necessities from the different persistence
units by hand.

I am not sure I was clear so here is another abstract example:

There is a service A which needs Service B and service B needs service C
and D. Service B has to have some properties based on the properties of
service A and service C and D has to have some properties based on the
properties of service B.

Which is the best practice?

1: I instantiate a ServiceTracker with the good filter every time a service
A is caughed and I do the same when a service B is caughed based on the
second serviceTracker.
2: I create one service tracker for A, one for B and one for C and I check
the properties and handle everything with a code that aimed to the special
requirement.

Solution 1 can work only if it is not a problem if even thousands of
ServiceTracker instances can work parallel and it does not have a
performance issue. Does anybody have experience on this? I guess the
performance of ServiceTrackers are related to the OSGI container as well
(felix, equinox, ...) but if there is not real performance difference
between solution 1 and solution 2 then solution 1 needs much less
programming and much less difficult code.

Till now I alway instantiate as less ServiceTracker as I could however this
may have been a bad practice.

Thanks and regards,
Balazs Zsoldos
Software Architect
Mobile: +36-70/594-92-34

Everit Kft.
https://www.everit.biz
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to