BJ Hargrave wrote:
I am not sure it is that unlikely.
Scenario:
A framework is launching and there are 3 bundles: A (contains your
snippet), Http, Log. They are all at the same start level and the
framework chooses to start them in the order: A, Http, Log. A will start
right up and create 2 trackers. No problem. Http starts up and registers
the HttpService in its activator. The ServiceEvent is received by the
tracker in A and A calls log which then waits for 10 seconds for a
LogService. The thread launching the bundles is now blocked and the Log
bundle wont be started to register its LogService. In this scenario, it
does not matter how long you wait for a LogService. You might say a
framework impl should use multiple threads to launch the bundles which
would avoid this. But this is not required by the spec and we shouldn't
promote coding examples which rely upon it.
I think it is bad from to block for a long time in an event listener which
is effect what your snippet suggests. The waitForService method warns
about avoiding that in BundleActivator methods. I guess the warning should
be extended to include event listener methods and ServiceTrackerCustomizer
methods.
To demonstrate the use of waitForService, it would be better to use a
thread which is not related to event delivery and whose blocking does not
impede progress of the system.
Something simple and regular. IMHO smthing like the dining philosophers
problem but in service oriented implementation. Could it be representative?
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
office: +1 386 848 1781
mobile: +1 386 848 3788
Aggelos
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
