Yes, I recall this issue and that was the same kind of problem where blueprint had to register a proxy on behalf of a bundle, so the classloader of the actual service factory could not see the service interface directly. With the use of extenders, it seems like a more and more common use cases.
On Mon, Feb 21, 2011 at 16:33, Peter Kriens <[email protected]> wrote: > Did some deeper digging and I think we have an interesting issue. > > ECF RSA should work with +M3 release of 3.7 Equinox. It turns out that a bug > requested by Guillaume Nodet relaxed the rules for Service Factory services. > If the registrant of the service cannot see the package for any of the > service name classes then it is assumed that he Service Factory will do the > right thing. So with a Service Factory you should be able to register an > appropriate proxy for each bundle, at least in equinox. > > Unfortunately, there seems to be some inconsistency here between the > frameworks. I will get to the bottom of this. > > Kind regards, > > Peter Kriens > > > On 21 feb 2011, at 11:49, Peter Kriens 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? >> >> 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 > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
