I agree, at startup you could always have this case. I have changed
the example (and mentioned you! You're famous now! :-)
Kind regards,
Peter Kriens
BH> I am not sure it is that unlikely.
BH> Scenario:
BH> A framework is launching and there are 3 bundles: A (contains your
BH> snippet), Http, Log. They are all at the same start level and the
BH> framework chooses to start them in the order: A, Http, Log. A will start
BH> right up and create 2 trackers. No problem. Http starts up and registers
BH> the HttpService in its activator. The ServiceEvent is received by the
BH> tracker in A and A calls log which then waits for 10 seconds for a
BH> LogService. The thread launching the bundles is now blocked and the Log
BH> bundle wont be started to register its LogService. In this scenario, it
BH> does not matter how long you wait for a LogService. You might say a
BH> framework impl should use multiple threads to launch the bundles which
BH> would avoid this. But this is not required by the spec and we shouldn't
BH> promote coding examples which rely upon it.
BH> I think it is bad from to block for a long time in an event listener which
BH> is effect what your snippet suggests. The waitForService method warns
BH> about avoiding that in BundleActivator methods. I guess the warning should
BH> be extended to include event listener methods and ServiceTrackerCustomizer
BH> methods.
BH> To demonstrate the use of waitForService, it would be better to use a
BH> thread which is not related to event delivery and whose blocking does not
BH> impede progress of the system.
BH> BJ Hargrave
BH> Senior Technical Staff Member, IBM
BH> OSGi Fellow and CTO of the OSGi Alliance
BH> [EMAIL PROTECTED]
BH> office: +1 386 848 1781
BH> mobile: +1 386 848 3788
BH> Peter Kriens <[EMAIL PROTECTED]>
BH> 02/23/2007 08:04 AM
BH> To
BH> BJ Hargrave/Austin/[EMAIL PROTECTED]
BH> cc
BH> OSGi Developer Mail List <[email protected]>
BH> Subject
BH> Re[2]: [osgi-dev] Re: Knopflerfish and Eclipse
BH> The key word is potentially ... normally the log service will be there
BH> or shortly. It is highly unlikely that it will -ever- have to wait. So
BH> in the unlikely case you take a performance hit, but things keep on
BH> working.
BH> I just needed to demonstrate the waitForService as well.
BH> However, I'll add a comment about the synchronous behavior of service
BH> tracker.
BH> Kind regards,
BH> Peter Kriens
BH>> I am not sure that is such a great example. The log method block for
BH>> potentialy a very long time and thus can impede the ServiceEvent
BH> deliver
BH>> for HttpService. The ServiceTrackerCustomizer methods are called from
BH> the
BH>> ServiceListener inside ServiceTracker and should complete quickly.
BH>> BJ Hargrave
BH>> Senior Technical Staff Member, IBM
BH>> OSGi Fellow and CTO of the OSGi Alliance
BH>> [EMAIL PROTECTED]
BH>> office: +1 386 848 1781
BH>> mobile: +1 386 848 3788
BH>> Peter Kriens <[EMAIL PROTECTED]>
BH>> Sent by: [EMAIL PROTECTED]
BH>> 02/23/2007 04:11 AM
BH>> Please respond to
BH>> OSGi Developer Mail List <[email protected]>
BH>> To
BH>> Aggelos Mpimpoudis <[EMAIL PROTECTED]>
BH>> cc
BH>> [email protected]
BH>> Subject
BH>> Re: [osgi-dev] Re: Knopflerfish and Eclipse
BH>> If you need another example with the service tracker look at:
BH>> http://www.aqute.biz/Snippets/Tracker
BH>> There are also some similar examples.
BH>> Kind regards,
BH>> Peter Kriens
BH>> _______________________________________________
BH>> OSGi Developer Mail List
BH>> [email protected]
BH>> http://www2.osgi.org/mailman/listinfo/osgi-dev
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
