On 2/21/2011 8:54 AM, Thomas Watson wrote:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=326918
I just looked at the code again. It should work as long as the
registrant bundle has no wire to the package in question AND the
service was registered using a ServiceFactory. If you are seeing
something else, please open an equinox bug.
Ok, this is not what I'm seeing (i.e. the RSA proxy service factory code
is not working in 3.7m4)...at least as evidenced by
ServiceTracker.open(true) requirement.
I'm going to be away the remainder of today, so cannot open a bug until
tomorrow, but if a test case exists/is created (as per BJ's request)
then a test that would match my use case:
In consumer framework:
Bundle A: org.foo.IFoo.class (service type)
Bundle TM: registers a proxy-creating ServiceFactory upon async network
discovery. Has no import of org.foo package and IFoo is not dynamically
loaded.
Bundle B: imports org.foo package, creates ServiceTracker to be
notified about org.foo.IFoo remote services.
If Bundle B uses ServiceTracker.open(true), it is notified about the
proxy ServiceFactory registration, and calls getService(B)...which uses
B.loadClass to load the org.foo.IFoo class, and create and return a proxy.
If Bundle B uses ServiceTracker.open(), it is not notified about the
proxy ServiceFactory, and so getService is never called to create actual
proxy.
I'm assuming ServiceTracker.open(true) being required is because of
ServiceReference#isAssignable returning false for the proxy
ServiceFactory as per https://bugs.eclipse.org/bugs/show_bug.cgi?id=326918
Please let me know if I need to create this test code myself...I could
do so, but probably will not until tomorrow or later this week.
Scott
Tom
[email protected] wrote: -----
To: [email protected]
From: Scott Lewis <[email protected]>
Sent by: [email protected]
Date: 02/21/2011 10:03AM
Subject: Re: [osgi-dev] Classloader accessibility and
ServiceTracker.open(true)
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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
