On Tue, May 25, 2010 at 11:09, Rickard Öberg <[email protected]> wrote:
> On 2010-05-24 20.44, Niclas Hedhman wrote: > >> Well, that can work but isn't clean. >> Ideally, you should have the importer register a ServiceTracker to the >> BundleContext, and it will be notified when services are >> added/modified/removed accordingly. That can be done for instance by >> having a ServiceTracker implementation acting the service implementing >> proxy, and perhaps block for a while before failing calls during >> service upgrades. >> > > I agree, but that is not enough. The problem is that there is no way to > force the service proxy (backed by a ServiceTracker) to be created on > startup, it is only done today when a service dereferenced > (ServiceReferece.get()). So when the isActive() method comes to the > ServiceReference, we need to ensure that the proxy+tracker has been created, > or else it has no choice but to return "false". The easiest way to do that > is to call ImportedServiceReferenceInstace.getInstance(), which will create > this proxy+tracker, and which then allows it to check at that moment whether > the service is there or not. I'm not sure which OSGi approach you took, but I'm wondering on how do you passed BundleContext around in order to get ServiceTracker bootstrapped? Do you do this as part of application assembly? or do you expose bundleContext as qi4j service? If it's the former, shouldn't it be possible to get the proxy and service tracker created at startup? And this is very well suited for both Qi4j and java.lang.reflect.Proxy >> to avoid redoing the same code over and over again. >> > > I agree! > > So, what I would propose is still that the > ImportedServiceReferenceInstance.isActive() does getInstance() first, and > then call isActive() on it. The implementation of the OSGi Service Importer > (which I only have in Streamflow so far) would then use a ServiceTracker to > do the actual work, rather than doing a lookup on each invocation. > > Then it's all goodness. > > I find it interesting to relate this to what Richard Nicholson talks about, > where from a particular point of view (say, inside the Qi4j app) a service > is perceived to be always there, and yet from the outside (the OSGi > framework runner) the service comes and goes. The OSGi ServiceImporter can > provide the illusion that it is always there, by using the OSGi > ServiceTracker, proxies and a lookup timeout. I believe this is similar to > what Spring does for the same case. Yup, that's what Spring do, it injects a proxy and create an illusion that the service is always there. Regards, Edward Yakop
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
