BJ Hargrave <[EMAIL PROTECTED]> writes: > Yes, I would still suggest using a ServiceTracker for short lived > uses.
I found one downside to using ServiceTracker versus my previous alternative: ServiceTracker's constructors penalize callers with filter criteria. Allow me to explain. In one of the two implementations I've studied (Felix), ServiceTracker assumes that if it was constructed with a filter, the class name of the desired service set cannot be known. When ServiceTracker calls BundleContext.getServiceReferences(String, String), it passes null for the class name, with the penalty that way down the call chain, the entire Service Registry has to be scanned linearly looking for a filter match. Equinox's ServiceTracker is clever enough to hoist a class name out of a supplied filter, and use the class name as a first cut into the Service Registry, applying the filter only to those services that match the desired class. The Equinox Service Registry is indexed by a HashMap from class name to a list of ServiceRegistrations. Felix does do some special matching by class name in its search through the Service Registry, but it still iterates linearly through its set of registrants. Also, as mentioned, this optimization is missed by ServiceTracker users that supply a filter to the constructor. -- Steven E. Harris _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
