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.
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.
Does that make sense?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
