Hi Bryan,
Bryan Hunt wrote:
On Jun 9, 2009, at 11:07 AM, Scott Lewis wrote:
Hi Bryan,
The listener is registered in the Activator of the org.eclipse.ecf.osgi.services.discovery bundle, which is started when the org.eclipse.ecf.osgi.services.distribution bundle is started.
So the key thing is that the org.eclipse.ecf.osgi.services.distribution bundle must be started in order to get everything going in a lazy start environment (like Eclipse)...or a class in o.e.e.osgi.services.distribution accessed, of course (as this will also start o.e.e.osgi.services.distribution and discovery).
If the osgi distribution (and discovery) bundles are not started, then yes...they will miss discovered services (assuming the ecf discovery *has* been started). This constraint isn't unique to ECF...as there was nothing in the spec (in my most recent reading of RFC 119) that discusses starting/start order in various environments.
Even if they are started prior to the discovery provider, I assert there is still a race condition. The listener is added asynchronously to the provider which could have already discovered it's services,
Not sure if I understand what you mean 'listener is added asynchronously to the provider'. The listener is added in the start method of the org.eclipse.ecf.osgi.discovery bundle. If this is what you mean by asynchronous, then do you mean asynchronous to the discovery provider being started?
If so, then yes...this starting of the osgi.discovery bundle can happen asynchronous to the starting of the discovery provider.
could be in the process of discovering services, or may not discover any services for several hours.
Sure. This is why, in general, it makes sense to start the osgi distribution/discovery code as early as possible. But we cannot require/guarantee when any of our bundles get started (or even if they get started)...in fact, for distribution with Eclipse we explicitly *can't* start them (since Eclipse uses lazy start).
Isn't this the exact same problem as listening to regular OSGi services and why the ServiceTracker was created?
We do use a service tracker to track the IDiscoveryLocator, it's on line 82 in org.eclipse.ecf.internal.osgi.services.discovery.Activator. The call to locatorTracker.open() on line 85 will end up calling LocatorTrackerCustomizer.addingService(servicePublicationHandler), which adds a service listener to the discovered IDiscoveryLocator.
I think I recognize what you are trying to say (correct me if I'm wrong): isn't it possible that an ECF discovery provider (e.g. zeroconf/slp) could discover services all day long, and the osgi discovery would never be triggered...because it was never started, and therefore no listener was registered, therefore no notifications. Yes, that is certainly true. But it's not obvious (to me) what we can do about this given the OSGi lazy starting (other than what we have done...which is to start osgi discovery as part of osgi distribution being started)...and no spec-based guidance on start order.
