Ok, I guess I figured it out :-) At least I hope.
The problem is that Equinox and Felix have been working together to make the
visibility of services workable in practice but forgot to update the spec. The
magic to make it work is to create a dummy bundle and use that for service
proxy registration. You only need one for all service proxies.
It turns out that both Equinox and Felix detect an "extender" by looking at the
implementation class of the Service Factory. If the Bundle Context does not
corresponds to the class loader of the Service Factory implementation then they
assume you are an extender and they always grant you visibility. Otherwise, the
original OSGi rules come into play that are much more restricted.
So by using a dummy bundle for your service registrations you tell Equinox and
Felix that you're an extender and they will give you some more leeway. An added
benefit is that this dummy bundle can also have no imports and exports so never
give you a problem with conflicting imports/exports.
I tested this and it is clear that the frameworks distinguish between these
cases, although their behavior is not identical. So we still have to discuss
this inside.
Let me know if this helps. Kind regards,
Peter Kriens
On 21 feb 2011, at 17:03, Scott Lewis wrote:
> Hi Peter,
>
> Although I'm very happy to hear this, I've been running/testing on 3.7M4
> version of Equinox and I'm still seeing the problem (i.e. proxy
> ServiceFactory registered by TM bundle...without dynamic import:*...still
> doesn't pass compatibility check).
>
> Maybe I need to do something else to trigger this new behavior (?)...if so
> please let me know. Do you (or Guillaume) have a bug number for the
> ServiceFactory bug?
>
> Thanks all for the help with this.
>
> Scott
>
> On 2/21/2011 7:33 AM, Peter Kriens 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
>
> _______________________________________________
> 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
