Bug 141180

Description Jeff McAffer 2006-05-10 20:25:27 EDT

the current ServiceTracker seems to want to getService() for all the services that might be needed when the tracker is opened.  It seems that it also keeps track of all the services.  These characteristics are problematic for a couple reasons:
- The services are not needed until someone does getService() 
- ignoring the case where people are doing getServices() (plural) there is generally no need to maintain a list of all serivces.  You can simply remember the last one you bound to and listen for changes.  If a change occurs, flush the current cache and recompute the next time someone does a getService().
- in many/most of the cases that we have there is no customizer so much of this stuff around lifecycles is not needed.  Unfortunately, we currently do not have a way of distinguishing between service trackers that are customized and those which are not.
- The current approach may present some difficulties for declarative services.  getting the service will force it to be created thus defeating the laziness characteristics of DS.

Either the ServiceTracker we have now should be updated with these characteristics or we should write a FastServiceTracker that we use in our code.  If we do the former (and it makes sense) we should consider doing it in the org.osgi namespace (as the current one is) to improve the reference implementation.