On Mon, Feb 21, 2011 at 10:49 AM, Peter Kriens <[email protected]> wrote: > I think we have think a bit deeper. Assume you have 2 exporters of IFoo that > are both compatible with the proxy you generate. Shouldn't you create a proxy > for both?
Ideally yes, but this doesn't seem to be compatible with the RSA spec... if the TM calls importService(EndpointDescription) then it gets back a single ImportRegistration, which in turn points to a single ImportReference which points to a single ServiceReference. The DP can choose any exporter of the service API, but only one. If the DP did need to proxy all of the API exports then it would have to create an on-the-fly generated bundle for each version (as per our previous discussion). These would probably need to use either Require-Bundle or Import-Package+bundle-symbolic-name attribute, to make sure they wire to the expected export. Incidentally, can anybody comment on how the RI handles this currently? Cheers Neil > I think the only viable solution is to register the proxy with each distinct > exporter of IFoo's package for which you're compatible with to ensure you do > not leave anybody out in the cold. > > Logically, 4.3's new registerService(Class<S>,S,Map) method should provide > you with the capability but I am afraid the current definition of the > compatibility is in limbo because it is unfortunately defined in terms of > isAssignableTo, which unfortunately is string based instead of class based. I > think we need to define a Class<?> version of this method that we then use > for compatibility when possible. This will allow you to register objects from > the DP that are compatible with other bundles even though you do not import > the service interfaces. I file an errata so this is looked into. > > Oh, how I long for the days of OSGi R3 when we did not have multiple versions > :-( > > Kind regards, > > Peter Kriens > > > On 21 feb 2011, at 07:00, Scott Lewis wrote: > >> On 2/20/2011 6:14 PM, BJ Hargrave wrote: >>> <stuff deleted> >>> >>> You could use dynamic import package but that has some drawbacks. First you >>> would need to actually load the type(s) to force the framework to >>> establish the wires before you register the service. Second, you could only >>> support one version of the package could be a big limitation. >> >> Yes, I see how supporting only one version of a package could be a big >> limitation. >> >>> >>> This is why I previously suggested dynamically creating, installing and >>> starting a bundle which has the proper import package statement. This >>> bundle does not need any classes in it. You just need an "anchor" to use >>> for its class loader to access the types and for its context to register >>> the service. The actual work can be done by your bundle. Make sure to >>> properly uninstall this bundle when no longer necessary. There can be many >>> of these bundles for different service types. >> >> Forgive me, but this approach seems kind of clumsy and complex to manage to >> me...as it could be necessary to create, install, start and manage/uninstall >> a lot of these dynamic bundles...i.e. one for each distinct imported remote >> service. >> >> Are there any viable approaches other than this? e.g. can the wiring of >> the RSA (or TopologyManager) bundle be dynamically manipulated...to allow >> the RSA or TM itself to register the proxy service factory? >> >> Thanks, >> >> Scott >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
